Micro stutter on circles

I have replaced stock anet board with SKR 1.3 with tmc 2208 drivers on xyz and lv8729 on extruder. I am running Marlin 2.0.

When printing circles (I think it is happening more with smaller, about 2.5cm diameter) I get a micro stutter which results in zits on the surface. I am printing from sd card.



I thought that 32 bit boards should have no problem processing gcode to print a circle. I had better results with stock anet A8 8 bit board. I have attached my Marlin config files if anyone would like (and would be kind) to look at. Is there something wrong with my settings?

I use Prusa slicer.

Config files say BOARD_RAMPS_14_EFB another 8 bit board. wrong config file?

Whats the segment size on the circles, you can still have buffer under runs on 32 bit boards....

Are you using SD on the skr.13 or on a display (if its a 12864 glcd the sd has share time on the SPI bus with the display)

you could try increasing BLOCK_BUFFER_SIZE

Have you tried bugfix to see if the it was a bug and it has already been solved? The config files give a version of 020000 which is old now...

Edited 2 time(s). Last edit at 04/30/2020 07:38AM by Dust.

I am so sorry I have attahed wrong config files to my first post.

This one has the correct files attached.

I am printing with the sd card pluged to the slot on the main board (SKR 1.3) through extension cable.

Could you please look at my config files just to check that if I have not missed something obvious?

I will try to increase buffer size. Any sugested walue for SKR 1.3?

Do the blobs happen when you use a different slicer? Maybe there is a line of Gcode that causes the micro-stutters.

Thank you Dust

After upgrading to the latest version of Marlin 2.0.5.3 and increasing the BLOCK_BUFFER_SIZE to 64 and SLOWDOWN divisor to 4 no more stuttering!

whould there be any advantage of setting BLOCK_BUFFER_SIZE to 128? SKR 1.3 has enough memory to do it, the question is are there any benefits of doing so...

Whether there is an advantage or not depends heavily on your specific circumstances and what you're printing. There is a disadvantage, though, which is that the larger the BLOCK_BUFFER_SIZE the longer it takes for cancelling the print to take effect, since the printer will empty the buffer before stopping. So you could have a few seconds of printing occur after you cancel, specially if you're printing over the serial/USB port (OctoPrint, for example).

With EMERGENCY_PARSER you can send an M112 to do an emergency stop that will bypass the buffer.