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.
GRBL new post processor with drill cycles G81..G83
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- sliptonic
- Veteran
- Posts: 3457
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: GRBL new post processor with drill cycles G81..G83
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?
- sliptonic
- Veteran
- Posts: 3457
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: GRBL new post processor with drill cycles G81..G83
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.
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.
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.
Re: GRBL new post processor with drill cycles G81..G83
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 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.
Re: GRBL new post processor with drill cycles G81..G83
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.
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.
Re: GRBL new post processor with drill cycles G81..G83
We could put to the vote the choice to keep the two options or to delete the default one...
Re: GRBL new post processor with drill cycles G81..G83
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.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.
Re: GRBL new post processor with drill cycles G81..G83
since the other args do not have negated forms, it is probably clearer to be consistent.
Re: GRBL new post processor with drill cycles G81..G83
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.
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.
-
- Posts: 5
- Joined: Tue Jun 18, 2019 7:31 am
Re: grble-5X control panel
Can I use this on windows 10 and if so how do I install it and run it.
Thanks
Thanks