Overloading the Duet 3 Mini 5+ with commands, causing stuttering

Phaedrux

Have you tried running a print without the daemon.g code?

Is it always on curves?

VirtualBrown

@Phaedrux Yes always on curves, and only with many parts on the bed and later in the print, like there's a cashe of memory that's getting filled.

Its difficult to replicate as it requires the need to print quite a few curved parts (ovals or cylinders are the main culprits)...

I can try with the deamon off, or is there a way to decrease the frequency which it runs?

Phaedrux

The default time for daemon.g to run is 10 seconds. To make it longer you can add a G4 delay at the end for longer than 10 seconds. Ex: G4 S20

droftarts

@VirtualBrown It may be worth checking your SD card; it may be a slow read speed on Gcode with particularly short movements (ie curves with fine slicer resolution) is causing queue starvation. Check what class your current SD card is, how full it is, and what the read speeds are by seeing this page: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues
We recommend SD cards of the following specification: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#specification

Ian

VirtualBrown

@droftarts Interesting, so the SD card is the original that came with the board and the interface speed looks as expected: 22.5 MB/s

But the read write test is very slow:
SD write speed for 10.0MByte file was 0.43MBytes/sec
Testing SD card read speed...

Doesn't seem to ever finish the read test.

Not much free space either:
SD card in slot 0: capacity 7.95GB, partition size 0.26GB, free space 0.06GB, speed 22.50MBytes/sec, cluster size 512 bytes

I'm not sure where its all gone, I regularly delete all the jobs.

Could be a nice fix as I have another 32 GB SD card, once I format it as FAT 32 do I just copy all the files over? Can I reformat it using Mac OS?

Phaedrux

Your original card likely has a double partition arrangement. One for use with an SBC, and another smaller for use in standalone.

I'd suggest using a new, larger, faster card.

I would suggest using the official SD card association formatter tool. https://www.sdcard.org/downloads/formatter/

You can then copy the existing files from the SD card across. Keep it as a backup.

infiniteloop

@VirtualBrown said in Overloading the Duet 3 Mini 5+ with commands, causing stuttering:

once I format it as FAT 32 do I just copy all the files over? Can I reformat it using Mac OS?

Sure - works fine

droftarts

@VirtualBrown Also see my post here about SD cards bigger than 32GB: https://forum.duet3d.com/topic/36414/using-sd-cards-with-capacity-32gb

Ian

VirtualBrown

Thanks everyone for your help, it looks like a new SD card has fixed the problem, which is great!

droftarts

@VirtualBrown Looking back at the M122 report you posted, I see:

=== DDARing 0 ===
Scheduled moves 2526188, completed 2526188, hiccups 0, stepErrors 0, LaErrors 0, Underruns [302, 1, 1064], CDDA state -1

It's the Underruns [302, 1, 1064] that will have been causing pauses.

The first underrun number is the number of 'lookahead' underruns, i.e. there were not enough spaces available in the move queue to do full lookahead. This type of underrun causes movement to be slower when there are very many short decelerating segments in succession. This should not cause a pause/stutter.

The second figure is the number of 'prepare' underruns. This indicates that the step interrupt service routine wanted another move, but although there was one it had not been prepared for execution. If the SD card was struggling to supply the next move, the processor may not have had time to prepare it for when it was needed. This may cause a stutter.

The third figure is the number of "no move" underruns. This indicates that the step interrupt routine wanted another move but none was available. If the SD card couldn't supply the next move in time to even be prepared, this will cause a stutter.

To check everything is okay now, start a print job, send M122. This will clear any existing errors. At the end of the job, send M122 again and see if it reports any of the above errors.

Probably just reformatting your original card would have cured it; I expect it was just running out of space, and causing files to be fragmented and taking longer to read.

Ian