Voron 2.4 duet 5 mini pauses every 12 seconds when printing

cdoe

Hi guys,
I'm running RRF v3.5.4 on Voron 2.4 300 mm with duet 5 mini and SHTv3 toolboard. Xol toolhead with orbiter v2 extruder. Prusa Slicer is used to slice models.
I've noticed that printing staggers every 12 seconds or so - first thought was this was to let layer cool, but that was also visible on printing infill on large-ish prints as well.
SD card was changed and that had no effect (both old and new were able to produce 40mb/s reads and 10mb/s writes.
I've tried bumping up acceleration but that seems to have no effect as well. My bed compensation is tapered (over 6mm), however, pauses were also visible on layers higher than 6mm, suggesting that this is probably (don't take my word on it) not related to low acceleration for Z axis.
Attached are M122/M122 B124 outputs and my config along with gcode file.
Where/what can I look at next?
config.g.txt
M122B124.txt
M122.txt
v13_top_panel.gcode

Phaedrux

Can you try disabling the heightmap? Usually this would be a sympton of the Z axis having too low a jerk value, but that may not be the issue here.

Is there any commonality to the pauses?

cdoe

@Phaedrux Thanks for helping me figure this out..
There's no commonality i can figure out, tbh. It's also visible (in form of blobs) in vase mode as well - which from what i understand shouldn't have any pauses or layer changes at all?
Issue occurs even when heightmap/bed compensation is disabled.

I'm trying to "port" my profile to cura to see if this is a slicer issue.

resam

@cdoe are you running with an SBC / Raspberry Pi?

I recall similar issues with my printer when there was a lot of tiny moves due to high-fidelity / super smooth geometry that resulted in SPI data transfer queue issues.

I was able to work-around the issue by tweaking the SPI and transfer queue sizes in the DSF config.

cdoe

@resam I don't - setup is running in standalone mode. But that gave me an idea. I think next step would be to check if there's an issue with toolboard - maybe some sort of issue with canbus throughput?
Reslicing with cura didn't help though - still having this periodic pauses

infiniteloop

@cdoe Do you use a daemon.g file? If so, what’s its content?

cdoe

@infiniteloop
I do:

;#################### Electronics Bay Fan ###########################
if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
  M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
  M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
else
  M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
  M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

; heater 0 - bed
; heater 1 - hotend
if heat.heaters[1].current > global.hotSenseTemp
  M98 P"/macros/led/indicator_hot"
elif heat.heaters[1].current > global.warmSenseTemp
  M98 P"/macros/led/indicator_warm"
else
  M98 P"/macros/led/indicator_cold"

cdoe

@infiniteloop thank you - the issue is with daemon.g
in particular with calling macros which change led colour
Here's indicator_warm content:

; Set led on stealthburner to warm colour
M150 E0 R222 U201 B95 P96 S1 F0

T3P3Tony

@cdoe

try enclosing the whole daemon.g code in a while loop with a reasonable pause between each execution, so that the daemon is not reopening the file every ~10 seconds.
https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#daemong

e.g.:

while true
  ;#################### Electronics Bay Fan ###########################
  if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
    M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
    M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
  else
    M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
    M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3
   
  ; heater 0 - bed
  ; heater 1 - hotend
  if heat.heaters[1].current > global.hotSenseTemp
    M98 P"/macros/led/indicator_hot"
  elif heat.heaters[1].current > global.warmSenseTemp
    M98 P"/macros/led/indicator_warm"
  else
    M98 P"/macros/led/indicator_cold"
  G4 S5 ; wait 5 seconds before looping

cdoe

@T3P3Tony Thanks for the tip.Will try this out.
I think this can be marked as solved (not sure how to do that).

infiniteloop

@cdoe

the issue is with daemon.g
in particular with calling macros which change led colour

@T3P3Tony already told you how to avoid the time to permanently reopen the daemon.g file. The same is true for calling the colour-change macros. As these are simple one-liners, you might want to incorporate these M150 calls into daemon.g directly.

T3P3Tony

@infiniteloop yeah good point

cdoe

After updating my daemon.g to

while true
  ;#################### Electronics Bay Fan ###########################
  if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
    M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
    M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
  else
    M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
    M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

  ; Toolhead led based on temp
  ; unfortunately seems like this will pause move
  ; heater 0 - bed
  ; heater 1 - hotend
  if heat.heaters[1].current > global.hotSenseTemp
    M150 E0 R222 U95 B188 P96 S1 F0
  elif heat.heaters[1].current > global.warmSenseTemp
    M150 E0 R222 U201 B95 P96 S1 F0
  else
    M150 E0 R96 U223 B223 P96 S1 F0
  G4 S5 ; wait 5 seconds before looping

I'm still observing a slight pause (now every ~5 seconds).
Looking through Changelog M150 and its interaction with movement are mentioned couple of times. In particular "M150 commands are now queued to sync them with movement commands" (feature in 3.2) - and there were couple of fixes later on around that functionality is it possible that this is causing a pause?
Is there a way to check if movement buffer / queue is empty or not when that M150 in my daemon.g is executed?

T3P3Tony

@cdoe try commenting those out in daemon.g for now and see if the pauses go away.

cdoe

@T3P3Tony I did and pauses went away, so i strongly suspect it's M150 and movement buffer interaction
Just in case, here's how leds are configured (wired on sht36 toolboard):

M950 E0 C"124.rgbled" T1

gloomyandy

@cdoe As explained here in the M150 documentation:

However, when using an output other than the dedicated LED output on Duet 3 boards, in order to meet the precise timing 
requirement of Neopixel LEDs, RRF waits for all motion to stop and then disables interrupts while sending the LED data.
During this time input data from UARTs may be lost, especially if there are a lot of LEDs to update. Therefore you should use the dedicated LED port if available.

If the output device is not able to use dma to update the pixel then motion will be paused. I don't think any of the existing toolboards (either Duet3D ones or the boards supported by teamgloomy) are configured to use dma output. I think that in theory the rp2040 based boards should be able to use pio mode (a form of dma i/o) to update the pixels but that is not currently the case. I'll take a look at possibly enabling that capability in 3.6, but I will need to verify that it works ok.

For now I suggest that rather than setting the state of the pixels every time through your script loop you modify the code to track the current state of the pixels and only call M150 when things change. That should reduce how often your print needs to pause.

T3P3Tony

@cdoe ad @gloomyandy says, it looks like updating the LEDs wile printing is going on is not a good idea. Given that the lights only need to change when its changing from cold->warm->hot then an option could be to check to ensure the state.status was not "printing" and only change them using the deamon.g file when the job is not processing (i.e state.status |="processing") . That does mean that heating commands in start gcode at the beginning of a job file wont change the LEDs however you could get around that bu checking ot to the warm colour when starting to heat and then to the hot colour when heated?

cdoe

@gloomyandy @T3P3Tony Thanks for ideas and suggestions. Now it makes sense - i'll rework daemon.g to only change colour if needed rather than just blindly doing so

gloomyandy

@cdoe A quick update, it looks like this is actually a bug in RRF. The rp2040 expansion boards are actually operating in pio mode, but RRF is losing track of that information. It's only obvious if you have a rp2040 based board or are using a mainboard in expansion mode. Current Duet toolboards do not use dma for the led output so they will generate a pause anyway.

The fix is here: https://github.com/Duet3D/RepRapFirmware/commit/5127e951e9b89b9d213de74b66e0dfc261a8ea40 and should be included in furure releases.

However it is almost certainly a good idea to reduce how often you set the led state if you can.

0

dc42 committed to Duet3D/RepRapFirmware

Fixed clearing of DMA-capable flag in M150 to CAN-connected boards

cdoe

@gloomyandy thanks for the update. Appreciate tracking this one down