Printer resetting after print upgrade from version 3.3 to 3.4.
-
I have recently upgraded from version 3.3 to version 3.4, and have a few issues. I have never seen this before, only since I have upgraded to version 3.4.
It looks like a software reset.M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0 (2022-03-15 18:58:31) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 0JD0M-9P6M2-NWNS0-7J9DJ-3SJ6S-K90RJ
Used output buffers: 1 of 24 (24 max)
=== RTOS ===
Static ram: 23868
Dynamic ram: 73160 of which 0 recycled
Never used RAM 11524, free system stack 110 words
Tasks: NETWORK(ready,26.3%,212) HEAT(notifyWait,0.1%,332) Move(notifyWait,0.5%,283) DUEX(notifyWait,0.0%,24) MAIN(running,73.1%,440) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:54:59 ago, cause: power up
Last software reset at 2022-03-18 12:04, reason: User, GCodes spinning, available RAM 14524, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
Step timer max interval 0
MCU temperature: min 30.3, current 32.5, max 39.1
Supply voltage: min 23.9, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/68/68, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min 0
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min 0
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10:
Driver 11:
Date/time: 2022-03-18 20:35:19
Cache data hit count 4294967295
Slowest loop: 179.97ms; fastest: 0.14ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.1ms, write time 4.5ms, max retries 0
=== Move ===
DMs created 83, segments created 28, maxWait 282993ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 1628, completed 1628, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], 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
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== DueX ===
Read count 1, 0.02 reads/min
=== Network ===
Slowest loop: 203.96ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 2 of 8
Interface state active, link 100Mbps full duplex -
Was that M122 gathered after the reset?
Last reset 00:54:59 ago, cause: power up
That indicates it was a power cycle that caused the last reset.
Can you give more details about what issues you're seeing exactly?
-
@phaedrux
Hi Phaedrux, Since the update, there are only a few things I have noticed. M0 doesn't turn off the heaters as it did earlier with v3.3.
The printer was losing all home information on completion of a print. I tried an experiment and copied my End-Gode from Prusa Slicer to notepad, and the same with SuperSlicer and compared the two. They were the same. I deleted all content in SuperSlicer End-Gcode field, and copied and paste the content from PrusaSlicer. Guess what, it retained all home position at the end of a print. Perhaps an invisible character was in the End-gcode field. The g-code created by the slicer showed no reason for the lost home positions.I am still experiencing network dropout during prints. They are not there while the printer is idle (very random drops while sitting idle). During a print, the network drops out are quite bad. This has been an ongoing thing with my Duet 2. This is reproducible.
This is my working End-GCode
; Run custom end G-code G91 ; use relative positioning G1 Z5 F1000 ; Drop Bed 5mm G90 ; use absolute positioning T-1 ; Drop off the tool G29 S2 ; Disable Mesh Compensation. G1 X5 Y5 F10000 ; Park gantry M140 H0 ; Set bed heater to 0 M568 P0 R0 S0 ; Set T0 off M568 P1 R0 S0 ; Set T1 off M568 P2 R0 S0 ; Set T2 off M568 P3 R0 S0 ; Set T3 off
-
-
@trobison said in Printer resetting after print upgrade from version 3.3 to 3.4.:
M0 doesn't turn off the heaters as it did earlier with v3.3.
Where did you have M0 in your end gcode?
-
@phaedrux It was on the last line of end gcode. This configuration was working for many months at version 3.3. After the upgrade, it stopped working. I tried typing a M0 command into the console after the print job was completed and the heaters failed to turn off. The M0 command did nothing, the heaters remained at their standby temps.
I the end I have commands that turn off all heaters in the end gode. It works, but I thought a simple M0 should work. -
@trobison said in Printer resetting after print upgrade from version 3.3 to 3.4.:
I thought a simple M0 should work.
Yes you're not the first person to notice a difference in behaviour with M0. There was a change noted in the release notes of 3.4 but I don't know if it's behaving as expected right now.