Yesterday, I published the Grbl post processor with G81..G83 drill cycles translations on my Github account here : grbl_G81_post
This more efficient updated version (full rewrite) is ready for Python 3 (work in Python 2.7 and Python 3), and it is able to handle the speed units convertion beetwen FreeCAD (mm/s) and Grbl gCode standard (mm/mn).
On this Github, you can also found my Grbl fork: grbl-Mega-5X
This is a Grbl-Mega enhancement wich add the ability to :
handle 3 to 6 axis,
chose the name of each axis from X, Y, Z, A, B or C,
clone one axis name movement to 2 or more motors drivers (by chosing the same name for more than one axis),
Finally, you will also find on my Github account, the cn5X++ control panel, a new 5/6 axis Grbl control panel whose purpose is to implement all the grbl-Mega-5X capabilities…
cn5X ++ is still in active development, but it is starting to be used to drive a CNC mahine.
I hope this will interest the community, and this lay a first stone of 5 axis CNC milling with FreeCAD…
I’ve only glanced through the code, not actually tried running it but this looks good. I would suggest preparing a pull request so we can test it formally and discuss merge.
Thanks, it was a misunderstanding on my part. I thought this was intended to replace the old “grbl” which does not produce code suitable for GRBL. I did not realise that it had been installed in parallel as a separate post processor. Sorry for the noise.
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?
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.
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.
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.
