DWC Seems to Crash After Uploading a Print

CCS86

The last few times I have chosen "send to printer" > "upload and print" from Super Slicer, it uploads normally. Then after completing the upload successfully, DWC seems to crash. The web interface is trying to reconnect for a minute or two, then suddenly it comes back online and starts printing as if nothing happened.

The two files that have caused this were around 40 MB. I haven't tried a smaller file to see if it is related.

DWC 3.4.0
RRF 3.4.0

m122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.4.0 (2022-03-15 18:58:02) running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LLMS4-7J9F6-3SN6Q-KBM2Q
Used output buffers: 3 of 24 (19 max)
=== RTOS ===
Static ram: 23644
Dynamic ram: 68572 of which 0 recycled
Never used RAM 18528, free system stack 150 words
Tasks: NETWORK(ready,102.1%,255) ACCEL(notifyWait,0.0%,349) HEAT(notifyWait,78.9%,342) Move(notifyWait,89.1%,310) TMC(notifyWait,145.3%,110) MAIN(running,5.6%,494) IDLE(ready,0.4%,31), total 421.3%
Owned mutexes: W5500(NETWORK)
=== Platform ===
Last reset 480:33:21 ago, cause: software
Last software reset at 2022-02-04 15:35, reason: User, GCodes spinning, available RAM 23080, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 1867
MCU temperature: min 38.3, current 41.5, max 50.4
Supply voltage: min 24.0, current 24.0, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/186/186, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, read errors 0, write errors 1, ifcnt 45, reads 34021, writes 37, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, read errors 0, write errors 1, ifcnt 45, reads 34021, writes 37, timeouts 0, DMA errors 0, CC errors 0
Driver 2: ok, read errors 0, write errors 1, ifcnt 45, reads 34021, writes 37, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, read errors 0, write errors 1, ifcnt 39, reads 34027, writes 31, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, read errors 0, write errors 1, ifcnt 13, reads 34052, writes 6, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2022-04-13 22:01:12
Slowest loop: 1488.61ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 10.0MBytes/sec
SD card longest read time 2.7ms, write time 157.2ms, max retries 0
=== Move ===
DMs created 83, segments created 37, maxWait 1448604906ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 31, completed 30, hiccups 55, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1, chamber heaters -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 0
Movement lock held by File
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 42
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
=== Network ===
Slowest loop: 1488.71ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex

Phaedrux

what version of super slicer?
Are you doing any post processing on the gcode?

CCS86

@phaedrux

2.4.58.2

No PP.

Phaedrux

Does it also crash if you upload from another slicer like PrusaSlicer, or an older version of SuperSlicer?

Does it upload successfully in DWC itself?

CCS86

@phaedrux

This actually seems to be a more global DWC issue. I just tried to download a variety of files from DWC and it keeps crashing. The largest file I was able to download was around 6MB. Even a 10MB file causes a connection interruption and aborted download:

4/17/2022, 10:12:08 AM	Connection established
4/17/2022, 10:12:08 AM	Failed to download Vent Lips.gcode
Could not complete action because the connection has been terminated
4/17/2022, 10:12:08 AM	Connection interrupted, attempting to reconnect...
Network error
4/17/2022, 10:11:51 AM	Download of Drain Adapter.gcode successful after 6s
4/17/2022, 10:11:36 AM	Connection established
4/17/2022, 10:11:35 AM	Failed to download Outlet Nozzle3.gcode
Could not complete action because the connection has been terminated
4/17/2022, 10:11:35 AM	Connection interrupted, attempting to reconnect...
Network error
4/17/2022, 10:11:10 AM	Connection established
4/17/2022, 10:11:10 AM	Failed to download Outlet Nozzle3c.gcode
Could not complete action because the connection has been terminated
4/17/2022, 10:11:10 AM	Connection interrupted, attempting to reconnect...
Network error
4/17/2022, 10:10:49 AM	Connection established
4/17/2022, 10:10:48 AM	Failed to download Outlet Nozzle3c.gcode
Could not complete action because the connection has been terminated

Uploading a lager file via DWC causes the same issue.

Phaedrux

Do you have another SD card you can try?

CCS86

@phaedrux said in DWC Seems to Crash After Uploading a Print:

Do you have another SD card you can try?

This doesn't seem like an SD card issue.

I tried uploading a 5.2MB file repeatedly. Each time it gave me this error and DWC had to reconnect:

Failed to upload Loctite4.gcode
Could not complete action because the connection has been terminated

But, these files were still present in the jobs folder. So, I downloaded the files and they are perfect matches to the original. So, there is no actual failure to write and read from the card, and no corruption.

This seems like purely a network connectivity glitch in DWC.

Can I gather more detailed logs?

Phaedrux

If you downgrade to 3.3 does it persist? It would be useful to know if it's tied to the firmware or the hardware.

CCS86

@phaedrux said in DWC Seems to Crash After Uploading a Print:

If you downgrade to 3.3 does it persist? It would be useful to know if it's tied to the firmware or the hardware.

Okay, I flashed back to 3.3 and the problem persists.

This is really odd, because I have a number of larger files uploaded already without that issue. So, it started recently.

No changes to me network or the printer. I'm stumped at the moment.

Phaedrux

A wireshark trace could maybe show where the problem is.

CCS86

@phaedrux

Is there a way for DWC to gather detailed logs?

Phaedrux

These are your options for logging but I don't know if it will capture what is happening.

https://docs.duet3d.com/en/User_manual/Troubleshooting/Logging

A wireshark trace would at least tell us where the connection is failing.

CCS86

@phaedrux

First attempt to capture packets during a failed upload:

Maestro_Wireshark.zip.txt

clegg78

@ccs86 I've been seeing similar with DWC after going to 3.4.0. There is some real weird behavior in the UI now with resets, reconnections, crashes on saving big macros/config files, etc... Very frustrating.

CCS86

@clegg78 said in DWC Seems to Crash After Uploading a Print:

@ccs86 I've been seeing similar with DWC after going to 3.4.0. There is some real weird behavior in the UI now with resets, reconnections, crashes on saving big macros/config files, etc... Very frustrating.

Interesting.

I never noticed this issue before going to the release version of 3.4.0.

I tried flashing back to earlier versions of DWC, but I left RRF at 3.4.0. So, maybe there is actually an issue with RRF that is causing the DWC disconnects.

clegg78

@ccs86 So... I may have stumbled on something in my case today... Disabling both filament sensors (Duet rotating magnet ones, one on each print head) = no reconnections/DWC crashes.
Enabling one = some random drops.
Enabling both = Crashes galore.

I am going to be doing more testing on this.

CCS86

@clegg78

I'm actually using no filament sensors. Just a BL Touch.

clegg78

@ccs86 Interesting. I also have a BLTouch. curious what bug was introduced in 3.4.0 to cause these weird behaviors.

CCS86

@clegg78

Have you tried downgrading RRF? That's my next step.

clegg78

@ccs86 I have not. My machine is used for pretty consistent production use and the DWC thing is annoying, very annoying, but hasn't been a show stopper for it to run. And the code/config tweaks for 3.4.0 I don't want to unwind. I guess if it turns out there is no fix, I may have to go back.