Random disconnects DuetWifi 3.01 RC12
-
After a bit more troubleshooting I've determined that the printer behaves as if I sent a M999 command but it occurs at random times
-
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
Every time it disconnects the USB connection to my computer also disconnects
this always happen when the board is reset.
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
I've determined that the printer behaves as if I sent a M999
running
M122first thing after connecting to the board again would be helpful. is there anything that could short against the reset pins or trigger the reset switch on the board? pictures andM122might provide some insight. -
The results from M122 immediately after it reconnects are provided above in a previous post. There's nothing that could be pressing against the reset button.
This is how the board is currently wired
-
Please upgrade to 3.1.0 release firmware and if the problem continues, post another M122 report taken immediately after it reconnects.
The ground wire between your Duet and DueX5 isn't done according to our wiring instructions. This might be part of the problem, OTOH the wires between them and the DueX5 are short, which will help to mitigate the incorrect wiring.
-
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
The results from M122 immediately after it reconnects are provided above in a previous post. There's nothing that could be pressing against the reset button.
as in
Last reset 00:02:19 ago, cause: power up?
Unless the firmware is wrong it would suggest you had a power glitch? In any case, what he said
-
Thank you for pointing out the wiring issue. Unfortunately after fixing that and upgrading to firmware 3.1.0 I am still having the same problem.
This is my M122 immediately after the printer reconnects.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.0 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-956GU-DJMSN-6J1DL-3SN6M-TTNRF
Used output buffers: 3 of 24 (12 max)
=== RTOS ===
Static ram: 28180
Dynamic ram: 94088 of which 60 recycled
Exception stack ram used: 264
Never used ram: 8480
Tasks: NETWORK(ready,36) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1816) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:10 ago, cause: software
Last software reset at 2020-05-18 14:22, reason: Stuck in spin loop, spinning module Move, available RAM 8080 bytes (slot 1)
Software reset code 0x4084 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200043ac Task IDLE
Stack: 00454afd 00455530 61000000 a5a5a5a5 00454afd a5a5a5a5 200043d0 200042c0 00000002 200051f4 0000be35
Error status: 0
MCU temperature: min 29.5, current 30.9, max 31.1
Supply voltage: min 24.3, current 24.5, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-05-18 14:22:39
Cache data hit count 15987603
Slowest loop: 2.94ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.5ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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, 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.67ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 5c:cf:7f:76:68:e0
WiFi Vcc 3.41, reset reason Unknown
WiFi flash size 4194304, free heap 25200
WiFi IP address 192.168.1.101
WiFi signal strength -38dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== DueX ===
Read count 1, 5.62 reads/min
- WiFi -
-
@mike5490 Can you please share your config.g? How can you reproduce it? If it happens while printing a certain file or while running a certain macro, please share that, too.
-
I don't know how to reproduce the problem as it's intermittent and I haven't been able to find a cause yet. I haven't bothered to run any macros or prints yet as I'm trying to get the printer working correctly first.
Here's my current config.g file
-
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
I don't know how to reproduce the problem as it's intermittent and I haven't been able to find a cause yet. I haven't bothered to run any macros or prints yet as I'm trying to get the printer working correctly first.
Here's my current config.g file
Please try again with the 3.1.1 release, which we hope to make available later today.
-
@dc42 I installed the internal build for 3.1.1 -18b8 last night and am still having the same disconnect problems.
-
Please try the official 3.1.1 release.
-
I installed the official 3.1.1 and am still having the same issues.
This is my results from M122 immediately after the board reconnects
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-956GU-DJMSN-6J1DL-3SN6M-TTNRF
Used output buffers: 3 of 24 (12 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 94488 of which 60 recycled
Exception stack ram used: 264
Never used ram: 8280
Tasks: NETWORK(ready,384) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1824) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:00:13 ago, cause: software
Last software reset at 2020-05-20 10:19, reason: Stuck in spin loop, spinning module Move, available RAM 7880 bytes (slot 2)
Software reset code 0x4084 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200042e4 Task IDLE
Stack: 00454cdd 0045570c 61000000 a5a5a5a5 00454cdd a5a5a5a5 20004308 200041f8 00000002 2000512c 00004be2
Error status: 0
MCU temperature: min 31.3, current 32.4, max 33.3
Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-05-20 10:19:45
Cache data hit count 21289392
Slowest loop: 3.01ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 1.5ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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, 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.62ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 5c:cf:7f:76:68:e0
WiFi Vcc 3.42, reset reason Unknown
WiFi flash size 4194304, free heap 25200
WiFi IP address 192.168.1.101
WiFi signal strength -43dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== DueX ===
Read count 1, 4.47 reads/min
- WiFi -
-
After updating to the official 3.1.1 it seems to disconnect less randomly and seems to occur most often after an endstop is triggered while homing.
-
Oh, I thought that I'm the only one with that problem.
I saw the same problem with 3.01-RC12 and it still exists with 3.1.1. With 3 or 4 browsers. (router and printer in the same room, 4 meter distance)
It happens often enough that I see it when I edit a file frequently.I think that I will capture the traffic with wireshark, to see who is not answering.
Cheers, Chriss
-
@Chriss any luck with determining what could be causing your disconnect issues?
I still haven't been able to find a solution for mine
-
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
@Chriss any luck with determining what could be causing your disconnect issues?
Unfortunately not, but it seems to me that the problem is "gone with the wind". I had some trouble with my workstation in a complete other context. So I rebooted the workstation and the router which is my access point too. It seems that the problem is gone now, but I still keep a tcpdump in the background running to have some data when the problem comes back.
I still haven't been able to find a solution for mine
As a idea: I would try to trace the actual component/source of the problem first. I do not know how you are "wired" to the duet. I have Workstation, connected via wire to a switch(a), which is connected to a switch(2). This switch(2) is connected to a WiFi bridge (aka AVM Fritz! Box) which is a router too. But I do not use it as a router, it is a bridge to WiFi for me only.
So my idea was to get rid of all the complexity fist. So I would connect a other device (laptop) to WiFi, make sure that the WiFi signal is very good, and test from the laptop first. Just to make sure that no active or passive component in the middle is the root of the problem.That would be my approach to trace the "failing" component, I hope that gave you a idea.
This topic is not death to me, but I have to many variables at the moment. The reboot of the router and the workstation was not a very good idea.
Cheers, Chriss
-
I'm a step closer to the root of that issue. It seems that I have a "block" somewhere in my kernel. There are a couple of reports that the X-Windows system and the linux kernel have some problem with internal blocks of processes when the system runs low in memory. I have that problem at the moment with 100% memory usage plus 13GB swap. The CPU load is around 10-12. On a Threadripper with 24cores and 2 threads per core.
You may to make sure that you do not have a problem with your host. :?
Cheers, Chriss
-
Update: I restarted the bloody Firefox (Beta), that gave the Chromium enough resources to communicate properly with the Duet.
This modern browsers open a lot of tcp connections and keep them open for a very long time. You may like to test if you have that problem with a fresh started workstation.
Cheers, Chriss
-
I have bought a brand new duet 2 ethernet board and am still having the same problems. Was hoping using an ethernet board would help.
I updated the new board to firmware 3.1.1 and this is my results for M112 immediately after it reconnectsM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DLM-996RU-N8PS4-7JKD2-3S06T-9ABRN
Used output buffers: 3 of 24 (12 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 94104 of which 60 recycled
Exception stack ram used: 208
Never used ram: 8720
Tasks: NETWORK(ready,384) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1824) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:00:21 ago, cause: software
Last software reset at 2020-06-08 21:30, reason: Stuck in spin loop, spinning module Move, available RAM 8264 bytes (slot 1)
Software reset code 0x4084 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200042e4 Task IDLE
Stack: 00454cdd 0045570c 61000000 a5a5a5a5 00454cdd a5a5a5a5 20004308 200041f8 00000002 2000512c 000124b9
Error status: 0
MCU temperature: min 30.2, current 30.9, max 31.1
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-06-08 21:31:20
Cache data hit count 39924084
Slowest loop: 5.22ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.2ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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, 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 8.15ms; 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
=== DueX ===
Read count 1, 2.76 reads/min -
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
After updating to the official 3.1.1 it seems to disconnect less randomly and seems to occur most often after an endstop is triggered while homing.
Are any of the endstop switches connected to the DueX5?
