Wifi/DWC Disconnecting with RRF3.5.2 on Duet2 Wifi Hardware
-
@rechrtb said in Wifi/DWC Disconnecting with RRF3.5.2 on Duet2 Wifi Hardware:
mesh/multi-AP
Only one router in my house. I think the log entry just said it lost connection. Next time it happens I'll copy the log entry and post it here.
-
@DonStauffer Thank you! I initially thought that it's only the DWC reloading, but in your case the module itself seems to be disconnecting from the access point).
In the meantime, there I have another beta build. This also contain more fixes compared to the last one. If you're still inclined to try it out, it would be highly appreciated!
-
@rechrtb I'll install and test it and report back. Thanks!
-
@DonStauffer Have you had the chance to take the new beta for a spin?
Also, do you have other protocols enabled? Ftp, Mqtt, etc?(Sorry, I just remembered I can look at the M122 output to have the answer to this question) -
@rechrtb Sorry for the delay. COVID-19. I'll try to figure this out today.
-
@DonStauffer Oh no, no rush! Hope you get well soon.
-
@rechrtb It hasn't been too horrible. Just horrible enough...
Here's the console log, RRF 3.6.0 alpha 4 with the WiFi firmware you posted here; the " Incompatible software" error message is just from having the alpha RFF:
8/21/2024, 11:52:40 AM Connection interrupted, attempting to reconnect...
Operation failed (Reason: Service Unavailable)
8/21/2024, 11:52:41 AM Connection established
8/21/2024, 11:52:43 AM Connection interrupted, attempting to reconnect...
Operation failed (Reason: Service Unavailable)
8/21/2024, 11:52:43 AM Connection established
8/21/2024, 11:52:54 AM Incompatible software versions
The installed software versions do not match. Please operate your setup only at equal versions to avoid potential incompatibilities and unexpected errors. -
im having similar disconnects and I'm on ethernet with a direct run to the switch that the pc i print from is plugged into. started with 3.5.1. duet 2 ethernet 2017 vintage. I noticed it happens when i pause (m226) to insert a nut to be printed over. ftp and telnet are off.
-
-
@DonStauffer Ok, I mentioned previously I am unable to replicate the disconnect you're having. In the past builds I've given, I've just made general improvements to the stability of the WiFi firmware, hoping that it will solve your issue. I've managed to find and fix several issues in this endeavor, and I've been looking at the M122 output more closely because of this.
To that point, I looked at the previous M122 output you've made in this reply: https://forum.duet3d.com/post/341950
I just noticed:
Last software reset at 2024-07-16 11:06, reason: OutOfMemory, Gcodes spinning, available RAM 160, slot 1
Could the 'disconnects' not be actually related to the network, but the board running out of RAM? If the board crashes because it runs out of RAM, then naturally DWC will disconnect and wait until reconnection after the reset.
In the afternoons, perhaps more stuff is also in the memory (do you turn off at the end of the day and turn on in the morning)?
-
@Miss-Rebekah I see you are also on a Duet 2 (Ethernet). Though this is more of a WiFi thread, can you check the output of your M122 as well after a 'disconnect' (or what might actually be a board crash)?
(Please check this reply for context: https://forum.duet3d.com/post/344015)
-
@rechrtb I don't think the disconnects are running out of memory. They happen even when nothing is happening on the printer, and that out of memory only happens when a job fails in the middle and doesn't reclaim memory. While I've been debugging new code, that happens occasionally but not frequently like teh WiFi disconnects. A restart fixes it, and I don't have it happen too much any more, while the WiFi disconnects continue to happen. I just was assuming there's RF pollution around.
Also I've watched it happen spontaneously, the reconnect, with no reset, and there was no error. Often I'm actually just editing a macro when it happens, and I may not have even run a print job in days.
-
@DonStauffer Just to verify, next time you notice it happens, can you do an M122 immediately after? Just to be able to rule this out completely.
There is another new build which fixes an issue on the previous one (it's not related to this issue however).
-
@rechrtb I'll try to remember to do that.
-
@rechrtb Immediately after a disconnect this morning:
10/3/2024, 11:20:49 AM M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.4 (2024-08-13 15:11:39) running on Duet WiFi 1.02 or later + DueX5 Board ID: 08DGM-9T6BU-FG3SN-6JKD0-3S06Q-9AY7D Used output buffers: 3 of 26 (24 max) === RTOS === Static ram: 23368 Dynamic ram: 70472 of which 0 recycled Never used RAM 22036, free system stack 122 words Tasks: NETWORK(1,ready,13.6%,222) HEAT(3,nWait 5,0.1%,328) Move(4,nWait 5,0.0%,286) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,85.4%,610) IDLE(0,ready,0.9%,29), total 100.0% Owned mutexes: === Platform === Last reset 01:19:41 ago, cause: power up Last software reset at 2024-09-21 14:08, reason: User, Gcodes spinning, available RAM 13020, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x08 Aux0 errors 0,3,0 MCU temperature: min 33.2, current 48.3, max 48.7 Supply voltage: min 23.8, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/56, heap memory allocated/used/recyclable 4096/3124/1496, gc cycles 1004 Events: 0 queued, 0 completed Date/time: 2024-10-03 11:20:48 Slowest loop: 45.92ms; fastest: 0.10ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 8 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 9.4ms, write time 0.0ms, max retries 0 === Move === Segments created 6, maxWait 3515020ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00, mcet 0.016 Pos req/act/dcf: 60000.00/60000/0.00 0.00/0/0.00 13592.00/13592/0.00 no step interrupt scheduled Driver 0: standstill, SG min 0 Driver 1: standstill, SG min 0 Driver 2: standstill, SG min n/a Driver 3: standstill, SG min 0 Driver 4: standstill, SG min n/a Driver 5: standstill, SG min 0 Driver 6: standstill, SG min 0 Driver 7: standstill, SG min 0 Driver 8: standstill, SG min n/a Driver 9: standstill, SG min n/a Driver 10: Driver 11: === DDARing 0 === Scheduled moves 66, completed 66, LaErrors 0, Underruns [0, 0, 0] === Heat === Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 0 is on, I-accum = 0.0 === GCodes === Movement locks 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 0 0, running macro Autopause is idle in state(s) 0 Q0 segments left 0 Code queue 0 is empty === Filament sensors === check 0 clear 25429311 Extruder 0 sensor: no data received Extruder 1 sensor: no data received === DueX === Read count 1, 0.01 reads/min === Network === Slowest loop: 13.13ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 Firmware version 2.2.0beta1 MAC address 84:f3:eb:83:47:be Module reset reason: Turned on by main processor, Vcc 3.36, flash size 4194304, free heap 39196 WiFi IP address 192.168.1.130 Signal strength -41dBm, channel 11, mode 802.11n, reconnections 0 Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0