Voron 2.4 duet 5 mini pauses every 12 seconds when printing
-
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#daemonge.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 -
@T3P3Tony Thanks for the tip.Will try this out.
I think this can be marked as solved (not sure how to do that). -
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
M150calls into daemon.g directly. -
@infiniteloop yeah good point
-
undefined T3P3Tony marked this topic as a question
-
undefined T3P3Tony has marked this topic as solved
-
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 loopingI'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 thatM150in my daemon.g is executed? -
@cdoe try commenting those out in daemon.g for now and see if the pauses go away.
-
undefined T3P3Tony has marked this topic as unsolved
-
@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 -
@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.
-
@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?
-
@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
-
undefined Phaedrux has marked this topic as solved
-
@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.
-
@gloomyandy thanks for the update. Appreciate tracking this one down
