Bug in Pause/Resume when running Duet3 Mini5+ wifi in SBC mode?
-
Hi,
I've recently added an R.pi 3 model B+ v1.3 as an SBC using the Duet3D pi image burnt to a brand new 32gb Sandisk Extreme Pro class 10 A1 sd card. It's running the latest stable firmware (3.4.5). This has been working great... up until the point where I paused a print mid-print using DWC (3.4.5 - note I do not have a PanelDue or other display attached, this was done through Chrome). The pause process worked, and ran my pause.g. When I clicked resume, it ran resume.g, moved the print head back to the last position, and then simply stopped where it was without actually resuming the print.
The status in DWC had changed from "paused" to "printing", but it wasn't moving, and whilst DWC was working (i.e. I could browse to different tabs), any direct printer controls became unresponsive (so I was unable to get an M122 output). In the end I had to do an emergency shutdown.
The same pause.g/resume.g was working perfectly when I was running without the SBC attached in standalone mode.
Has anyone else experienced this, or is it a known bug, and what's the fix?
pause.g
; ========================================================================================================= ; pause.g ; ========================================================================================================= M98 P"0:/macros/03-Turn_Lighting_On" ; turn the lighting on if heat.heaters[1].current > heat.coldExtrudeTemperature ; check extrude temperature M83 ; relative extruder moves G1 E-2 F3600 ; retract 2mm of filament M98 P"0:/sys/00-Functions/ParkingPosition" Z50 ; move to the parking positionparkingPosition
; ========================================================================================================= ; moves to the parking position ; param.Z is the absolute target height in mm ; ========================================================================================================= M98 P"0:/sys/00-Functions/zLift" Z5 ; call macro to lift z if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed M98 P"0:/sys/00-Functions/zLift" Z5 ; call macro to lift z again else G90 ; set absolute positioning if (move.axes[2].machinePosition < param.Z) ; if z position is below target height G1 X125 Y-3 Z{param.Z} F6000 ; go to the parking position else G1 X125 Y-3 F6000 ; go to the parking position M400 ; finish all moves, clear the bufferresume.g
; ========================================================================================================= ; resume.g ; ========================================================================================================= M98 P"0:/sys/00-Functions/CurrentSenseNormal" ; ensure the drivers current and sensitivity is set for normal routines if heat.heaters[1].current > heat.coldExtrudeTemperature ; check extrude temperature M83 ; relative extruder moves G1 E2 F600 ; extrude 2mm of filament (now being able to pull that away) G1 R1 X0 Y0 Z5 F2000 ; go to 5mm above position of the last print move G1 R1 X0 Y0 ; go back to the last print move M83 ; relative extruder moves if heat.heaters[1].current > heat.coldExtrudeTemperature ; check extrude temperature G1 E0.6 F300 ; extrude 0.6mm of filament M121 ; recover the last state pushed onto the stack M98 P"0:/macros/04-Turn_Lighting_Off" ; turn the lighting offmacro 3 and 4 turn on an io which I have connected to a relay to turn the LED strip lighting on and off. The resume script seems to run up to the end, as the LED lighting was turned off, but nothing happened after that point.
I should also point that a resurrect.g file seemed to be created in the sys folder with the following content:
; File "0:/gcodes/V2_Small_Trays_0.25mm_PLA_E0.974_MK2.5S_7h0m.gcode" resume print after print paused at 2023-05-16 14:40 G21 M140 P0 S70.0 G29 S1 G92 X204.716 Y14.845 Z0.250 G60 S1 G10 P0 S220 R220 T0 P0 M98 P"resurrect-prologue.g" M116 M290 X0.000 Y0.000 Z0.000 R0 T-1 P0 T0 P6 ; Workplace coordinates G10 L2 P1 X0.00 Y0.00 Z0.00 G10 L2 P2 X0.00 Y0.00 Z0.00 G10 L2 P3 X0.00 Y0.00 Z0.00 G10 L2 P4 X0.00 Y0.00 Z0.00 G10 L2 P5 X0.00 Y0.00 Z0.00 G10 L2 P6 X0.00 Y0.00 Z0.00 G10 L2 P7 X0.00 Y0.00 Z0.00 G10 L2 P8 X0.00 Y0.00 Z0.00 G10 L2 P9 X0.00 Y0.00 Z0.00 G54 M106 S0.00 M106 P0 S0.00 M106 P2 S1.00 M116 G92 E0.00000 M83 M486 S-1 G17 M23 "0:/gcodes/V2_Small_Trays_0.25mm_PLA_E0.974_MK2.5S_7h0m.gcode" M26 S3589 G0 F6000 Z2.250 G0 F6000 X204.716 Y14.845 G0 F6000 Z0.250 G1 F1440.0 P0 G21 M24I'm not sure what resurrect-prologue.g is, it doesn't exist in the sys folder.
The gcode filename has '.'s in the name: 0:/gcodes/V2_Small_Trays_0.25mm_PLA_E0.974_MK2.5S_7h0m.gcode, are there any limitations with that?
-
Is this repeatable with your pause resume files?
Can you test with simplified pause resume that don't contain any conditional statements?
-
Yes, it seems repeatable. I initially discovered the issue when the filament sensor triggered after a filament runout. It paused, let me change the filament, resumed and stopped once the light went off. So I subsequently tried just pausing from DWC.
I was planning on simplyfying everything to see if it is my resume script. I was also going to change the filename to remove the '.' in case it was that.
-
Simplified both pause.g and resume.g to just move the print head to the parking position without calling any macros, and the printer hangs on resume as before. Note, that I mispoke earlier, DWC is responsive I can browse to the different tabs, however any printer controls are not responsive - e.g. sending a gcode like M122 or trying to change the nozzle temperature.
I also tried renaming the gcode file to "short.gcode", again it hangs on resume as before.
I got an M122 result whilst it was paused.
m122 === Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.4.5 (2022-11-30 19:41:16) running on Duet 3 Mini5plus WiFi (SBC mode) Board ID: R4MQT-XP6KL-K65J0-409NY-3Q02Z-HYPA6 Used output buffers: 1 of 40 (12 max) === RTOS === Static ram: 103652 Dynamic ram: 99248 of which 0 recycled Never used RAM 35764, free system stack 134 words Tasks: SBC(ready,1.5%,434) HEAT(notifyWait,0.0%,345) Move(notifyWait,0.1%,267) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.0%,341) TMC(notifyWait,0.7%,115) MAIN(running,95.9%,547) IDLE(ready,0.9%,30) AIN(delaying,0.8%,265), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:05:43 ago, cause: software Last software reset at 2023-05-16 22:16, reason: User, GCodes spinning, available RAM 35500, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x00 MCU revision 3, ADC conversions started 343814, completed 343812, timed out 0, errs 0 Step timer max interval 1491 MCU temperature: min 36.7, current 37.6, max 38.4 Supply voltage: min 23.6, current 23.8, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/656/550, gc cycles 1 Events: 0 queued, 0 completed Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 211, reads 18052, writes 22, timeouts 0, DMA errors 0, CC errors 0 Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 209, reads 18052, writes 22, timeouts 0, DMA errors 0, CC errors 0 Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 208, reads 18052, writes 22, timeouts 0, DMA errors 0, CC errors 0 Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 210, reads 18051, writes 22, timeouts 0, DMA errors 0, CC errors 0 Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 126, reads 18059, writes 15, timeouts 0, DMA errors 0, CC errors 0 Driver 5: not present Driver 6: not present Date/time: 2023-05-16 22:22:33 Cache data hit count 656382545 Slowest loop: 569.28ms; fastest: 0.09ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 0.0MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === DMs created 83, segments created 8, maxWait 113597ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 565, completed 565, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.4 Heater 1 is on, I-accum = 0.3 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File* is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty === Filament sensors === Extruder 0 sensor: ok === CAN === Messages queued 3065, received 0, lost 0, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 1719/0/0 Tx timeouts 0,0,1718,0,0,1345 last cancelled message type 30 dest 127 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 14631/14631 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0f1bc Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server v3.4.5 File /opt/dsf/sd/gcodes/short.gcode is selected, paused Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 42.82, max time between full transfers: 82.4ms, max pin wait times: 76.6ms/30.0ms Codes per second: 1.39 Maximum length of RX/TX data transfers: 3416/1364 16/05/2023, 22:22:32 M25 Printing paused at X192.5 Y35.0 Z0.2 -
I've just tried in standalone mode, I've just uploaded the exact same system set to a different 32Gb SanDisk Extreme Pro SD card, and the pause/resume works. But SBC mode still does not work.
-
@jgrg1 thanks, one for @chrishamm to look at.
-
undefined Phaedrux marked this topic as a question
-
undefined Phaedrux has marked this topic as solved
-
@Phaedrux Hi, it's not resolved. The issue still remains in SBC mode. The issue is not present in standalone mode.
-
undefined dc42 has marked this topic as unsolved
-
Sorry, I think I marked the wrong thread.
-
@jgrg1 I am unable to reproduce this problem. When it gets stuck, can you obtain an output from
M122 "DSF"? That should complete after a few seconds.Also, do you have any other plugins installed?
-
@chrishamm Apologies, only just saw this.
When it gets stuck, if I Send Code M122 via DWC, the UI displays a spin/wait graphic, but does nothing, and there is no response.
Is M122 "DSF" different? Is it possible to do this via a USB connection and YAT?
I have the following integrated plugins:
Accelerometer (stopped)
Height Map (started)
G-Code viewer (started)
Object model browser (started)
On-Screen keyboard (stopped)And External plugins:
DuetPi Management plugin (started)I'm using the https://pkg.duet3d.com/DuetPi.zip image that I burnt uising balenaEtcher. I also did the sudo apt upgrade, and sudo apt dist-upgrade after installation.
The below is the output of M122 "DSF" when it is not stuck - it's actually printing right now:
M122 "DSF" === Duet Control Server === Duet Control Server v3.4.5 File /opt/dsf/sd/gcodes/ShelfSupport_Triple_0.25mm_PLA_E0.974_MK2.5S_2h53m.gcode is selected, processing File: Buffered code: G1 E.5 F2100 Buffered code: M204 P1200 Buffered code: G1 F3600 Buffered code: G1 X81.429 Y103.504 E.04466 Buffered code: G1 X80.813 Y103.452 E.02494 Buffered code: G1 X82.014 Y104.653 E.06853 Buffered code: G1 X81.986 Y105.189 E.02166 Buffered code: G1 X80.002 Y103.205 E.11324 Buffered code: M204 P1000 Buffered code: G1 E-.5 F2100 Buffered code: G1 Z1.45 F720 Buffered code: G1 X80.285 Y92.775 F7200 Buffered code: G1 Z1.25 F720 Buffered code: G1 E.5 F2100 Buffered code: M204 P1200 Buffered code: G1 F3600 Buffered code: G1 X79.694 Y92.183 E.03375 Buffered code: G1 X79.635 Y92.688 E.02052 Buffered code: G1 X80.066 Y93.119 E.02458 Buffered code: G1 X80.007 Y93.624 E.02052 Buffered code: G1 X79.576 Y93.193 E.02458 Buffered code: G1 X79.517 Y93.698 E.02052 Buffered code: G1 X79.948 Y94.129 E.02458 Buffered code: G1 X79.889 Y94.634 E.02052 Buffered code: G1 X79.458 Y94.203 E.02458 Buffered code: G1 X79.399 Y94.708 E.02052 Buffered code: G1 X79.83 Y95.138 E.02458 Buffered code: G1 X79.771 Y95.643 E.02052 Buffered code: G1 X79.34 Y95.213 E.02458 Buffered code: G1 X79.281 Y95.718 E.02052 Buffered code: G1 X79.712 Y96.148 E.02458 Buffered code: G1 X79.653 Y96.653 E.02052 ==> 1416 bytes Code buffer space: 2688 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 2.87, max time between full transfers: 142.6ms, max pin wait times: 94.5ms/31.9ms Codes per second: 0.61 Maximum length of RX/TX data transfers: 3100/1464 -
@jgrg1 Yes,
M122 "DSF"is handled exclusively by DSF and the output would be only useful if I got it at the time the printer got stuck. I suspect there is already a bug fix for this issue in the upcoming v3.4.6 version. -
Just plugged a touchscreen into the raspberry pi, and tried to reproduce the issue. Behaviour is the same. The Duet website seems to hang. The raspberry pi is still responsive, so I think it's the Duet board itself that hangs.
