Duet 0.8.5 crashed on file upload while printing

[PDBeal]

Firmware Name: RepRapFirmware for Duet Firmware Electronics: Duet 0.85 Firmware Version: 1.22 (2018-07-26b2) Web Interface Version: 1.22.3

I was printing out a file and it was roughly 97% complete. I wanted to load the next file I was going to print. On previous versions, the upload file buttons were greyed out while printing. Since this newer version didn't have them greyed out I thought I'd see what would happen.

As soon as I selected the file, I got the usual popup that shows the speed and progress. As soon as it appears, an error message about not being able to write to the sd card, or the sd card being full appears and the Duet board just seemed to shutdown or lockup.

The print head stopped where it was, the motors halted, the Z axis remained in position, the heaters were off according to the PanelDue and loosing temperature. The web interface was not able to connect to the board and resulted in the page not found as if the entire Duet board just stopped.

I was able to use the PanelDue's STOP button to re-access the Duet without power cycling it. This is the resulting M122 result after I pressed the STOP button and reconnected to the Duet via the web interface.

M122 === Diagnostics === RepRapFirmware for Duet version 1.22 running on Duet 0.85 Used output buffers: 1 of 16 (9 max) === System === Static ram: 44652 Dynamic ram: 41788 of which 3672 recycled Stack ram used: 2904 current, 5340 maximum Never used ram: 2852 === Platform === Last reset 00:07:37 ago, cause: software Last software reset at 2018-09-24 19:23, reason: User, spinning module GCodes, available RAM 2212 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 21.0MBytes/sec SD card longest block write time: 18.2ms, max retries 0 MCU temperature: min 40.8, current 41.2, max 43.9 Date/time: 2018-09-24 19:31:06 Slowest loop: 200.91ms; fastest: 0.09ms === Move === Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 0, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heaters = 0, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use 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 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Free connections: 15 of 16 Free transactions: 23 of 24 Locked: 0, state: 4, listening: 20071c20, 0, 0

[PDBeal]

I'm pretty sure I shouldn't have been able to even attempt the file upload (based on previous firmware versions) while it was printing, but since it did allow me and the result was a crash, I figured I'd let you know what I experienced.

[dc42]

If you are able to reproduce this then I may do something about it, however it's not easy for me because I no longer have a printer that uses a first-generation Duet.

[PDBeal]

I’m pretty sure I can reproduce it with any print. The upload button on the webpage isn’t being locked out when a print is started like it used to. Before (not sure what version) the upload button would turn grey and not function once a print had started. It’s no longer doing that which means I’m pretty sure it’ll end up the same result of a board crash if I attempt an upload while it’s printing.

[chrishamm]

In this case I'll disable the upload buttons again on the first-gen Duets when a print starts.