I’ve been playing with plotting lately and for the last week or so I’ve been struggling to understand and fix the stuttering and slow drawing behavior.
This is something I have seen several people encounter. At first I thought it was due to a very large number of very small movements, which in theory could saturate the 250kbps USB link between the PC and RAMPS. But actually calculating the expected throughput throughput (in one case for movements of about 0.1 mm) seemed to show that the 250kbps throughput is not close to saturation and can’t explain the stuttering.
Now I’m seeing stuttering and slow behavior with an extremely low command rate, so there is no way this could be the USB link. This particular file (attached) has G2/G3 arc commands which Marlin internally splits into many small segments. So I began to think perhaps it was the CPU or some internal per-segment rate bottleneck. I tried a number of settings in Marlin and none of them seemed to make a difference. These are the things I tried:
- Minimum segment time (M205 B<nnn>)
- Disable JUNCTION_DEVIATION (uses jerk method instead I guess?)
- Increase BLOCK_BUFFER_SIZE (processed movement queue)
- Increase BUFSIZE (unprocessed lines of g-code)
- (I tried increasing jerk but I don't think I did it right)
- Disabled G2/G3 in Estlcam, lots of short straight segments produced almost identical behavior
- Tried increasing MM_PER_ARC_SEGMENT and other values for coarser arcs
I am thinking it is something similar to minimum segment time, perhaps not the M205 setting but something else that is having the same effect.
I’m going to keep looking but I am also wondering if anyone has any other thoughts or suggestions for something I haven’t tried.
ocrb_hand2.gcode (31.3 KB)