I noticed, that with higher acceleration and higher jerk/junction deviation, I get a more constant flow and so automatically get rid of any blobs and overextrusions at the end of a track. Higher settings also affect the “round corners” and toplayer quality in a good way.
I did build a very small and very rigid printer and the printhead can move flawlessly with acceleration-settings of up to 12.000mm/s² and junction deviation of 0,5mm. At this settings I can print at 80mm/s without any visible ghosting/ringing. The extrusion at this point is very constant in terms of “the extruder gear is turning at a constant speed” for the whole layer as far as my eyes can tell.
Now, my question is: Is there a way to calculate the possible maximum velocity for given acceleration and jerk/junction deviation settings? I do not want to know the max top-speed (this is 833mm/s for my printer and capped by the internal clockspeed), instead I want to identify the max speed where little to no acceleration happens.
The goal is to get to the point where the printhead is moving with constant speed the whole time, no matter what circle or corner is printed.
Another thing to consider is that when your acceleration is so much higher than your feedrate, there may only be a negligible number of steps in the acceleration period.
Wait so you actually increase the jerk number to eliminate “jerking motion” my printer when it comes to smaller circular movement would jerk alot so naturally, I lowered the jerk setting number but it never really make any noticeable change…
“Jerk” is badly misnamed. It’s not the proper physics definition of jerk (change in acceleration) nor particularly intuitive. What it SHOULD be called is “max corner velocity jump” or something like that. It is how much “instantaneous” velocity change is allowed at the corner between two gcode segments. So if it’s zero, the motion planner slows to a stop at every corner. If it’s arbitrarily high, the motion planner won’t decelerate at all and you get constant-speed operation. Which is very “jerky.”
BUT, for the case of “jerking” on arcs, that’s much more likely the motion planner running into problems (such as empty queue stuttering) because of the high rate of very small gcode commands. GRBL-based motion planners don’t “see” finely-faceted arcs because there isn’t enough change in direction at each corner to trigger the slowdown algorithm.