Random disconnects DuetWifi 3.01 RC12
-
@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?
-
@mike5490 can you post your current config.g, preferably in you reply as text using the code tags? (I can’t read attached files on my phone!) Are you using a fixed IP address (possible IP address clash)? Have you tried connecting to the DWC using a different device (phone/tablet/PC)?
Isn
-
@dc42
Yes the y-axis endstop is connected to the duex5. Both the x-axis endstop and probe are connected to the duet.@droftarts
This is my config file:; Executed by the firmware on start-up
; Last updated June 8/2020; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"Cube Printer" ; set printer name
M669 K1 ; select CoreXY mode; Network
M551 P"mike17670" ; set password
M552 S1 ; enable networking
M586 P0 S1 ; enable HTTP
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet; Drives
M584 X9 Y5 Z6:7:8 E3:4 ; Drive mapping, x=drive9, y=drive5, z=drive6+7+8, e=drive3+4
M569 P9 S0 ; physical drive 9 goes forwards
M569 P5 S0 ; physical drive 5 goes forwards
M569 P6 S0 ; physical drive 6 goes forwards (front right z motor)
M569 P7 S0 ; physical drive 7 goes forwards (rear right z motor)
M569 P8 S0 ; physical drive 8 goes forwards (center left z motor)
M569 P3 S1 ; physical drive 3 goes forwards
M569 P4 S1 ; physical drive 4 goes forwards
M350 X16 Y16 Z8 E16:16 I0 ; 1/16 microstepping for all motors, and enable microstepping interpolation up to 1/256
M92 X80.00 Y80.00 Z400.00:400.00:400.00 E420.00:420.00 ; set steps per mm
M566 X900.00 Y900.00 Z12.00:12.00:12.00 E120.00:120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00:180.00:180.00 E1200.00:1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00:20.00:20.00 E250.00:250.00 ; set accelerations (mm/s^2)
M906 X800 Y800 Z1400:1400:1400 E800:800 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout; Axis Limits
M208 X0 Y0 Z0 S1 ; set minimums for each axis
M208 X400 Y400 Z400 S0 ; set maximums for each axis
M671 X335:335:-35 Y10.5:340.5:175.5 S1 ; set leadscrew locations for auto bed leveling and max correction in mm (front right, rear right, center left leadscrews); Endstops
M574 X2 S1 P"!e1stop" ; set x endstp location at max of axis, active low endstop, mapped to e1stop on duet wifi
M574 Y2 P"nul" ; free up y endstop
M574 Y2 S1 P"!duex.e6stop" ; set y endstop location at max of axis, active low endstop, mapped to e6stop on duex5
M574 Z1 S2 ; set z axis enstop at min of axis and controlled by probe; Z-Probe
M558 P1 C"zprobe.in" H5 F120 T6000 ; set Z probe type to unmodulated/smart IR probe, connected to zprobe, dive height, feed rate, and travel speed between points
G31 P500 X0 Y0 Z2.5 ; set Z probe trigger value, XY offset and trigger height
M557 X15:215 Y15:195 S20 ; mesh grid, XY max/min values, and probe point spacing; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 R4700 ; define thermistor 0, set to bedtemp pins, thermistor type, and thermistor constants (bed thermistor)
M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.06E-8 R4700 ; define thermistor 1, set to e0temp pins, thermistor type, and thermistor constants (extruder 0 thermistor)
M308 S2 P"e1temp" Y"thermistor" T100000 B4725 C7.06E-8 R4700 ; define thermistor 2, set to e1temp pins, thermistor type, and thermistor constants (extruder 1 thermistor)
M950 H0 C"bedheat" T0 ; define heater 0, set to bedheat pins, assign temperature sensor 0 to it (bed heater)
M950 H1 C"e0heat" T1 ; define heater 1, set to e0heat pins, assign temperature sensor 1 to it (extruder 0 heater)
M950 H2 C"e1heat" T2 ; define heater 2, set to e1heat pins, assign temperature sensor 2 to it (extruder 1 heater)
M140 H0 ; assign heater 0 as the bed heater
M307 H0 A208.8 C572.6 D1.0 V24.4 B0 S1.00 ; set PID calibration constants for heater 0 calibrated at 100 deg C, disable bang-bang mode for heater 0, set pwm limit to 1.00
M307 H1 A567.6 C228.7 D4.5 V24.4 ; set PID calibration constants for heater 1 calibrated at 250 deg C
M307 H2 A555.1 C244.4 D5.0 V24.4 ; set PID calibration constants for heater 2 calibrated at 250 deg C
M143 H0 S120 ; set temperature limit for heater 0 to 120 dec C
M143 H1 S280 ; set temperature limit for heater 1 to 280 deg C
M143 H2 S280 ; set temperature limit for heater 2 to 280 deg C; Fans
M106 P0 S0 I0 F500 H-1 ; set fan number, fan speed, normal mode, PWM frequency, thermostatic mode off
M106 P1 S1 I0 F500 H1:2 T45 ; set fan number, fan speed, normal mode, PWM frequenct, thermostatic mode on for heaters 1 and 2; Tools
M563 P0 D0 H1 F0 ; define tool 0, extruder drive, heater, and fan
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C
M563 P1 D1 H2 F0 ; define tool 1, extruder drive, heater, and fan
G10 P1 X18 Y0 Z0 ; set tool 1 axis offsets
G10 P1 R0 S0 ; set initial tool 1 active and standby temperatures to 0C
M572 D0:1 S0 ; pressure advance for tools 0 and 1, amount of pressure advance (in seconds) -
@droftarts
I have tried both a fixed ip address and one assigned by the router and it hasn't helped.
I have tried connecting on my desktop (windows 10), macbook pro, ipad, and iphone and the same problem happens on all these devices -
@mike5490 said in Random disconnects DuetWifi 3.01 RC12:
As the disconnections seem to be happening when endstops are triggered, and particularly because you are using plug in connections (very tidy, but each pin is not insulated from others on those connectors, by the look of it), trace the endstop wiring very closely from board to endstop, through those connectors, and check there's no wire strands shorting out on another pin. Do disconnections happen on both X and Y endstop activation?
Other possibilities:
What endstops are you using? I can see you have 3 wires going to each endstop connection. If you're using bare microswitches, you only need to wire two wires. The third may be causing interference on endstop activation.
Check you have no wiring running alongside, or parallel to, the ribbon cable connecting the Duet and Duex. Ribbon cable is unshielded, so can pick up interference, causing false triggering or interrupted signalling. Your probe wires are close
Maybe extend the endstop cables and connect them to the Duet, and see if the problem disappears?
I know in your first post you said you have tried a different SD card, but did you try a different SD card when you swapped the boards, or are you using the same one? I'd try using a freshly formatted card, using the official SD card formatting tool. For SD card specification see https://duet3d.dozuki.com/Wiki/SD_Card#Section_Specification and the section after for formatting. There's also a section on testing write speed on that page.
I can't see anything obviously wrong with your config.g. Note that in M92, M566, M203, M201 and M906, only Extruder axes can have extra parameters (because each is an extra axis); other axes can have only one parameter, so replace all the 'Z[nnn]:[nnn]:[nnn]' with 'Z[nnn]' in these gcodes. The firmware should just ignore the extra parameters, but in older firmwares it caused problems.
M350 X16 Y16 Z8 E16:16 I0 ; 1/16 microstepping for all motors, and enable microstepping interpolation up to 1/256
M92 X80.00 Y80.00 Z400.00:400.00:400.00 E420.00:420.00 ; set steps per mm
M566 X900.00 Y900.00 Z12.00:12.00:12.00 E120.00:120.00 ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00:180.00:180.00 E1200.00:1200.00 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00:20.00:20.00 E250.00:250.00 ; set accelerations (mm/s^2)
M906 X800 Y800 Z1400:1400:1400 E800:800 I30 ; set motor currents (mA) and motor idle factor in per centThat's all I can think of at the moment!
Ian
-
@droftarts
I'll double check the connectors for any shorts tonight.
Yes the disconnects happen on both the x and y axis endstops, it doesn't seem to happen more often on one or the other.These are the endstops I'm using. I had them wired in the same way on the previous version of my printer and didn't have any issues.
Currently I'm using the new SD card that came with the new board. I'll try a freshly formatted one too.
-
Did you have the endstops wired like this? https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Makerbot_Mechanical_Endstop_v1_Num_2
-
One possibility is that the Y endstop wires are picking up noise when it is triggered (assuming it is a normally-closed switch) and that is causing an excessive rate of interrupts from the DueX5 to the Duet. In which case, one of the following may resolve it:
- connecting it to an endstop input on the main board instead
- using shielded cable for that endstop
- adding a pullup resistor between that endstop input and +3.3V (between 1K and 10K)
- adding a small capacitor (e.g. 1nF) between that endstop input and ground
-
After extending and moving the y-axis endstop connector from the duex to the duet I haven't had any more disconnects and everything seems to be working correctly.
Thank you so much.
-
@Phaedrux I get a lot of these disconnects using Vivaldi to run DWC and far fewer disconnects when using Google Chrome.
Vivaldi allows the user to reload tabs at user specified intervals but this doesn't seem to help.
Vivaldi is based on Chrome but has it's own settings for tab hibernation. Sadly it cannot be turned off. People would like control over this but so far there is none.
I should search for a browser that doesn't hibernate tabs and just use it for running DWC.
