Unsolved Duet 2 WiFi network slowdowns and board restarts
-
This is possibly related to https://forum.duet3d.com/topic/35833/duet-3-mini5-nightly-restarts but is a bit characteristically different as well as being for a different board, so I opened a new thread. Can combine if that is for the best. The incidents in this issue are less common and restarts tend to happen when specific events happen instead of when idle like in the linked thread.
We have been having occasional issues with Duet 2 WiFi boards with network functionality when the Duet is a client on our network. This has been the case for internal and external antenna versions of the board, and firmware 3.4.5 and 3.5.1 as well as the release candidates in-between. This issue does not seem to occur when the machine is hosting the connection.
The issue tends to begin with periodically dropped connections to DWC, as well as slow responses to actions in DWC, and also results in file upload speeds slowing down to single digit KiB/s or lower. Another symptom is that sending an M122 will take a while but then only be responded to with "M122" and no actual diagnostics reported. Additionally, if DWC is opened initially or refreshed, there is a very high likelihood it will become stuck with just a white screen, or a partially loaded version of the UI with messed up formatting. When in this state, there is a high occurrence of board reset crashes when one of the following events occur:
M552 command is sent to set the WiFi module to idle (S0) or client (S1).
Turning the router off and on again.Sending the M552 S0 in this state almost always produces the "another SPI transfer is pending" warning message.
Machine uptime does not seem to make a difference as it can continue to be a problem after a crash reset, hard power off and on, or in the case of this morning just after the machine is turned on after it was off over the weekend. When the issues happen it does seem to effect multiple machines at the same time, though the rate of slowdown/issues and likelihood to restart is not the same across machines while not being tied to one machine or another across incidents.
Resetting the connection via M552 does not seem to clear this issue all that often. Powering the board/machine off and on again can sometimes improve things for a short while. The best solution we have found is resetting our router, which will usually clear up issues for up to several weeks, though sometimes less than a day can pass before issues start to crop up again.
Current firmware:
RRF = 3.5.1
DWC = 3.5.1
Wi-Fi = 2.1.0There is a Duex5 board connected in our machines.
Here is an M122 I got this morning after a reset with P500 S0 options applied. This reset was caused by using M552 commands and took place before a router reset to clear the issue, and it was still presenting problems at the time this M122 report was generated.
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.1 (2024-04-19 14:40:46) running on Duet WiFi 1.02 or later + DueX5v0.11 Board ID: 0JD2M-9F8TA-GJ4TJ-6JKDG-3S06P-9RUQ7 Used output buffers: 1 of 26 (22 max) === RTOS === Static ram: 23256 Dynamic ram: 74824 of which 16 recycled Never used RAM 15048, free system stack 182 words Tasks: NETWORK(1,ready,12.6%,220) HEAT(3,nWait 5,0.1%,328) Move(4,nWait 5,0.0%,359) DUEX(5,nWait 5,0.0%,24) MAIN(1,running,86.1%,739) IDLE(0,ready,1.2%,29), total 100.0% Owned mutexes: === Platform === Last reset 00:01:04 ago, cause: software Last software reset at 2024-06-24 09:23, reason: HardFault bfarValid precise, Gcodes spinning, available RAM 15048, slot 2 Software reset code 0x0063 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x0041f803 BFAR 0x25040230 SP 0x20003540 Task NETW Freestk 530 ok Stack: 20015324 25040230 25040582 20015323 20005a3c 0041560b 004001de 810d0000 0045b65b 20011260 0041560b 20011264 00000001 00000001 200114b0 00000352 feff0ddc 200114b0 00416ed1 a5a5a5a5 a5a5a5a5 a5a5a5a5 00416f13 00000000 25040230 00000352 00000000 Error status: 0x00 MCU temperature: min 32.7, current 33.2, max 33.6 Supply voltage: min 24.0, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: standstill, SG min n/a Driver 1: standstill, SG min n/a Driver 2: standstill, SG min n/a Driver 3: standstill, SG min n/a Driver 4: standstill, SG min n/a Driver 5: standstill, SG min n/a Driver 6: standstill, SG min n/a Driver 7: standstill, SG min n/a Driver 8: standstill, SG min n/a Driver 9: standstill, SG min n/a Driver 10: Driver 11: Date/time: 2024-06-24 09:25:47 Cache data hit count 2258914684 Slowest loop: 8.70ms; fastest: 0.20ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 9 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 3.5ms, write time 4.0ms, max retries 0 === Move === DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00 no step interrupt scheduled Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0 === DDARing 0 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters 0 1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 2 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 Autopause is idle in state(s) 0 Q0 segments left 0 Code queue 0 is empty === Filament sensors === check 0 clear 509884 Extruder 0: pos 2252.81, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1 sensor: no filament === DueX === Read count 1, 0.93 reads/min === Network === Slowest loop: 18.78ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 2 of 8 === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 Firmware version 2.1.0 MAC address 4c:75:25:1b:b9:2d Module reset reason: Power up, Vcc 3.14, flash size 2097152, free heap 36432 WiFi IP address 10.1.10.213 Signal strength -62dBm, channel 11, mode 802.11n, reconnections 0 Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0
Here is the relevant section of the log file.
2024-06-24 09:16:53 [debug] === Network === 2024-06-24 09:16:53 [debug] Slowest loop: 302.94ms; fastest: 0.00ms 2024-06-24 09:16:53 [debug] Responder states: 2024-06-24 09:16:53 [debug] HTTP(3) 2024-06-24 09:16:53 [debug] HTTP(0) 2024-06-24 09:16:53 [debug] HTTP(0) 2024-06-24 09:16:53 [debug] FTP(0) 2024-06-24 09:16:53 [debug] Telnet(0) 2024-06-24 09:16:53 [debug] HTTP sessions: 1 of 8 2024-06-24 09:16:53 [debug] === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 2024-06-24 09:16:53 [debug] Firmware version 2.1.0 2024-06-24 09:16:53 [debug] MAC address 4c:75:25:1b:b9:2d 2024-06-24 09:16:53 [debug] Module reset reason: Power up, Vcc 3.46, flash size 2097152, free heap 37288 2024-06-24 09:16:53 [debug] WiFi IP address 10.1.10.213 2024-06-24 09:16:53 [debug] Signal strength -61dBm, channel 11, mode 802.11n, reconnections 0 2024-06-24 09:16:53 [debug] Clock register 00002002 2024-06-24 09:16:53 [debug] Socket states: 2024-06-24 09:16:53 [debug] 3 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:53 [debug] 0 2024-06-24 09:16:56 [warn] HTTP client 10.1.10.161 login succeeded (session key 1755196080) 2024-06-24 09:17:32 [warn] HTTP client 10.1.10.161 login succeeded (session key 1745141368) 2024-06-24 09:18:13 [warn] HTTP client 10.1.10.161 login succeeded (session key 259321250) 2024-06-24 09:18:59 [warn] HTTP client 10.1.10.161 login succeeded (session key 1167928987) 2024-06-24 09:19:56 [warn] HTTP client 10.1.10.161 login succeeded (session key 1381950929) 2024-06-24 09:20:29 [warn] HTTP client 10.1.10.161 login succeeded (session key 1413621398) 2024-06-24 09:20:41 [warn] HTTP client 10.1.10.161 login succeeded (session key 1123249425) 2024-06-24 09:20:58 [warn] HTTP client 10.1.10.161 login succeeded (session key 2071828845) 2024-06-24 09:20:59 [warn] WiFi module is idle 2024-06-24 09:21:02 [debug] ok 2024-06-24 09:21:08 [warn] WiFi module is connected to access point SD3D-24, IP address 10.1.10.213 2024-06-24 09:21:08 [warn] HTTP client 10.1.10.161 login succeeded (session key 1927545457) 2024-06-24 09:21:12 [warn] HTTP client 10.1.10.9 login succeeded (session key 1465680804) 2024-06-24 09:22:17 [warn] HTTP client 10.1.10.161 login succeeded (session key 2059841738) 2024-06-24 09:23:19 [warn] HTTP client 10.1.10.161 login succeeded (session key 176217279) power up + 00:00:00 [info] Event logging started at level debug power up + 00:00:00 [info] Running: Duet WiFi 1.02 or later: 3.5.1 (2024-04-19 14:40:46) power up + 00:00:00 [debug] Done! power up + 00:00:00 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet is up and running. power up + 00:00:01 [warn] WiFi module started power up + 00:00:08 [warn] WiFi module is connected to access point SD3D-24, IP address 10.1.10.213 power up + 00:00:08 [warn] HTTP client 10.1.10.161 login succeeded (session key 1824904060) 2024-06-24 09:24:52 [warn] Date and time set at power up + 00:00:08 2024-06-24 09:24:53 [warn] HTTP client 10.1.10.9 login succeeded (session key 801089966) 2024-06-24 09:24:56 [warn] HTTP client 10.1.10.9 login succeeded (session key 1344075519) 2024-06-24 09:25:07 [warn] HTTP client 10.1.10.9 login succeeded (session key 0) 2024-06-24 09:25:47 [debug] === Diagnostics === 2024-06-24 09:25:47 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.1 (2024-04-19 14:40:46) running on Duet WiFi 1.02 or later + DueX5v0.11 2024-06-24 09:25:47 [debug] Board ID: 0JD2M-9F8TA-GJ4TJ-6JKDG-3S06P-9RUQ7 2024-06-24 09:25:47 [debug] Used output buffers: 1 of 26 (22 max) 2024-06-24 09:25:47 [debug] === RTOS === 2024-06-24 09:25:47 [debug] Static ram: 23256 2024-06-24 09:25:47 [debug] Dynamic ram: 74824 of which 16 recycled 2024-06-24 09:25:47 [debug] Never used RAM 15048, free system stack 182 words 2024-06-24 09:25:47 [debug] Tasks: 2024-06-24 09:25:47 [debug] NETWORK(1,ready,12.6%,220) 2024-06-24 09:25:47 [debug] HEAT(3,nWait 5,0.1%,328) 2024-06-24 09:25:47 [debug] Move(4,nWait 5,0.0%,359) 2024-06-24 09:25:47 [debug] DUEX(5,nWait 5,0.0%,24) 2024-06-24 09:25:47 [debug] MAIN(1,running,86.1%,739) 2024-06-24 09:25:47 [debug] IDLE(0,ready,1.2%,29) 2024-06-24 09:25:47 [debug] , total 100.0% Owned mutexes: 2024-06-24 09:25:47 [debug] === Platform === 2024-06-24 09:25:47 [debug] Last reset 00:01:04 ago, cause: software
Please let me know if there is any additional information I can provide that could prove useful. Unfortunately specific testing is difficult as I cannot predict if I may see the issue again tomorrow, or not for another couple of months. But, if there is anything to test when the issue next presents itself I should be able to do so.
-
@ProteanReverie That list of symptoms seems sounds more like a problem with your router rather than with the the Duet boards. Do you have other devices connected to the same 2.4GHz WiFi network? Do they also slow down? Many routers have an option to have them restart at a preset time (usually in the middle of the night) every week, if yours does you might want to try enabling it.
-
@gloomyandy thank you for your response.
I do suspect there is something going on with our router/network causing this since this is not a more widely reported issue, but we have not been able to successfully diagnose thus far as well as it being more connected to router resets than duet resets. Several months ago we did try changing various router settings as well as adding a range extender and having the Duets connect to that, but we would still encounter the issue. Unfortunately, I do not have information on what changes were attempted at that time.
The hardfault crash reset of Duet boards does seem like an issue/concern on the Duet end.
We currently have 4 windows PCs, 2-3 cellphones, 3 blink cameras, 2 tablets, and 3 office phones also on the network, as well as anywhere from 2-8 total Duets. I have seen this happen with 2PCs, 1 cell, 2 tablets, 1 office phone and 2 duets in the past. Nothing else on the network has ever had issues with network slowdown or showing any issue that we have been able to detect, even when then the issue is present with DWC.
A regular reset bandaid could work for our office, but as a printer OEM building machines with these boards to be sold to customers, a better understanding would be preferred in case customers encounter such issues.
-
@ProteanReverie It's a long shot, but... it does seem possible that Duets are a bit susceptible to malformed Ethernet packets coming from the network. Some other users have reported similar issues, and the Hardfaults seem to be related to networking, and occasionally oddly setup browsers. @dc42 has often asked what extra languages are installed in these cases, as it seems foreign characters or character sets can trigger the Duet crash.
What made me think of this is when you say you have '3 blink cameras' on your network. Security cameras are a favourite target for hackers, that can then be used to snoop on the local network (strange packets) as well as launch DoS attacks. The Blink camera does seem susceptible: https://www.electronicshub.org/can-blink-cameras-be-hacked/
Running a WireShark scan of the network for a while, and capturing any strange packets, particularly at the point when the Duet crashes, may be useful. It would be great to track this one down!
Ian
-
@ProteanReverie it might be worth setting up a macro that disables wifi using M552 S-1, delays for a few seconds using G4, then restarts wifi using M552 S1. Resetting the connection in this way may be simpler than resetting the Duet or the router.
-
@droftarts said in Duet 2 WiFi network slowdowns and board restarts:
@ProteanReverie It's a long shot, but... it does seem possible that Duets are a bit susceptible to malformed Ethernet packets coming from the network. Some other users have reported similar issues, and the Hardfaults seem to be related to networking, and occasionally oddly setup browsers. @dc42 has often asked what extra languages are installed in these cases, as it seems foreign characters or character sets can trigger the Duet crash.
What made me think of this is when you say you have '3 blink cameras' on your network. Security cameras are a favourite target for hackers, that can then be used to snoop on the local network (strange packets) as well as launch DoS attacks. The Blink camera does seem susceptible: https://www.electronicshub.org/can-blink-cameras-be-hacked/
Running a WireShark scan of the network for a while, and capturing any strange packets, particularly at the point when the Duet crashes, may be useful. It would be great to track this one down!
Ian
No extra languages are set up on any of the PCs or tablets, or any other devices to my knowledge.
I am aware to some extent the security issues present with networked cameras and will keep an eye on that. Nothing that I have seen so far has indicated to me that they have been compromised at any point, but those kinds of things not being able to be noticed is usually a key point so can't say for sure.
I have got wireshark set up, and next time I see issues I will run a capture focused on the IP of one of the machines to share here. I plan to take it through a file upload (which will likely fail) as well as some network interface resets which hopefully cause the restart while doing that capture. If there are other actions I should take during that capture, please let me know.
@dc42 said in Duet 2 WiFi network slowdowns and board restarts:
@ProteanReverie it might be worth setting up a macro that disables wifi using M552 S-1, delays for a few seconds using G4, then restarts wifi using M552 S1. Resetting the connection in this way may be simpler than resetting the Duet or the router.
I actually wrote that exact macro a couple of years ago when having other issues which were later resolved. I still use it from time to time when I see this issue crop up, though often times when the issue is present the interface will be so inaccessible that I cannot activate the macro so it is easier to connect via serial to send commands or just power cycle the machine. Thank you for the recommendation.
-
I happened to encounter the issue again this morning. I did not get a board reset this time, but did get data from Wireshark. At the start of this capture I was able to upload a file of size 70kb. This was followed by attempts to upload a file of size 11,365kb. This file never succeeded in uploading, and was transfering at speeds under 5kb/s, as low as 300b/s from what I observed. The first upload attempt reached about 45% before restarting and then failing at about 5%. After each failed upload I tried the M552 commands a couple of times to try and induce a board reset, but this did not occur. There are multiple upload attempts with multiple M552s in between each upload attempt within the packet capture. Near the end of the capture I had done another M552 S0 which the console responded to by letting me know that the WiFi module was idle, as expected. However, the M552 S1 that followed that and subsequent S0/S1s only responded with "ok" and I could not get it to reconnect, so I power cycled the machine and ended the capture.
During this capture I was able to normally use the network outside of DWC without issue, including an internet speed test from the PC that was uploading the files, which looked normal without any speed concerns. 3 other people were present in the office and working online without noticing any issues with the network. Whatever is happening only seems to impact the Duets/DWC.
The Duet is IP 10.1.10.38, and my PC is 10.1.10.9. All captures below were taken with a filter for 10.1.10.38.
Here is the packet capture discussed above:
6-27-24-uploads-M552s-nocrash-failconnectatend.pcapngHere is an additional capture, taken after the first one. During this the machine was printing, and while I still had DWC up on my PC it was not connected, with the blue "Connecting..." popup sitting at a static 0% for the duration.
6-27-24-printing-notconnected-issuepresent.pcapngIn case it helps for comparison, here is a packet capture I took yesterday when the issue was not occurring, where I uploaded a file of size 27066kb at over 250kb/s without issue:
6-26-24.pcapng -
@ProteanReverie this starts to sound more like an SD card writing issue, now. Please can you run the tests described in this section of the wiki, and post the results: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues
Ian
-
@droftarts said in Duet 2 WiFi network slowdowns and board restarts:
@ProteanReverie this starts to sound more like an SD card writing issue, now. Please can you run the tests described in this section of the wiki, and post the results: https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues
Ian
I have run those test on two Duets/machines, after a 3+ hour print on each, with results below. Do note that the issue was not occurring at the time these tests were done. Also, when the issue occurs it seems to impact all machines. I can confirm both of the tested machines were having the issue at the same time this morning.
The machine that the packet captures came from:
Test 1 - M122
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 7.4ms, write time 145.6ms, max retries 0Test 2 - M39
SD card in slot 0: capacity 7.95GB, partition size 7.94GB, free space 7.47GB, speed 20.00MBytes/sec, cluster size 64kBTest 3 - M122 P104 S10
SD write speed for 10.0MByte file was 2.87MBytes/sec
SD read speed for 10.0MByte file was 1.31MBytes/secTest 4 - M22
Error: M22: SD card has open file(s)Other machine:
Test 1 - M122
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 12.3ms, write time 146.4ms, max retries 0Test 2 - M39
SD card in slot 0: capacity 7.95GB, partition size 7.94GB, free space 7.54GB, speed 20.00MBytes/sec, cluster size 32kBTest 3 - M122 P104 S10
SD write speed for 10.0MByte file was 2.40MBytes/sec
SD read speed for 10.0MByte file was 1.23MBytes/secTest 4 - M22
Error: M22: SD card has open file(s)I did not get the chance today to remove the SD cards to try the windows application in those troubleshooting steps.
-
@ProteanReverie Okay, thanks for testing the SD cards, both look pretty normal. I forgot you said that it affects multiple machines at once in your first post.
Is there any other sources of WiFi interference around? Microwave ovens, cordless phones, baby monitors, or noisy electric motors (eg old fridge)? Re-reading the whole thread, it does feel like it's an issue with the router.
Ian
-
@droftarts said in Duet 2 WiFi network slowdowns and board restarts:
@ProteanReverie Okay, thanks for testing the SD cards, both look pretty normal. I forgot you said that it affects multiple machines at once in your first post.
Is there any other sources of WiFi interference around? Microwave ovens, cordless phones, baby monitors, or noisy electric motors (eg old fridge)? Re-reading the whole thread, it does feel like it's an issue with the router.
Ian
Interference could be a possibility. We do have a couple of cordless office phones, though they aren't used often. We do also have a microwave, but timing of usage does not line up. However, we are in a multi-business building and wedged in between two other companies. It is unknown what interference generators they may have.
-
undefined Phaedrux marked this topic as a question
-
undefined ProteanReverie referenced this topic
-
Had another case today. This time it only appeared to only be an issue one Duet system, but it seemed like the usual issue from this thread. The slowdown/inaccessibility issue persisted through multiple power-cycles, multiple uses of [M552 S-1] followed by [M552 S1], and switching to host mode with [M552 S2] and then going back to client mode. Everything seemed to work just fine in host mode, as usual. There were no resets during this.
This Duet 2 was running on firmware version 3.6.0A2+3. A Duet 3 also running 3.6.0A2+3 did not appear to be affected. Additionally, two Duet 2s running 3.5.2 did not seem to exhibit symptoms and DWC stayed connected the whole time I was monitoring them while the one with the issue was having its problem.
I ran a packet capture, the Duet is 10.1.10.38. Before long this devolved into only showing requests from my PC (10.1.10.9) to find the Duet, while the Duet seemed completely unreachable. I stopped the capture in case the connection would not be recovered to prevent a needlessly long file. That is the first packet capture here. Then, in case it did reconnect I started a new capture, which did see a point where the Duet was able to re-establish communications, though it continued to disconnect from DWC shortly after any time it did connect.
8-9-24-A3-D2-idle-disconnect.pcapng
8-9-24-A3-D2-idle-reconnect.pcapngI was also able to get M122 data via serial console, which I have pulled to share here from the log file. The first M122 was run during the period of time where the packet capture showed the board as completely unreachable, right around where the capture was stopped and then restarted. The second M122 was run shortly after it reconnected, while still being too unstable to get the M122 through DWC.
Disconnected:
2024-08-09 12:09:57 [debug] WiFi module is connected to access point SD3D-24, IP address 10.1.10.38 ok 2024-08-09 12:24:13 [debug] === Diagnostics === 2024-08-09 12:24:13 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.2+3 (2024-07-17 20:03:21) running on Duet WiFi 1.02 or later + DueX5v0.11 2024-08-09 12:24:13 [debug] Board ID: 0JD2M-9F8TA-GJ4TN-6J1DD-3S46S-17SU6 2024-08-09 12:24:13 [debug] Used output buffers: 1 of 26 (24 max) 2024-08-09 12:24:13 [debug] === RTOS === 2024-08-09 12:24:13 [debug] Static ram: 23368 2024-08-09 12:24:13 [debug] Dynamic ram: 70144 of which 12 recycled 2024-08-09 12:24:13 [debug] Never used RAM 24192, free system stack 134 words 2024-08-09 12:24:13 [debug] Tasks: 2024-08-09 12:24:13 [debug] NETWORK(1,ready,64.1%,217) 2024-08-09 12:24:13 [debug] ACCEL(6,nWait 5,0.0%,249) 2024-08-09 12:24:13 [debug] HEAT(3,nWait 5,0.1%,328) 2024-08-09 12:24:13 [debug] Move(4,nWait 5,0.0%,274) 2024-08-09 12:24:13 [debug] DUEX(5,nWait 5,0.0%,23) 2024-08-09 12:24:13 [debug] MAIN(1,running,35.8%,501) 2024-08-09 12:24:13 [debug] IDLE(0,ready,0.0%,29) 2024-08-09 12:24:13 [debug] , total 100.0% Owned mutexes: 2024-08-09 12:24:13 [debug] WiFi(NETWORK) 2024-08-09 12:24:13 [debug] USB(MAIN) 2024-08-09 12:24:13 [debug] === Platform === 2024-08-09 12:24:13 [debug] Last reset 01:18:37 ago, cause: power up 2024-08-09 12:24:13 [debug] Last software reset at 2024-08-06 15:49, reason: HeatTaskStuck, Gcodes spinning, available RAM 26972, slot 0 2024-08-09 12:24:13 [debug] Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004818 Task ACCE Freestk 4294954872 ok 2024-08-09 12:24:13 [debug] Stack: 00000000 200041bc 10000000 e000e000 006dc7e3 0045d535 0045dc80 61000000 0045dc69 20005370 2000d448 00011d4a 2000d478 200041a8 200041b0 20004c78 0042f4a5 2000d448 a5a5a5a5 a5a5a5a5 20004c78 a5a5a5a5 0042f54b a5a5a5a5 0045c459 a5a5a5a5 a5a5a5a5 2024-08-09 12:24:13 [debug] Error status: 0x00 2024-08-09 12:24:13 [debug] MCU temperature: min 32.3, current 33.0, max 34.3 2024-08-09 12:24:13 [debug] Supply voltage: min 24.1, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes 2024-08-09 12:24:13 [debug] Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0 2024-08-09 12:24:13 [debug] Events: 0 queued, 0 completed 2024-08-09 12:24:13 [debug] Date/time: 2024-08-09 12:24:13 [debug] 2024-08-09 12:24:13 2024-08-09 12:24:13 [debug] Slowest loop: 1005.96ms; fastest: 0.21ms 2024-08-09 12:24:13 [debug] I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 2024-08-09 12:24:13 [debug] === Storage === Free file entries: 9 2024-08-09 12:24:13 [debug] SD card 0 detected, interface speed: 20.0MBytes/sec 2024-08-09 12:24:13 [debug] SD card longest read time 104.0ms, write time 101.0ms, max retries 0 2024-08-09 12:24:13 [debug] === Move === Segments created 15, maxWait 1915146ms, 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.025 2024-08-09 12:24:13 [debug] Pos req/act/dcf: 80000.00/79999/1.00 -4.00/-3/-1.00 6400.00/6400/0.00 88056.00/88056/0.00 2024-08-09 12:24:13 [debug] no step interrupt scheduled 2024-08-09 12:24:13 [debug] === DDARing 0 === Scheduled moves 4, completed 4, LaErrors 0, Underruns [0, 0, 0] 2024-08-09 12:24:13 [debug] Driver 0: standstill, SG min 0 2024-08-09 12:24:13 [debug] Driver 1: standstill, SG min 5 2024-08-09 12:24:13 [debug] Driver 2: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 3: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 4: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 5: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 6: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 7: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 8: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 9: standstill, SG min n/a 2024-08-09 12:24:13 [debug] Driver 10: 2024-08-09 12:24:13 [debug] Driver 11: 2024-08-09 12:24:13 [debug] === Heat === 2024-08-09 12:24:13 [debug] Bed heaters 0 1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 2024-08-09 12:24:13 [debug] Heater 2 is on, I-accum = 0.0 2024-08-09 12:24:13 [debug] === GCodes === 2024-08-09 12:24:13 [debug] Movement locks held by null 2024-08-09 12:24:13 [debug] HTTP is idle in state(s) 0 2024-08-09 12:24:13 [debug] Telnet is idle in state(s) 0 2024-08-09 12:24:13 [debug] File is idle in state(s) 0 2024-08-09 12:24:13 [debug] USB is ready with "m122" in state(s) 0 2024-08-09 12:24:13 [debug] Aux is idle in state(s) 0 2024-08-09 12:24:13 [debug] Trigger is idle in state(s) 0 2024-08-09 12:24:13 [debug] Queue is idle in state(s) 0 2024-08-09 12:24:13 [debug] LCD is idle in state(s) 0 2024-08-09 12:24:13 [debug] Daemon is idle in state(s) 0 2024-08-09 12:24:13 [debug] Autopause is idle in state(s) 0 2024-08-09 12:24:13 [debug] Q0 segments left 0 2024-08-09 12:24:13 [debug] Code queue 0 is empty 2024-08-09 12:24:13 [debug] === Filament sensors === check 0 clear 14997920 2024-08-09 12:24:13 [debug] Extruder 0 sensor: ok 2024-08-09 12:24:13 [debug] Extruder 1 sensor: ok 2024-08-09 12:24:13 [debug] === DueX === Read count 1, 0.01 reads/min 2024-08-09 12:24:13 [debug] === Network === 2024-08-09 12:24:13 [debug] Slowest loop: 302.78ms; fastest: 0.00ms 2024-08-09 12:24:13 [debug] Responder states: 2024-08-09 12:24:13 [debug] HTTP(0) 2024-08-09 12:24:13 [debug] HTTP(0) 2024-08-09 12:24:13 [debug] HTTP(0) 2024-08-09 12:24:13 [debug] FTP(0) 2024-08-09 12:24:13 [debug] Telnet(0) 2024-08-09 12:24:13 [debug] HTTP sessions: 0 of 8 2024-08-09 12:24:13 [debug] === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 16435, noresp 41 2024-08-09 12:24:13 [debug] Failed to get WiFi status 2024-08-09 12:24:13 [debug] Socket states: 2024-08-09 12:24:13 [debug] 6 2024-08-09 12:24:13 [debug] 6 2024-08-09 12:24:13 [debug] 0 2024-08-09 12:24:13 [debug] 4 2024-08-09 12:24:13 [debug] 0 2024-08-09 12:24:13 [debug] 0 2024-08-09 12:24:13 [debug] 0 2024-08-09 12:24:13 [debug] 0 2024-08-09 12:24:13 [debug] ok
Post re-connect, unstable:
2024-08-09 12:49:30 [debug] === Diagnostics === 2024-08-09 12:49:30 [debug] RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.2+3 (2024-07-17 20:03:21) running on Duet WiFi 1.02 or later + DueX5v0.11 2024-08-09 12:49:30 [debug] Board ID: 0JD2M-9F8TA-GJ4TN-6J1DD-3S46S-17SU6 2024-08-09 12:49:30 [debug] Used output buffers: 1 of 26 (24 max) 2024-08-09 12:49:30 [debug] === RTOS === 2024-08-09 12:49:30 [debug] Static ram: 23368 2024-08-09 12:49:30 [debug] Dynamic ram: 70144 of which 12 recycled 2024-08-09 12:49:30 [debug] Never used RAM 24192, free system stack 134 words 2024-08-09 12:49:30 [debug] Tasks: 2024-08-09 12:49:30 [debug] NETWORK(1,ready,48.4%,217) 2024-08-09 12:49:30 [debug] ACCEL(6,nWait 5,0.0%,249) 2024-08-09 12:49:30 [debug] HEAT(3,nWait 5,0.1%,328) 2024-08-09 12:49:30 [debug] Move(4,nWait 5,0.0%,274) 2024-08-09 12:49:30 [debug] DUEX(5,nWait 5,0.0%,23) 2024-08-09 12:49:30 [debug] MAIN(1,running,51.5%,501) 2024-08-09 12:49:30 [debug] IDLE(0,ready,0.0%,29) 2024-08-09 12:49:30 [debug] , total 100.0% Owned mutexes: 2024-08-09 12:49:30 [debug] WiFi(NETWORK) 2024-08-09 12:49:30 [debug] === Platform === 2024-08-09 12:49:30 [debug] Last reset 01:43:54 ago, cause: power up 2024-08-09 12:49:30 [debug] Last software reset at 2024-08-06 15:49, reason: HeatTaskStuck, Gcodes spinning, available RAM 26972, slot 0 2024-08-09 12:49:30 [debug] Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004818 Task ACCE Freestk 4294954872 ok 2024-08-09 12:49:30 [debug] Stack: 00000000 200041bc 10000000 e000e000 006dc7e3 0045d535 0045dc80 61000000 0045dc69 20005370 2000d448 00011d4a 2000d478 200041a8 200041b0 20004c78 0042f4a5 2000d448 a5a5a5a5 a5a5a5a5 20004c78 a5a5a5a5 0042f54b a5a5a5a5 0045c459 a5a5a5a5 a5a5a5a5 2024-08-09 12:49:30 [debug] Error status: 0x00 2024-08-09 12:49:30 [debug] MCU temperature: min 32.4, current 33.3, max 33.8 2024-08-09 12:49:30 [debug] Supply voltage: min 24.1, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes 2024-08-09 12:49:30 [debug] Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/12/12, gc cycles 0 2024-08-09 12:49:30 [debug] Events: 0 queued, 0 completed 2024-08-09 12:49:30 [debug] Date/time: 2024-08-09 12:49:30 [debug] 2024-08-09 12:49:30 2024-08-09 12:49:30 [debug] Slowest loop: 673.42ms; fastest: 0.21ms 2024-08-09 12:49:30 [debug] I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 2024-08-09 12:49:30 [debug] === Storage === Free file entries: 9 2024-08-09 12:49:30 [debug] SD card 0 detected, interface speed: 20.0MBytes/sec 2024-08-09 12:49:30 [debug] SD card longest read time 104.0ms, write time 100.8ms, max retries 0 2024-08-09 12:49:30 [debug] === Move === Segments created 15, maxWait 0ms, 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.000 2024-08-09 12:49:30 [debug] Pos req/act/dcf: 79999.00/79999/1.00 -3.00/-3/-1.00 6400.00/6400/0.00 88056.00/88056/0.00 2024-08-09 12:49:30 [debug] no step interrupt scheduled 2024-08-09 12:49:30 [debug] === DDARing 0 === Scheduled moves 4, completed 4, LaErrors 0, Underruns [0, 0, 0] 2024-08-09 12:49:30 [debug] Driver 0: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 1: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 2: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 3: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 4: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 5: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 6: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 7: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 8: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 9: standstill, SG min n/a 2024-08-09 12:49:30 [debug] Driver 10: 2024-08-09 12:49:30 [debug] Driver 11: 2024-08-09 12:49:30 [debug] === Heat === 2024-08-09 12:49:30 [debug] Bed heaters 0 1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 2024-08-09 12:49:30 [debug] Heater 2 is on, I-accum = 0.0 2024-08-09 12:49:30 [debug] === GCodes === 2024-08-09 12:49:30 [debug] Movement locks held by null 2024-08-09 12:49:30 [debug] HTTP is idle in state(s) 0 2024-08-09 12:49:30 [debug] Telnet is idle in state(s) 0 2024-08-09 12:49:30 [debug] File is idle in state(s) 0 2024-08-09 12:49:30 [debug] USB is idle in state(s) 0 2024-08-09 12:49:30 [debug] Aux is idle in state(s) 0 2024-08-09 12:49:30 [debug] Trigger is idle in state(s) 0 2024-08-09 12:49:30 [debug] Queue is idle in state(s) 0 2024-08-09 12:49:30 [debug] LCD is idle in state(s) 0 2024-08-09 12:49:30 [debug] Daemon is idle in state(s) 0 2024-08-09 12:49:30 [debug] Autopause is idle in state(s) 0 2024-08-09 12:49:30 [debug] Q0 segments left 0 2024-08-09 12:49:30 [debug] Code queue 0 is empty 2024-08-09 12:49:30 [debug] === Filament sensors === check 0 clear 21956288 2024-08-09 12:49:30 [debug] Extruder 0 sensor: ok 2024-08-09 12:49:30 [debug] Extruder 1 sensor: ok 2024-08-09 12:49:30 [debug] === DueX === Read count 0, 0.00 reads/min 2024-08-09 12:49:30 [debug] === Network === 2024-08-09 12:49:30 [debug] Slowest loop: 302.74ms; fastest: 0.08ms 2024-08-09 12:49:30 [debug] Responder states: 2024-08-09 12:49:30 [debug] HTTP(0) 2024-08-09 12:49:30 [debug] HTTP(0) 2024-08-09 12:49:30 [debug] HTTP(0) 2024-08-09 12:49:30 [debug] FTP(0) 2024-08-09 12:49:30 [debug] Telnet(0) 2024-08-09 12:49:30 [debug] HTTP sessions: 1 of 8 2024-08-09 12:49:30 [debug] === WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 22587, noresp 91 2024-08-09 12:49:30 [debug] Firmware version 2.1.0 2024-08-09 12:49:30 [debug] MAC address 48:55:19:09:31:80 2024-08-09 12:49:30 [debug] Module reset reason: Power up, Vcc 3.38, flash size 2097152, free heap 23616 2024-08-09 12:49:30 [debug] WiFi IP address 10.1.10.38 2024-08-09 12:49:30 [debug] Signal strength -59dBm, channel 1, mode 802.11n, reconnections 0 2024-08-09 12:49:30 [debug] Clock register 00002002 2024-08-09 12:49:30 [debug] Socket states: 2024-08-09 12:49:30 [debug] 4 2024-08-09 12:49:30 [debug] 0 2024-08-09 12:49:30 [debug] 4 2024-08-09 12:49:30 [debug] 4 2024-08-09 12:49:30 [debug] 0 2024-08-09 12:49:30 [debug] 0 2024-08-09 12:49:30 [debug] 0 2024-08-09 12:49:30 [debug] 0
Since then, I had the Duet in host mode for about a half an hour to get some other things done, and then switched back to client mode. The issue was no longer present after switching back that time.