GRBL new post processor with drill cycles G81..G83

Here's the place for discussion related to CAM/CNC and the development of the Path module.
topcyde
Posts: 48
Joined: Wed Mar 05, 2014 5:32 am

Re: GRBL new post processor with drill cycles G81..G83

Postby topcyde » Sat Jun 08, 2019 2:09 pm

sliptonic wrote:
Sat Jun 08, 2019 1:58 pm
What is the rationale for maintaining both a grbl and a grbl_g81 post processor?
To control the output for different machines/FW versions. At least until there's an option in the path operations to control the post output as either G-Code or machine cycle.
User avatar
sliptonic
Posts: 1569
Joined: Tue Oct 25, 2011 10:46 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby sliptonic » Sat Jun 08, 2019 2:14 pm

topcyde wrote:
Sat Jun 08, 2019 2:09 pm
sliptonic wrote:
Sat Jun 08, 2019 1:58 pm
What is the rationale for maintaining both a grbl and a grbl_g81 post processor?
To control the output for different machines/FW versions. At least until there's an option in the path operations to control the post output as either G-Code or machine cycle.
I don't understand. The regular grbl post produces canned cycles but AFAIK no grbl firmware can use them. So everybody should be using this variant.
What functionality differs between the two that is valid?
User avatar
sliptonic
Posts: 1569
Joined: Tue Oct 25, 2011 10:46 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby sliptonic » Sat Jun 08, 2019 2:22 pm

Also, I don't use grbl but I would be very confused that the post called grbl_g81.py is the one that specifically does NOT produce G81. :D

I would also suggest that it's overkill and confusing to have two arguments. --translate_drill and --no-translate_drill. It's more intuitive to have a single argument that does something and the absence of the argument does the other/default condition.

So if this can be merged with the regular grbl post, the default condition should be to translate the canned cycles and a flag --use-canned-cycles would suppress this and produce the regular G81/G83 moves.

Just me two cents.
User avatar
Gauthier
Posts: 73
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: GRBL new post processor with drill cycles G81..G83

Postby Gauthier » Sat Jun 08, 2019 2:29 pm

Hi all,

I agree with you Sliptonic, especially since the option to use drill cycles conversion or not (--translate_drill (by default) / --no-translate_drill) already exists... And without argument, drill cycles are translated. Then, the --translate_drill can be ignored... I can remove it if you want :)
In fact, I proposed the new name grbl_G81 on my first push to not impose my solution whereas a post processor for Grbl already existed.
So I'm going to push the merge of latest version of grbl_G81 with the name of the main post processor grbl_post.py quickly.

@++;
Gauthier.
Last edited by Gauthier on Sat Jun 08, 2019 2:35 pm, edited 1 time in total.
User avatar
freman
Posts: 709
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Sat Jun 08, 2019 2:29 pm

It can be argued that it is a bit redundant but this is typical of the way ./configure and make work on Linux/Unix.

It allows one to specify explicitly what you want rather than having to check on what the default state is to imply it.

also many compiler switches work like that : -fomit-frame-pointer -fnoomit-frame-pointer

The merge obviously makes sense. Nice initiative.
User avatar
Gauthier
Posts: 73
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: GRBL new post processor with drill cycles G81..G83

Postby Gauthier » Sat Jun 08, 2019 2:38 pm

We could put to the vote the choice to keep the two options or to delete the default one...
topcyde
Posts: 48
Joined: Wed Mar 05, 2014 5:32 am

Re: GRBL new post processor with drill cycles G81..G83

Postby topcyde » Sat Jun 08, 2019 2:41 pm

Gauthier wrote:
Sat Jun 08, 2019 2:29 pm
Hi all,

I agree with you Sliptonic, especially since the option to use drill cycles conversion or not (--translate_drill (by default) / --no-translate_drill) already exists... And without argument, drill cycles are translated. Then, the --translate_drill can be ignored... I can remove it if you want :)
In fact, I proposed the new name grbl_G81 on my first push to not impose my solution whereas a post processor for Grbl already existed.
So I'm going to push the merge of latest version of grbl_G81 with the name of the main post processor grbl_post.py quickly.

@++;
Gauthier.
I prefer the one post, I just hadn't read through it to see the option available. I would agree this is the better method.
User avatar
freman
Posts: 709
Joined: Tue Nov 27, 2018 10:30 pm

Re: GRBL new post processor with drill cycles G81..G83

Postby freman » Sat Jun 08, 2019 2:47 pm

since the other args do not have negated forms, it is probably clearer to be consistent.
User avatar
Gauthier
Posts: 73
Joined: Fri Jul 04, 2014 10:00 am
Location: Audenge, France

Re: GRBL new post processor with drill cycles G81..G83

Postby Gauthier » Tue Jun 11, 2019 10:46 am

Hi all,

PR made this morning (https://github.com/FreeCAD/FreeCAD/pull/2255) to replace the old grbl_post.py by the new grbl_G81 one.

For the moment, I have kept the arguments as they are. The other arguments from the old grbl_post also have their positive and negative form whatever the default option.

@++;
Gauthier.
graham2550
Posts: 5
Joined: Tue Jun 18, 2019 7:31 am

Re: grble-5X control panel

Postby graham2550 » Tue Jun 18, 2019 7:35 am

Can I use this on windows 10 and if so how do I install it and run it.
Thanks