Unsolved [RRF3.11-3.2b3][DUET2WIFI] DWC constantly disconnects/reconnects
Good afternoon all,
I recently purchased a Duet 2 WiFi board and configured it to control my Ender 3 Pro. Everything was working fine with the board but after a couple of days I started getting a lot of connection resets when trying to upload gcode to the board over WiFi, to the point where I would need to try each upload 10+ times before the file would upload successfully.
Browsing these forums and looking at the WiFi troubleshooting guide, I checked my RSSI and found it was at -68 which is obviously not great. To remedy this I moved the printer much closer to my access point and was able to get the RSSI up to about -35, but the connectivity issues have not gone away.
The following day, the web interface became basically inaccessible, disconnecting and reconnecting constantly (sometimes as frequently as 4x in one minute). The disconnect errors are either:
Connection interrupted, attempting to reconnect... Network error # Note: This is the most common error
Connection interrupted, attempting to reconnect... Cannot read property 'seqs' of undefined # Note: This particular error may have only started appearing after upgrading to 3.2b2 as a troubleshooting step
I suspect this may be a hardware problem due to the fact that the signal strength is so good and the wifi "experience" is above 90% in UniFi, however I did try some additional troubleshooting steps based on reading through similar threads on these forums.
- Configured a new, 2.4ghz-only SSID
- Experimented with different channels (1, 3, 4, 6, 11)
- Experimented with 20mhz and 40mhz channel bandwidth
- Experimented with higher and lower AP broadcast power
I also tried the following additional troubleshooting steps on the device itself:
- Cleared the list of remembered networks and rejoined
- Cleared the SD card and rebuilt a new card using the configurator
- Reloaded firmware for the Duet board, the wifi server and DWC
- Upgraded to RRF 3.2b3 with updated wifi server and DWC (this is where the board is now)
The issue persists after all of these steps. At this point I am starting to think that the wifi module itself may be defective but I am hopeful that someone here has some experience that could help.
Can you share the results of M122?
Does the light on the wifi module go out when there are disconnects?
Cannot read property 'seqs' of undefined
This may be a more informative error message from the newer wifi server version 1.24 that would have come with the 3.2b3 update. @dc42 might have a better idea what it means.
Thanks for the quick reply!
Here's the output of M122:
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta3 running on Duet WiFi 1.02 or later Board ID: 08DJM-9178L-L2MSD-6JTDA-3SD6Q-KSDAN Used output buffers: 3 of 24 (24 max) === RTOS === Static ram: 23996 Dynamic ram: 100472 of which 60 recycled Never used RAM 5520, free system stack 118 words Tasks: NETWORK(ready,183) HEAT(blocked,308) MAIN(running,448) IDLE(ready,19) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 02:39:46 ago, cause: software Last software reset at 2020-11-11 12:12, reason: User, GCodes spinning, available RAM 5520, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 0x04 MCU temperature: min 29.0, current 31.1, max 31.4 Supply voltage: min 24.0, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 13880, standstill, SG min/max 0/189 Driver 1: position 10280, standstill, SG min/max 0/161 Driver 2: position 2400, standstill, SG min/max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2020-11-11 14:52:09 Cache data hit count 4294967295 Slowest loop: 13.70ms; fastest: 0.17ms 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 4.0ms, write time 4.1ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 169, MinFreeDm: 167, MaxWait: 6796914ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 7, completed moves 7, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 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 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: 49.95ms; 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.24 WiFi MAC address 84:0d:8e:ad:74:93 WiFi Vcc 3.44, reset reason Turned on by main processor WiFi flash size 4194304, free heap 23200 WiFi IP address 192.168.1.89 WiFi signal strength -47dBm, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
The light does not turn off, and I don't see any messages in the console on the PanelDue that indicate that wifi disconnected.
Another possibility is that there is an IP address conflict between the Duet and something else.
That's a great suggestion and something that I had not checked. I looked through my AP and firewall logs and have not seen anything else using that IP.
I also confirmed that there are no ICMP responses on that IP when the Duet board is powered off, so I think the answer to that question is No.