[BUG] Inconsistent Motion During Small Circular Movements

[SparkyDan555]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

I'm experiencing inconsistent movement when printing small circles (in this case, around the size of a coin). In some cases, the printer moves smoothly, but in others, it seems to jump or stutter, almost as if it’s buffering or waiting for the next command.

IMG_0793.mov

The printer operates normally during larger circular movements and straight lines. I suspect this may be related to how the firmware handles small arcs or curves, possibly due to a delay in command processing or a buffering issue.

I tried increasing the BLOCK_BUFFER_SIZE to 64 and SLOWDOWN divisor to 4 but this did not fix the issue.

This is not an issue on my Geeetech A10M with stock 8-bit board and almost identical configuration.

This issue creates artefacts on the outside of prints. See the prints on the right with blobs and the prints on the left are smooth as expected. These were printed at the same time as each other from the same gcode and stl file.

Bug Timeline

Unknown

Expected behavior

Small circles print smoothly.

Actual behavior

Movement is very jumpy with lots of short pauses. These pauses make the print take significantly longer than estimated.

Steps to Reproduce

1. Load a model with several small circular features (e.g., holes or rounded edges).
2. Start the print.
3. Observe the printer's motion during the circular parts of the print. Some circles will print smoothly, while others will show jerky or delayed movements.

Version of Marlin Firmware

bugfix-2.1.x Build 2024-09-06

Printer model

Creality Ender 3

Electronics

BTT SKR Mini E3 v1.2

LCD/Controller

Stock CR10

Other add-ons

No response

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

SD Card (headless)

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Archive.zip

[ellensp]

enable #define ADVANCED_OK

Log the serial console while printing

the OK response now has additional information

 *   N<int>  Line number of the command, if any
 *   P<int>  Planner space remaining  
 *   B<int>  Block queue space remaining 

you have BLOCK_BUFFER_SIZE set to 64, so you dont want to see P values >= 63 while printing
you have BUFSIZE set to 4 so you don't want to see B values >= 3 while printing.

[SparkyDan555]

enable #define ADVANCED_OK

Log the serial console while printing

the OK response now has additional information

 *   N<int>  Line number of the command, if any
 *   P<int>  Planner space remaining  
 *   B<int>  Block queue space remaining 

you have BLOCK_BUFFER_SIZE set to 64, so you dont want to see P values >= 63 while printing you have BUFSIZE set to 4 so you don't want to see B values >= 3 while printing.

I've just rebuilt Marlin with ADVANCED_OK and changed TX_BUFFER_SIZE to 32. I started a new SD print and monitored the serial console, but I don't get OK messages all the time, only on certain gcodes in the SD file. Do I need to do something to report OK periodically?

[ellensp]

sd print doesn't ok like serial..

enable
#define MARLIN_DEV_MODE
and
#define BUFFER_MONITORING

Then use D576 S5 on a serial port , this shows the same thing every 5 seconds + additional information

      /**
       * D576: Return buffer stats or set the auto-report interval.
       * Usage: D576 [S<seconds>]
       *
       * With no parameters emits the following output:
       * "D576 P<nn> B<nn> PU<nn> PD<nn> BU<nn> BD<nn>"
       * Where:
       *   P : Planner buffers free
       *   B : Command buffers free
       *   PU: Planner buffer underruns (since the last report)
       *   PD: Longest duration (ms) the planner buffer was empty (since the last report)
       *   BU: Command buffer underruns (since the last report)
       *   BD: Longest duration (ms) command buffer was empty (since the last report)
       */

you want to eliminate under runs

[SparkyDan555]

This is what I am getting whilst printing. It is mostly zero when printing the infill part of the model. The increase happens when it is printing the circular walls and when jittering occurs, then returns to zero when movement is smooth again:

D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:35 0 (0) B:0 0 (0)
D576 P:61 0 (0) B:0 0 (0)
D576 P:61 0 (0) B:0 0 (0)
D576 P:61 0 (0) B:0 0 (0)
D576 P:61 0 (0) B:0 0 (0)
D576 P:61 0 (0) B:0 0 (0)
D576 P:61 1 (58) B:0 0 (0)
D576 P:62 2 (69) B:0 0 (0)
D576 P:0 1 (57) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)

I presume these results indicate a problem which I am not sure how to fix. Thanks.

[ellensp]

SERIAL_ECHOLNPGM("D576"
" P:", planner.moves_free(), " ", planner_buffer_underruns, " (", max_planner_buffer_empty_duration, ")"
" B:", BUFSIZE - ring_buffer.length, " ", command_buffer_underruns, " (", max_command_buffer_empty_duration, ")"
);

so your results

D576 P:61 1 (58) B:0 0 (0)

So planner buffer got empty (61 free) , 1 under run error and 58ms twiddling its thumbs due to no data

D576 P:62 2 (69) B:0 0 (0)

Planner buffer got empty (62 free) , 2 under run error and 69ms twiddling its thumbs due to no data

D576 P:0 1 (57) B:0 0 (0)

buffer filled up again, but not without 1 under run error and 57ms twiddling its thumbs due to no data

Increase BLOCK_BUFFER_SIZE more, try 128

[SparkyDan555]

After I commented out the error #error "A very large BLOCK_BUFFER_SIZE is not needed and takes longer to drain the buffer on pause / cancel." from SanityCheck.h and tried again, it is still happening:

D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:70 0 (0) B:0 0 (0)
D576 P:125 0 (0) B:0 0 (0)
D576 P:125 0 (0) B:0 0 (0)
D576 P:125 0 (0) B:0 0 (0)
D576 P:125 0 (0) B:0 0 (0)
D576 P:121 0 (0) B:0 0 (0)
D576 P:124 2 (61) B:0 0 (0)
D576 P:7 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)
D576 P:0 0 (0) B:0 0 (0)