Bug in Pause/Resume when running Duet3 Mini5+ wifi in SBC mode?
-
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.
