Duet mb6hc suddenly lost ethernet
-
Hi! Hoping some here can help me figure this out.
I have an mb6hc running in standalone mode that was working fine very recently. Then I went away for a week, and now that I'm back I can't connect via ethernet. I've tried connecting via USB and it happily reports that ethernet is enabled, and reports both the configured IP and the actual IP (which is the same). But I can't connect to it, it doesn't even show up on the clients table on my internet router. I've tried connecting it via another router, and also directly to my computer (not sure if this would work without a crossed cable though).
The green LED on the ethernet port is mostly solid green, blinking once in a while. the other LED shows no activity whatsoever.
Where do I begin trying to fix this?
-
When connected by USB terminal can you send M122 and copy and paste the results here?
You can connect directly to a PC to test, but will need to do some minor configuration changes. This would be a good test because it removes your network from the equation entirely. See here: https://docs.duet3d.com/en/User_manual/Machine_configuration/Networking#wired-direct-connection
-
As a comment: I have removed the board from the CNC to work on this issue, so no other hardware is connected to it at the moment. It is connected only via USB and ethernet.
M122 results:[20:04:14:191] === Diagnostics ===␊
[20:04:14:191] RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (standalone mode)␊
[20:04:14:191] Board ID: 08DJM-956BA-NA3TN-6J9F0-3SJ6R-1V86U␊
[20:04:14:191] Used output buffers: 1 of 40 (14 max)␊
[20:04:14:191] === RTOS ===␊
[20:04:14:191] Static ram: 150904␊
[20:04:14:193] Dynamic ram: 91548 of which 0 recycled␊
[20:04:14:193] Never used RAM 111740, free system stack 190 words␊
[20:04:14:193] Tasks: NETWORK(ready,29.9%,429) ETHERNET(notifyWait,0.0%,204) HEAT(delaying,0.0%,414) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,343) TMC(notifyWait,0.0%,105) MAIN(running,70.1%,1131) IDLE(ready,0.0%,29), total 100.0%␊
[20:04:14:193] Owned mutexes: USB(MAIN)␊
[20:04:14:193] === Platform ===␊
[20:04:14:193] Last reset 00:02:35 ago, cause: power up␊
[20:04:14:193] Last software reset at 2023-04-06 19:09, reason: User, GCodes spinning, available RAM 107800, slot 1␊
[20:04:14:193] Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a␊
[20:04:14:193] Error status: 0x00␊
[20:04:14:193] Aux0 errors 0,0,0␊
[20:04:14:193] Step timer max interval 698␊
[20:04:14:193] MCU temperature: min 43.2, current 44.5, max 44.7␊
[20:04:14:193] Supply voltage: min 0.2, current 0.2, max 0.3, under voltage events: 0, over voltage events: 0, power good: no␊
[20:04:14:193] 12V rail voltage: min 0.1, current 0.1, max 0.2, under voltage events: 0␊
[20:04:14:193] Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0␊
[20:04:14:193] Driver 0: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Driver 1: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Driver 2: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Driver 3: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Driver 4: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Driver 5: position 0, ok, reads 0, writes 0 timeouts 0, SG min/max not available␊
[20:04:14:193] Date/time: 1970-01-01 00:00:00␊
[20:04:14:193] Slowest loop: 9.15ms; fastest: 0.05ms␊
[20:04:14:193] === Storage ===␊
[20:04:14:193] Free file entries: 10␊
[20:04:14:193] SD card 0 detected, interface speed: 25.0MBytes/sec␊
[20:04:14:193] SD card longest read time 3.0ms, write time 0.0ms, max retries 0␊
[20:04:14:193] === Move ===␊
[20:04:14:193] DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000␊
[20:04:14:193] === MainDDARing ===␊
[20:04:14:193] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊
[20:04:14:193] === AuxDDARing ===␊
[20:04:14:193] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊
[20:04:14:193] === Heat ===␊
[20:04:14:193] Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1␊
[20:04:14:193] === GCodes ===␊
[20:04:14:193] Segments left: 0␊
[20:04:14:193] Movement lock held by null␊
[20:04:14:193] HTTP is idle in state(s) 0␊
[20:04:14:193] Telnet is idle in state(s) 0␊
[20:04:14:193] File is idle in state(s) 0␊
[20:04:14:193] USB is ready with "M122" in state(s) 0␊
[20:04:14:193] Aux is idle in state(s) 0␊
[20:04:14:193] Trigger is idle in state(s) 0␊
[20:04:14:193] Queue is idle in state(s) 0␊
[20:04:14:193] LCD is idle in state(s) 0␊
[20:04:14:193] SBC is idle in state(s) 0␊
[20:04:14:193] Daemon is idle in state(s) 0␊
[20:04:14:193] Aux2 is idle in state(s) 0␊
[20:04:14:193] Autopause is idle in state(s) 0␊
[20:04:14:193] Code queue is empty.␊
[20:04:14:193] === CAN ===␊
[20:04:14:193] Messages queued 406, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 406/0/0␊
[20:04:14:193] Tx timeouts 0,0,406,0,0,0 last cancelled message type 30 dest 127␊
[20:04:14:193] ␊
[20:04:14:193] === Network ===␊
[20:04:14:193] Slowest loop: 0.11ms; fastest: 0.02ms␊
[20:04:14:193] Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions␊
[20:04:14:193] HTTP sessions: 0 of 8␊
[20:04:14:203] - Ethernet -␊
[20:04:14:203] State: active␊
[20:04:14:203] Error counts: 0 0 1 0 0␊
[20:04:14:203] Socket states: 2 2 2 2 2 0 0 0␊
[20:04:14:203] ok␊ -
Did you test a direct connection to your PC?
-
I did not, but I've tried two different internet routers, connecting from two different computers, with two different ethernet cables. All of which have been verified independently to be working. So i figured it would be unlikely to make a difference. I can still try if you think it makes sense, but I'm thinking there should be other things more relevant to try. Like reflashing the firmware? Can i place the install files in the sys folder on the SD card and trigger the install via USB? Or do I need to use Bossa for this if I cant access the DWC? And can I upload the same version or would it refuse because it is not an upgrade?
Either way I'm pretty desperate to get this working within a few days, I'm using the CNC for production in my startup. The last option would be to try using an SBC setup, but this takes some work and brings me no benefit so I hope it can be avoided. Very grateful for any help I get.
-
Since I'm desperate to get this working I now tried connecting it via ribbon cable and a raspberry pi 3B v1.2. I had an old SD card with the raspberry pi image on it and the raspberry pi boots up and connects to ethernet. But it does not load a DWC, and when running
lsusb
it does not seem to find the duet. I will admit that I'm not 100% if the Pi image and the duet have the same version number, but I'm sure they are close (possibly the Pi is 3.2.2 while duet is 3.3. Is there a way to check Pi firmware version?).I have the duet powering the RasPi via jumper settings. It's a 3B pi with nothing else connected to it and both the duet and the Pi seem to run fine, except not communicating.
I'd still prefer having it working in standalone mode but if this is easier to fix I'll settle for that, so long as I get it running again quickly.
Results of
journalctl -u duetcontrolserver -e
Apr 19 16:18:53 duet3 systemd[1]: duetcontrolserver.service: Succeeded. Apr 19 16:18:58 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart. Apr 19 16:18:58 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 49. Apr 19 16:18:58 duet3 systemd[1]: Stopped Duet Control Server. Apr 19 16:18:58 duet3 systemd[1]: Started Duet Control Server. Apr 19 16:18:58 duet3 DuetControlServer[2005]: Duet Control Server v1.1.0.5 Apr 19 16:18:58 duet3 DuetControlServer[2005]: Written by Christian Hammacher for Duet3D Apr 19 16:18:58 duet3 DuetControlServer[2005]: Licensed under the terms of the GNU Public License Version 3 Apr 19 16:18:58 duet3 DuetControlServer[2005]: Loading settings... Done! Apr 19 16:18:59 duet3 DuetControlServer[2005]: Initialising variables... Done! Apr 19 16:18:59 duet3 DuetControlServer[2005]: Connecting to RepRapFirmware... Error: Duet is not available Apr 19 16:18:59 duet3 systemd[1]: duetcontrolserver.service: Succeeded. Apr 19 16:19:04 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart. Apr 19 16:19:04 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 50. Apr 19 16:19:04 duet3 systemd[1]: Stopped Duet Control Server. Apr 19 16:19:04 duet3 systemd[1]: Started Duet Control Server. Apr 19 16:19:05 duet3 DuetControlServer[2019]: Duet Control Server v1.1.0.5 Apr 19 16:19:05 duet3 DuetControlServer[2019]: Written by Christian Hammacher for Duet3D Apr 19 16:19:05 duet3 DuetControlServer[2019]: Licensed under the terms of the GNU Public License Version 3 Apr 19 16:19:05 duet3 DuetControlServer[2019]: Loading settings... Done! Apr 19 16:19:05 duet3 DuetControlServer[2019]: Initialising variables... Done! Apr 19 16:19:06 duet3 DuetControlServer[2019]: Connecting to RepRapFirmware... Error: Duet is not available Apr 19 16:19:06 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Results of M122:
[17:15:19:033] === Diagnostics ===␊ [17:15:19:033] RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)␊ [17:15:19:033] Board ID: 08DJM-956BA-NA3TN-6J9F0-3SJ6R-1V86U␊ [17:15:19:033] Used output buffers: 1 of 40 (1 max)␊ [17:15:19:033] === RTOS ===␊ [17:15:19:033] Static ram: 150904␊ [17:15:19:033] Dynamic ram: 59980 of which 0 recycled␊ [17:15:19:036] Never used RAM 143308, free system stack 190 words␊ [17:15:19:036] Tasks: SBC(ready,4.1%,606) HEAT(delaying,0.0%,405) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.0%,93) MAIN(running,88.8%,1244) IDLE(ready,0.1%,29), total 100.0%␊ [17:15:19:036] Owned mutexes: USB(MAIN)␊ [17:15:19:036] === Platform ===␊ [17:15:19:036] Last reset 00:01:56 ago, cause: power up␊ [17:15:19:036] Last software reset at 2023-04-06 19:09, reason: User, GCodes spinning, available RAM 107800, slot 1␊ [17:15:19:036] Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a␊ [17:15:19:036] Error status: 0x00␊ [17:15:19:036] Step timer max interval 14997␊ [17:15:19:036] MCU temperature: min 31.8, current 42.4, max 42.4␊ [17:15:19:036] Supply voltage: min 28.9, current 28.9, max 28.9, under voltage events: 0, over voltage events: 0, power good: yes␊ [17:15:19:036] 12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0␊ [17:15:19:036] Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0␊ [17:15:19:036] Driver 0: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Driver 1: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Driver 2: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Driver 3: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Driver 4: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Driver 5: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊ [17:15:19:036] Date/time: 1970-01-01 00:00:00␊ [17:15:19:036] Slowest loop: 0.12ms; fastest: 0.00ms␊ [17:15:19:036] === Storage ===␊ [17:15:19:036] Free file entries: 10␊ [17:15:19:036] SD card 0 not detected, interface speed: 37.5MBytes/sec␊ [17:15:19:036] SD card longest read time 0.0ms, write time 0.0ms, max retries 0␊ [17:15:19:036] === Move ===␊ [17:15:19:036] DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000␊ [17:15:19:036] === MainDDARing ===␊ [17:15:19:036] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊ [17:15:19:036] === AuxDDARing ===␊ [17:15:19:036] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊ [17:15:19:036] === Heat ===␊ [17:15:19:036] Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1␊ [17:15:19:036] === GCodes ===␊ [17:15:19:036] Segments left: 0␊ [17:15:19:036] Movement lock held by null␊ [17:15:19:036] HTTP is idle in state(s) 0␊ [17:15:19:036] Telnet is idle in state(s) 0␊ [17:15:19:036] File is idle in state(s) 0␊ [17:15:19:036] USB is ready with "M122" in state(s) 0␊ [17:15:19:036] Aux is idle in state(s) 0␊ [17:15:19:036] Trigger is idle in state(s) 0␊ [17:15:19:036] Queue is idle in state(s) 0␊ [17:15:19:036] LCD is idle in state(s) 0␊ [17:15:19:036] SBC is idle in state(s) 0␊ [17:15:19:036] Daemon is idle in state(s) 0␊ [17:15:19:036] Aux2 is idle in state(s) 0␊ [17:15:19:036] Autopause is idle in state(s) 0␊ [17:15:19:036] Code queue is empty.␊ [17:15:19:036] === CAN ===␊ [17:15:19:036] Messages queued 583, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 583/0/0␊ [17:15:19:036] Tx timeouts 0,0,582,0,0,0 last cancelled message type 30 dest 127␊ [17:15:19:036] ␊ [17:15:19:036] === SBC interface ===␊ [17:15:19:036] State: 0, failed transfers: 1, checksum errors: 3␊ [17:15:19:036] Last transfer: 99003ms ago␊ [17:15:19:036] RX/TX seq numbers: 1/1␊ [17:15:19:036] SPI underruns 0, overruns 0␊ [17:15:19:036] Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c␊ [17:15:19:036] Buffer RX/TX: 0/0-0␊ [17:15:19:036] ok␊
-
A direct connection gives me an idea if the ethernet interface is working or not without an external network possibly causing the issue. It's just troubleshooting by elimination.
You can reflash the firmware via BOSSA and a USB connection if you life, but it still appears that the firmware is responding as expected. You can flash the same version or update to 3.4.5.
Using a Pi and SBC mode would be one way to get up and running more quickly because it bypasses the onboard ethernet and uses the pi for the networking. So if you need to get up and running ASAP this would be a good option, because even a warranty replacement would take some time. Which leads me to ask, when and where was the board purchased? If a direct connection after a firmware re-flash still doesn't communicate than it's likely the ethernet hardware has failed.
If you do go the SBC route I would suggest you download a fresh copy of the DuetPi image and burn it an SD card. Update the Duet via Bossa to 3.4.5, and then run
sudo apt update && sudo apt upgrade
on the pi terminal.https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup
-
The board is more than a year old so no warranty, but regardless I went for the SBC route to just get it running. I realized version 3.3 actually uses the same SD card for SBC and standalone, and the first SD card I used was out of date. I can now connect via the SBC and the versions are matching for sure (all 3.3), so for a while I was relieved and thought I could start production again. But despite being the same version as I used last week my jobs and macros are partially broken, the code is interpreted differently.
I have macros that repeat the same job in a pattern to produce multiple parts efficiently. If I run them as a macro they will terminate after just 2 out of 25 instances the first time I run it with no error being reported. If I run the same macro again it completes the whole pattern, but the first two parts have now been run twice and may need to be scrapped. It's also a wast of time.
If I run the exact same file from the job folder it finishes 5 instances out of 25 and then will not run again because it does not clear the loop variables so they can not be reassigned.Also all my laser jobs (I have both a milling spindle and a laser mounted) now turns on the laser on the first G0 transport of each job, leaving a long straight line across the workpiece ruining it. Subsequent G0 moves are interpreted correctly.
Plus a bunch of other less critical issues...
I know, I know, the only thing to do is to upgrade to the latest version and hope that this resolves the issues. But I really just want this to run and I don't have the time to spend on it right now and I know syntax has changed for some M-codes in config and homing macros so it won't be a quick fix. I could not imagine that the jobs and macros would be broken just by running SBC mode...