Duet3 6HC restart loop when connecting with web browser
-
A new effect started happening with my printer.
About 2 weeks ago I noticed that if I connect to my printer with a web browser (doesn't matter which one - Firefox, Chrome, Safari all show the same) - I would keep getting the Connecting... progress bar roughly every 5 seconds.
If I try to run a command (like heat the bed or hotend), I'd get a red popup saying the Operation has been cancelled.
But only if I connect with a web browser. If I use my PanelDue - no problem. Printer will happily launch and work and print as if nothing was wrong, until I connected with a web browser. I had that issue back in February, but then a software update fixed the problem.
Now though, the problem is much more serious.
I am running Duet 3 6HC + 3HC in standalone mode.
Diag logs below (seems there is an issue with memory?)I thought I read somewhere that the 6HC and 3HC must be connected together to power and not each separately (so wiring goes from PSU to 6HC and from there to 3HC), but I can't find that page anymore. I have the boards connected the right way (so PSU -> 6HC -> 3HC).
Is there anything I can do here? To be clear, it took me 20 minutes to get the below since the board would keep resetting on me
10/22/2020, 6:31:47 PM: Connected to 172.16.100.35 10/22/2020, 6:32:41 PM: m122: === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v0.6 or 1.0 (standalone mode) Board ID: 08DJM-956L2-G43S4-6JKDA-3SJ6T-1B6GH Used output buffers: 2 of 40 (11 max) === RTOS === Static ram: 154604 Dynamic ram: 163560 of which 44 recycled Exception stack ram used: 224 Never used ram: 74784 Tasks: NETWORK(ready,388) ETHERNET(blocked,436) SENSORS(blocked,112) HEAT(blocked,1212) CanReceiv(suspended,3616) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,4528) IDLE(ready,76) Owned mutexes: === Platform === Last reset 00:00:07 ago, cause: software Last software reset time unknown, reason: Memory protection fault, spinning module Platform, available RAM 74400 bytes (slot 2) Software reset code 0x4160 HFSR 0x00000000 CFSR 0x00000082 ICSR 0x0444a804 BFAR 0x00000016 SP 0x20411c6c Task ETHE Stack: 004100e9 00410c92 61000000 20411d80 2042b448 2042b464 004100e9 20425a04 2042285c 20425934 0040c40d Error status: 0 MCU temperature: min 35.1, current 35.4, max 35.6 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.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: standstill, reads 38942, writes 14 timeouts 0, SG min/max 0/0 Driver 1: standstill, reads 38944, writes 14 timeouts 0, SG min/max 0/0 Driver 2: standstill, reads 38944, writes 14 timeouts 0, SG min/max 0/0 Driver 3: standstill, reads 38946, writes 14 timeouts 0, SG min/max 0/0 Driver 4: standstill, reads 38946, writes 14 timeouts 0, SG min/max 0/0 Driver 5: standstill, reads 38947, writes 14 timeouts 0, SG min/max 0/0 Date/time: 1970-01-01 00:00:00 Slowest loop: 5.75ms; fastest: 0.21ms === Storage === Free file entries: 10 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 3.3ms, 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 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: 6.12ms; fastest: 0.03ms 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: 1 of 8 - Ethernet - State: active Error counts: 0 0 0 0 0 Socket states: 5 2 2 2 2 0 0 0 === CAN === Messages sent 41, longest wait 1ms for type 6017 === Linux interface === State: 0, failed transfers: 0 Last transfer: 7950ms ago RX/TX seq numbers: 0/1 SPI underruns 0, overruns 0 Number of disconnects: 0 Buffer RX/TX: 0/0-0 -
I would try flashing the board with 3.1.1 again via USB and bossa. I would also try a fresh SD card with a fresh version of the 3.1.1 DWC files.
https://github.com/Duet3D/RepRapFirmware/releases/tag/3.1.1
If you're still having issues after that then we can investigate further.
Here is the info page on the 3HC.
Perhaps the power connection detail you're thinking of is here? https://duet3d.dozuki.com/Wiki/Duet_3_Expansion_Hardware_Overview#Section_Power_distribution
-
Unfortunately, neither helped. I flashed fresh with 3.1.1, beta 3.2 (both 1 and 2), took a totally new SD card - same thing keeps happening the moment I connect with a web browser.
Thanks for the link to the 3HC page, but unless I am totally blind (very possible) - that's not the one. I was looking for the one that described how to hook up power to the 3HC and that it must go first to 6HC before it gets to the 3HC.
-
Just to verify, you've replaced the DWC files in the /www folder as well?
-
I took a brand new SD card and took all of the steps from here: https://duet3d.dozuki.com/Wiki/SD_Card (full format into FAT16).
The only thing I moved over from the old config was a couple files from the system folder (like config.g, home###.g).
-
Ok, but does your /www folder contain the files from this DWC zip file?
https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/DuetWebControl-SD-3.1.1.zip
-
Yes, it does.
-
@pkos, I will examine your M122 log tomorrow. Have you changed your antivirus software on the PC recently, or made other changes that coincide with the problem starting?
-
The only change was moving the Mac Mini to a different room.
I actually did the test with antivirus/firewall turned off to be sure it's not that - it's not.I'll have some more time this weekend to troubleshoot further.
-
So this will be a small necro of the thread, but I believe I figured out what is causing the problem.
To be clear - my comparison is between a Mac and a regular Windows 10 PC.
The problem is the Eset Smart Security on the Mac, but only if you use ethernet. If you switch to Wifi - problem is gone. On Windows - also with Eset - the problem never exists.
Fortunately, with more recent firmwares for the Duet - the printer will no longer reboot midprint if I try to connect to it, but it will keep disconnecting all the time.
The workaround for the rebooting is to disable Web protection in Eset when working with Duets (and this happens on all my duet boards and different versions of DWC (even the newest one).
