Constant HTTP timeouts after update to 3.5.3
-
Hello all,
I updated from 3.4.5 to 3.5.3 and instantly had HTTP dropouts every 20-40 sec.
Running a 6XD on ethernet, so not used to having dropout issues.
I downloaded the firmware from github and updated via the web interface, had issues, then downloaded the DuetWebControl-SD and also updated, still the same issues.
Also cleared browser cache in desperation.
shows as updated
Not sure what to do next.
m122 === Diagnostics === RepRapFirmware for Duet 3 MB6XD version 3.5.3 (2024-09-18 11:27:56) running on Duet 3 MB6XD v1.0 (standalone mode) Board ID: 08DLM-956DA-M2NS4-6J1FD-3S06Q-9A26S Used output buffers: 1 of 40 (36 max) === RTOS === Static ram: 153760 Dynamic ram: 135120 of which 0 recycled Never used RAM 54256, free system stack 198 words Tasks: NETWORK(1,ready,35.0%,172) ETHERNET(5,nWait 7,0.2%,316) HEAT(3,nWait 6,0.0%,355) Move(4,nWait 6,0.0%,335) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,339) MAIN(1,running,64.5%,128) IDLE(0,ready,0.2%,29), total 100.0% Owned mutexes: === Platform === Last reset 00:22:18 ago, cause: power up Last software reset at 2024-10-26 10:29, reason: User, Gcodes spinning, available RAM 57424, slot 2 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 MCU temperature: min 25.0, current 32.8, max 33.4 Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 11.9, current 12.1, max 14.8, under voltage events: 0 Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/352/352, gc cycles 0 Events: 4 queued, 4 completed Driver 0: ok Driver 1: ok Driver 2: ok Driver 3: ok Driver 4: ok Driver 5: ok Date/time: 2024-10-26 11:18:25 Slowest loop: 850.08ms; fastest: 0.07ms === Storage === Free file entries: 20 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 150.0ms, write time 136.4ms, max retries 0 === Move === DMs created 125, 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 === DDARing 1 === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 === GCodes === Movement locks held by null, 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 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 File2 is idle in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x0000000 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === CAN === Messages queued 6692, received 0, lost 0, errs 6318399, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 6692/0/0 Tx timeouts 0,0,6691,0,0,0 last cancelled message type 30 dest 127 === Network === Slowest loop: 137.33ms; fastest: 0.03ms Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0) HTTP sessions: 1 of 8 = Ethernet = Interface state: active Error counts: 0 0 0 1 0 0 Socket states: 5 2 2 2 2 0 0 0 === Multicast handler === Responder is inactive, messages received 0, responses 0
Anyone having this issue? It is quite debilitating.
-
@SDJ I found a post saying to increase the number of max AJAX communication to 5 from 2 under the machine-specific tab of DWC. This fixed the issue. I still don't understand why I am having these comm issues with the new firmware, especially considering that this is on an ethernet connection.
-
@SDJ if you open DWC on multiple browser tabs, the existing session may go away logically not physically on the board. Increasing the number of open AJAX connection allows for more parallel sessions, at the cost of system RAM.
-
@SDJ There have been changes to the networking code between 3.4 and 3.5, and affects WiFi and Ethernet boards. As @oliof says, running multiple browser windows connected to the same machine can cause time out errors, but as you have found out, increasing the AJAX limit can help. I don't know what the default for this normally is, but if you have updated from old versions of DWC, an old default might have been set. Let us know if you have any more issues.
Ian
-
Thanks for the info. I will ensure to close all browser windows before doing any more testing.
I am not sure it is related, but my network setup is 2x Asus rt-ax56U routers, one main, one a mesh access point connected on a wifi backbone with the duet via ethernet.
Oddly, the board no longer appears in the list of clients even though I can connect to DWC. It seems to be causing issues on my network. Unclear to me what is going in. I may redo my network and see if there is any improvement.