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:
Connecting... Printer is now online. >>>M36 "ormerod-leadscrew-mount.gcode" SENDING:M36 "ormerod-leadscrew-mount.gcode" {"err":0,"filament":[],"fileName":"0:/gcodes/ormerod-leadscrew-mount.gcode","firstLayerHeight":0.4,"generatedBy":"KISSlicer - PREMIUM","height":29,"lastModified":"2020-07-04T11:35:46.3573294+02:00","layerHeight":0.2,"numLayers":144,"printTime":null,"simulatedTime":null,"size":16576478} >>>M32 "ormerod-leadscrew-mount.gcode" SENDING:M32 "ormerod-leadscrew-mount.gcode" File opened File selected [... serial connection resets ...] >>>M27 SENDING:M27 [ERROR] Can't read from printer (disconnected?) (SerialException): call to ClearCommError failed Disconnected. Connecting... ok T0:38.4 /0.0 B:79.6 /0.0 Printer is now online. >>>M27 SENDING:M27 Not SD printing. >>>M122 SENDING: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: 162432 of which 20 recycled Exception stack ram used: 292 Never used ram: 75868 Tasks: NETWORK(ready,1968) HEAT(blocked,1124) CanReceiv(suspended,3536) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4952) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:00:20 ago, cause: software Last software reset at 2020-07-04 12:54, reason: Memory protection fault, spinning module GCodes, available RAM 74976 bytes (slot 0) Software reset code 0x0163 HFSR 0x00000000 CFSR 0x00000082 ICSR 0x04432804 BFAR 0x00000032 SP 0x2041787c Task MAIN Stack: 00441df3 0040305a 610f0000 2044d648 00405159 0047280c 20417b10 20417a58 00000000 00000002 00000002 Error status: 0 [ERROR] Error status: 0 MCU temperature: min 39.3, current 39.7, max 39.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 33324, writes 14 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 33324, writes 14 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 33328, writes 11 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 33325, writes 14 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 33326, writes 14 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 33326, writes 14 timeouts 0, SG min/max 0/0 Date/time: 2020-07-04 12:54:38 Slowest loop: 3.81ms; 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: 375, MaxWait: 0ms 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 idle in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is ready with "M122" 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.43ms; 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 [ERROR] Error counts: 0 0 0 0 0 Socket states: 0 0 0 0 0 0 0 0 === CAN === Messages sent 88, longest wait 2ms for type 6036 === Linux interface === State: 0, failed transfers: 0 Last transfer: 27ms ago RX/TX seq numbers: 2333/640 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0This is on an MB6HC 0.6 with a tool distribution board and a tool board, running RepRapFirmware 3.1.1
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.1.1 ELECTRONICS: Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_DATE: 2020-05-19b2
The Gcode file is available at https://drive.google.com/file/d/1ZeHqJQDHAMaIg1NdQABQmRF3ZLk1Sa5F/view?usp=sharing
<>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>
-
Forgot to add that running a simulation of the file works fine.
-
I am going to print the plater object by object now to see if a particular object triggers the Memory Fault Protection.
-
I was able to pare this down to two of the four objects on the plater, fixing them with netfabb made it possible to print them ...
So while the STLs had some errors, KISS did generate gcode, and I wouldn't expect RRF to memory fault on trying to parse gcode.
-
I've added this to my list of issues to investigate. Please ensure that the GCode file continues to be available. Also, please post your config.g file.
-
Here's config.g and config-override.g
vcp-config.g
vcp-config-override.gThis shorter gcode file did trigger the issue as well.
-
I've determined that the memory protection fault occurs while processing a M27 command. This command is rarely used these days, however Pronterface sends is regularly.
Does the problem occur at the start of printing, or the end, or in the middle?
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 -
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
