I tossed that in there in my fork, no idea if it will ever make it to the main branch, for now it’s just a place to store it on the internet. Github is a rather complicated thing, I have been just editing the file in place. I’d ask for help in the FreeCad forums, but I like my liver where it is.
The code should be fine, haven’t tested it, but I will find out eventually if it crashes something. I didn’t notice it as the projects I have been using haven’t used G0 for much more than the initial move and Z up or down.
I am using FreeCAD on a chromebook, path for a flatpak install for me is:
/var/lib/flatpak/app/org.freecadweb.FreeCAD/current/active/files/freecad/Mod/Path/PathScripts/post
Thanks for this! I am just learning how to do paths in freecad, and the GCode I made with the grbl post processor kept ignoring the Z axis position I was setting and started “drawing” way up in the air. Marlin version isn’t doing that. Not sure if it was the post processor or my tool defs. Lots to learn here!
Thanks @jeffeb3. I came across the coordinates link yesterday. Manually dialling in home and using G92 to zero all axis seems to be the sickest thing to do for now.
Can someone please explain to me why this postprocessor divides all feedrates by 60 (effectively making them in mm/s)? My Marlin expects feedrates in mm/min and I had to remove all /60 from the postprocessor.
Great job doing this Post-Processor! Thanks A LOT!!!
Correct me if I am wrong, but I noticed that when using the drilling operation with multiple holes (G81), the path in freecad simulator is showing a straight line at the same Z height when travelling between holes. However, when I put it on the CNC (and checked with Pronterface to confirm), the travel from one hole to another is changing the height continuously. If I am not wrong, it seems to travel and change the height from safety to clearance height instead to be at a fix clearance height.
Noticed the same behaviour on the first move of the job. The bit is going up to safety height and then move to the first position in X-Y while increasing the height from safety to clearance height instead to immediately go up to clearance height.
This could lead to a crash in holding brackets of the stock.
P.S. I tried to put pictures in this text, but as I am a new user, it doesn’t allow it :-(.
Noticed as well that in the October 21 version of the Marlin_Post.Py, the rapid move it showing this an incorrect conversion (using the value from the initialization in the py file instead) once processed:
I will have to lookat that further, I think it is a bit of Marlin behavior to work around with a movement split / inserted wait for completion like statements, bit of handholding. Unless I added a bug, it is what freecad outputs verbatim.
Not so much a conversion, but defensive override, freecad can send along some nonsense at times and marlin doesnt use g0 feedrates, it is a firmware constant, last going off anyway, I set the z speeds in the file itself, the values are a bit low so increasing feedrate doesn't make z too fast. I am using steeper threaded Z rod so it doesnt do the low rider thing.
I put in what gave me the gcode output I expected like I typed it in a terminal with the values freecad was spitting out by default. There are settings that sometimes don’t work in freecad, and marlin has a few commands that change things, mostly I am doing defensive programming, for whaver project and freecad features are working for me at the time.
Noticed Freecad outputting F0 for feedrate with G0, not sure what that even means, setting it to default instead. Previous message was incorrect, Freecad doesn’t output an M3 at all if the spindle speed isn’t set.
removed --tool-change=0 'Hold over from the base post processor, not using it since it is swapping out code instead
.
added --notoolchanges
This is useful when you have defined the same physical tool but set it up with different speeds I can use 20mm/s when doing shallow passes, when profiling through 20mm of wood, <10 mm/s…
Etches .05 mm down around entire job, offset by 5 mm. Give you a good indication of whether it is going deeper on one end or another and handy to find the middle if you need to restart due to power loss.
I didn’t notice it as the projects I have been using haven’t used G0 for much more than the initial move and Z up or down.