A square frame is much more simple in Gcode.
The G codes are line segments. Here G1 is spindle-on-move from where we are to (X…Y…) X motor and Y motor both move.
at one vertex, during circular framing the G-codes are
G1X45.875Y35.057
G1X47Y35
G1X48.125Y35.057
at the same vertex, during circular engraving the G-codes are
G1X47.566Y35.014
G1X47Y35
G1X46.434Y35.014
The engraving steps are much smaller.
No need to be sorry - It’s welcomed here. It’s important to be able to ask questions in a safe place so knowledge and discovery can be shared.
It’s a fine investigation you’re doing. I just want to point out, the problem / phenomenon with these strange movements of “round object framing” also happens to DSP machines, (at least for my KT322N). It’s not just G-code related. Thanks
The circle frame vectors are generated with a lower curve resolution than when the job is actually run. This is because non-GCode systems, like Ruida, don’t use their motion planner for framing moves - they just run each move as a single line, do a full stop, then run the next one.
If I generate extremely short lines, this results in severe shuddering on that hardware. This is what Bernd and others with Ruida controllers see when using the O-Frame. By reducing the curve precision, we emit fewer overall line segments, so the controller does fewer full stops and doesn’t shudder as badly.
On GCode systems, the framing moves do go through the motion planner, so I can alter the code to check which type of controller you’re using and adjust the output accordingly - smoother curves for GCode systems, coarser ones for DSPs.
I sat bolt upright this morning in bed thinking that i should repeat the test calling for an engrave speed of 6000 mm/min to see if the motion planner generated longer line segment lengths based on speed.
Edit: The engrave segment length does not change when the engrave speed is changed to 6000 mm/min and the $110 x-rate, $111 y-rate are both set to (machine default) 800mm/min.
Further the engrave segment length does not change when the engrave speed is set for 6000mm/min and the $110 x-rate, $111 y-rate are both set to 6000mm/min.
For a GRBL machine the machine jitter during framing is related to segment length and Speed as commanded by the Move window.
I didn’t run the steppers or the laser. I just wanted to see if or how the speed settings affected segment length. They didn’t.
Thanks for all the insight John, I can balance the “frame” speed to a point where it will not jiggle, but then it affects my overall object to object speed. So … Ill just live with it. Just glad I am not nuts.
I’m not certain I agree. The speed in the move window is the framing speed or traverse speed that’s ‘called’ when framing or jogging but unlike the G1 move it’s not explicitly applied to the G0 move in the G-code. Since the 6000 mm/min doesn’t show up in the console settings I can’t understand how or why the G-code controller would apply it to G0.
Some further reading tells me that the max speeds set in the controller aren’t exceeded. Just because we say 6000 (or 2973) - doesn’t mean that’s what we’re getting.
I believe that you can slow your speed in the move window and that it would change frame and jog operations and that the speed of those operations would not be allowed to exceed the maximum allowed traverse speeds ($110, $111, $112) in the controller.
I believe regular G0 move applies the maximum travel speed as its default unless it’s told otherwise. I feel the 8000 mm/min ($110 & $111 in your case) is high and might have just lucked into a resonance with the right sized circle.
Changing your $110 and $111 will change your object to object speed limit but you can call a slower number for Jog and Frame if you like.
Engraving at a speed lower than your maximum never jittered the machine because it was slow enough.
