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-0
    

    This 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



  • 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.


  • administrators

    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.g

    This shorter gcode file did trigger the issue as well.

    olm-x_end_stop.gcode


  • administrators

    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?


  • administrators

    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.


  • administrators

    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.


  • administrators

    @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.



  • @dc42 I am not using pronterface (my printer is not connected to anything via USB. Pi via SBC interface and a PanelDue).


  • administrators

    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.


  • administrators

    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


  • administrators

    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.



  • @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

    Screenshot_20200710-194953.png

    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 established
    

    I 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.83
    

    This 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.


Log in to reply