GCode file causes partial(?) reset
-
PS - are you running the Duet 3 with an attached SBC, or in standalone mode?
-
I am running in SBC mode and have a tool distribution board and a (single) toolboard as well.
-
Thanks, I've found the problem. When M27 is received from USB when you are printing a file from the Pi, the M27 command should be passed to the Pi for processing. I've now implemented this in RRF3.2.
-
Great find! I assume that the latest KISS V2 alpha release added M27 support.
-
@oliof said in GCode file causes partial(?) reset:
Great find! I assume that the latest KISS V2 alpha release added M27 support.
It's Pronterface that's generating the M27 commands, not the slicer.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 I am not using pronterface (my printer is not connected to anything via USB. Pi via SBC interface and a PanelDue).
-
In your original post, you said your M122 report was taken after you triggered a print using Pronterface :
@oliof said in GCode file causes partial(?) reset:
Hi,
I have a gcode file generated with the latest KISS Slicer v2 alpha which consistently soft resets the printer when I try to print it via DWC or serial console.
Here is M122 after trying to trigger a print with pronterface using M32: -
Oh true, but that was just to rule out it's DWC running into some error. The same happens without pronterface in the mix.
-
Does the GCode file you are trying to print contain M27 commands?
-
It does not, see the olm-x_end_stop.gcode I attached to https://forum.duet3d.com/post/164699
-
The firmware crash recorded in the M122 report you posted was caused by M27. But you said that was provoked by starting a file print from Pronterface. I am wondering whether you found more than one way to crash the firmware? If you did, then I need a M122 report from after it crashed in the other way.
I've put a pre-release RRF 3.2 build at https://www.dropbox.com/s/p28vp6fbnkc4rbz/Duet3Firmware_MB6HC.bin?dl=0 in which the M27 issue should be fixed.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 I can crash without pronterface, pronterface was just used to see whether this is DWC specific or not. I'll provide an M122 over the weekend from a DWC induced crash, and try the build you linked (I did a build myself but didn't get around to testing it yet).
-
Here is an M122 from a reset triggered when selecting to print a file via DWC
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA Used output buffers: 1 of 40 (13 max) === RTOS === Static ram: 154604 Dynamic ram: 162672 of which 188 recycled Exception stack ram used: 520 Never used ram: 75232 Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3424) CanSender(suspended,1428) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2868) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:20:54 ago, cause: power up Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 31.8, current 36.9, max 37.0 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.2, current 12.3, max 12.3, under voltage events: 0 Driver 0: standstill, reads 32356, writes 11 timeouts 0, SG min/max 0/1023 Driver 1: standstill, reads 32357, writes 11 timeouts 0, SG min/max 0/1023 Driver 2: standstill, reads 32367, writes 0 timeouts 0, SG min/max not available Driver 3: standstill, reads 32359, writes 8 timeouts 0, SG min/max 0/338 Driver 4: standstill, reads 32359, writes 8 timeouts 0, SG min/max 0/1023 Driver 5: standstill, reads 32358, writes 8 timeouts 0, SG min/max 0/1023 Date/time: 2020-07-10 19:42:47 Slowest loop: 5.91ms; fastest: 0.21ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 345, MaxWait: 116335ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 17, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "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. === Network === Slowest loop: 0.70ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 18347, longest wait 1ms for type 6013 === Linux interface === State: 0, failed transfers: 0 Last transfer: 16ms ago RX/TX seq numbers: 678/38571 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 27.96 -
And a other this time with some error from DCS before
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA Used output buffers: 1 of 40 (13 max) === RTOS === Static ram: 154604 Dynamic ram: 162672 of which 188 recycled Exception stack ram used: 520 Never used ram: 75232 Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3424) CanSender(suspended,1428) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2868) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:28:09 ago, cause: power up Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 36.7, current 37.0, max 37.1 Supply voltage: min 23.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0 Driver 0: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/595 Driver 1: standstill, reads 36601, writes 8 timeouts 0, SG min/max 0/1023 Driver 2: standstill, reads 36610, writes 0 timeouts 0, SG min/max not available Driver 3: standstill, reads 36601, writes 8 timeouts 0, SG min/max 0/101 Driver 4: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/993 Driver 5: standstill, reads 36602, writes 8 timeouts 0, SG min/max 0/1023 Date/time: 2020-07-10 19:50:02 Slowest loop: 5.16ms; fastest: 0.21ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 349, MaxWait: 256811ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "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. === Network === Slowest loop: 0.52ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 2575, longest wait 1ms for type 6013 === Linux interface === State: 0, failed transfers: 0 Last transfer: 19ms ago RX/TX seq numbers: 1318/52023 SPI underruns 0, overruns 0 Number of disconnects: 1 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 29.32 -
I updated the 3.2 build and now I cannot connect to the board cleanly anymore. DCS complains:
Jul 10 21:05:02 vcore-pro DuetControlServer[1692]: [fatal] Could not connect to Duet (Board is not available (no header)It's getting late here -- I will probably need to reflash via BOSSA to 3.1.1 and then see how to continue.
-
Back to 3.1.1 once more tonight -- I'm getting comfortable with BOSSA (-:
A freshly booted machine again crashes when uploading and starting a print via DWC:
console entries:
7/10/2020, 9:27:42 PM Upload of 1515-T-connector-vcore-pro.gcode successful after 3s 7/10/2020, 9:27:44 PM M32 "0:/gcodes/1515-T-connector-vcore-pro.gcode" File 0:/gcodes/1515-T-connector-vcore-pro.gcode selected for printing 7/10/2020, 9:27:45 PM Connection interrupted, attempting to reconnect... DCS has been stopped 7/10/2020, 9:27:54 PM Connection establishedI Immediately ran an M122:
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6J1D6-3SD6R-9U0BA Used output buffers: 1 of 40 (10 max) === RTOS === Static ram: 154604 Dynamic ram: 162880 of which 188 recycled Exception stack ram used: 520 Never used ram: 75024 Tasks: NETWORK(ready,1968) HEAT(blocked,1188) CanReceiv(suspended,3396) CanSender(suspended,1444) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,2672) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:09:44 ago, cause: power up Last software reset at 2020-07-05 15:48, reason: User, spinning module LinuxInterface, available RAM 75268 bytes (slot 3) Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 26.7, current 35.6, max 35.9 Supply voltage: min 24.0, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0 Driver 0: standstill, reads 22793, writes 49 timeouts 0, SG min/max 0/1023 Driver 1: standstill, reads 22793, writes 49 timeouts 0, SG min/max 0/856 Driver 2: standstill, reads 22832, writes 11 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 22824, writes 19 timeouts 0, SG min/max 0/154 Driver 4: standstill, reads 22825, writes 19 timeouts 0, SG min/max 0/210 Driver 5: standstill, reads 22825, writes 19 timeouts 0, SG min/max 0/97 Date/time: 2020-07-10 21:27:59 Slowest loop: 4.65ms; fastest: 0.14ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 375, MinFreeDm: 372, MaxWait: 42423ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 107, completed moves: 107, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is ready with "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 0, running macro Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 1.02ms; fastest: 0.01ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 0 of 8 - Ethernet - State: disabled Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 2343, longest wait 2ms for type 6011 === Linux interface === State: 0, failed transfers: 0 Last transfer: 16ms ago RX/TX seq numbers: 181/17363 SPI underruns 0, overruns 0 Number of disconnects: 1 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.1.1 Daemon: Finishing macro daemon.g, started by system > Next stack level Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 20.83This is the gcode file in question:
1515-T-connector-vcore-pro.gcode
It's notable that the printer is still homed, so it wasn't a full reset.
(DWC 3.1.1, RRF 3.1.1)
-
Over the weekend I did a couple slices with Superslicer (PrusaSlicer fork) which did not cause the reset. I'll try to come up with minimal gcode with as little differences as possible to see if I can isolate what causes this. It will take some time though since I'll be traveling for work this week.
