I have my mpcnc (grbl) setup in firmware with max X and Y acceleration of 50mm/s2. I also verified the eeprom parameters match. Jogging around and generally cutting it moves smoothly with little to no jerky action. Recently I added a quick rectangle cut to outline an image etched with a laser. The gcode generated by lightburn looks like this:
When it hits the first 3 corners, it bangs around them pretty hard. I expect it to gently decel/accel going in and out of the corners. However, it only slows down only when it approaches the final corner. Besides being hard on the machine, this leaves ringing artifacts just like a printer with high jerk. It also artificially limits cutting speed, as going too high could result in skipped steps when it hits a corner at speed like that.
Can anyone explain why this is happening? I thought jerk was just for printers, and cnc are not supposed to do that.
I figure it may be because the gcode is very simple, and for other operations that run smoother maybe what looks like a straight line between 2 points is broken up into several points of varying feedrate. IDK as I haven’t analyzed gcode in that detail yet, and don’t recall a setting in CAM for that anyways. Maybe it has to do with some off setting in GRBL? Is there some setting that allows the control to override max accel? …or conversely is there some gcode I need in the header to ensure max acc is always obeyed?
Looks like a lower $11 - Junction Deviation may be the fix for this (mine is set to 0.02, looks like 1.1 default should be 0.01… not sure how that happened!). That article also links to an interesting wordpress article, great for those curious about how cornering actually works.
Well, 0.01 didn’t seem to help much if at all. I will play with rectangles and $11 this afternoon after it’s done etching a photo. If I get anywhere with it I’ll report back.
Even dropping to $11=0.0001 was not enough to cure the jerky corners. I also tried dropping my xy accel to 50 from 127 and saw no changes with varied $11. I tried resetting eeprom and ran through the test matrix a second time with the same results.
I thought it may be some weird interaction with inch mode. So I tried it with G20 and no change.
Then I tried it with M3… same thing.
What is it with this g-code? I must be trippin! (BTW G90 M5 M9 goes at the end, but I cropped the thousands of image etch lines that after the jerky square).
[edit: I realized I have a script I use in bCNC that is very similar to this jerky square, which does not jerk. It uses G90 though… and get’s the coordinates from itself as the sender. Working with G90 based files though, is a pita and not a solution for this. At any rate, to be complete that script looks like this:
This is looking like a bug in GRBL. I just ran this gcode and it did exactly what it was supposed to, slowing into corners and getting around the rectangle very smoothly:
So there is something about those small moves near the corners in the gcode I put in the OP, that was throwing the planner off. In my mind, it seems it may be seeing the short large angle move as too large an angle to slow down for, then it is followed up by another very small move in both x and y, then goes off along y… that small in between xy move should trigger a decel in the planner, but for some reason it is not. On the surface, it looks like there may be some issue with numerics… small moves may have their “virtual radius” miscalculated as a result. It is like the planner sees the small move, miscalculates it as a low angle that does not require decel (so no decel at the end of the first long x move), then it looks at the next move (large Y move), and again the angle between that line and the previous tiny move also gets miscalculated so again no decel. Perhaps some extra bits of resolution may be required to handle very small moves like that… or at the very least a sanity check that adds decel/accel if a very small move comes up (I know this may lead to jerky slowness for complex details though).
This issue is a big problem when using lasers to cut items with profile paths. You will get a jerky corner anytime you have large sharp angle linear moves divided by one or 2 very small moves. It explains now why some of the slots on my cut pieces are not perfectly formed (slots that have 4 sharp corners about 1/4" from each other). Most CAM software adds a lot of “junk” near the corners like that (similarly, they do this due to numeric limitations), and not sure how easy it would be to modify things on the CAM end to fix this. Maybe there is some tolerance setting in lightburn that could fix this?
Can anyone else verify this behavior? Now I am also curious if this happens with Marlin as well. I am guessing they use totally different planner methods. I am thinking I need to submit an issue report on this, but not sure that will help… here’s why.
My other thought is, lowering junction deviation should theoretically fix any issues with tiny moves. However going down to 0.001 didn’t do it for this gcode. Perhaps it is possible to calculate the required deviation value given the size of the smallest move in a gcode file? That would be fairly easy to control in cam anyways. Then I wonder if that number had to be say 0.00005… would that lead to other problems with low resources? I think maybe this is the elephant in the room here with the way junction deviation works in general. There may be some reason processing correctly with jd=0.0001 just does won’t work, and maybe rethinking the whole planner would be required to fix it… or perhaps esp32 has tricks up it’s sleeve and we see 0.00001 default soon? IDK