Duet Wifi Webserver not responding
-
I have random disconnects to the webserver since i use the Duet Wifi (about one year), not a big deal as reloading the page reconnects immediatly.
However in the last weeks i had several disconnects and reconnect was only possibly be restarting the duet (power cycle).
I updated my firmware to 1.20 as changelog indicates some changes on wifi but the new firmeware did not help, lost connection 3 times within 1 hour.Wifi is still connected and at maximum signal strengh and i can ping the duet wifi, but the web ui won't load.
i disabled the wifi on my router and the duet wifi immediatly reconnects when reenabling the wifi.Is there some way to fix this problem or restart the duet webserver without a power cycle?
-
Today i had the same problem, webinterface did not load but ping was successful. Connected the printer via usb and executed an M122 with pronterface and got following report:
[c]
[[language]]M122
SENDING:M122
=== Diagnostics ===
Used output buffers: 1 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DAM-999TL-MQ4SD-6J1F4-3SN6J-KN9RW
Static ram used: 15448
Dynamic ram used: 99192
Recycled dynamic ram: 48
Stack ram used: 3576 current, 8608 maximum
Never used ram: 7776
Last reset 06:56:57 ago, cause: power up
Last software reset at 2018-01-27 11:42, reason: User, spinning module GCodes, available RAM 7792 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 83.7ms
MCU temperature: min 30.6, current 50.1, max 50.4
Supply voltage: min 23.5, current 24.1, max 24.5, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: ok, SG min/max 0/1023
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2018-01-27 19:56:40
Cache data hit count 4294967295
Slowest main loop (seconds): 0.085353; fastest: 0.000042
=== Move ===
MaxReps: 5, StepErrors: 0, FreeDm: 172, MinFreeDm 120, MaxWait: 2809821444ms, Underruns: 0, 0
Scheduled moves: 15628, completed moves: 15611
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X-1.708 Y-29.624 E21.7718" in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 5c:cf:7f:2c:28:22
WiFi Vcc 3.40, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 16048
WiFi IP address 192.168.178.15
WiFi signal strength -54dBm, reconnections 0, sleep mode modem
HTTP sessions: 1 of 8
Socket states: 0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
[/c]Restarting the Wifi via M552 S0 followed by M552 S1 fixed the issue.
I never use usb connection to avoid ground loop and reduce non essential wiring, so i would appreciate if the was a fix without usb connection.Had another error today where the webinterface would only load partially and the connect button did not work (connection failed), but the emergency stop button did work. So i suspect there is some 'low level' access possible without working web interface?
-
Thanks for the report. I'll think about what additional debugging information I can add to the M122 report to work out what is going on.
-
Had repeatedly another issue: Wifi won't enable after powering up the duet wifi (blue light on the wifi module stays off), a powercycle fixed this. Sadly did not execute a M122.
I just remembered a fan (at the base) burned out a few weeks ago right after powering up the duet (luckily i immediatly noticed it and turned the power off before something worse could happen). As the fan was quite hot after just a few seconds i suspect it produced a short. Could this have damaged the wifi function?
Currently im using no fan at the base as i had no spare part at hand.
Must have been very unlucky with the fans, as all three fans supplied with my T3DP3D Kossel XL failed within one year. -
A burned-out fan might damage the associated fan mosfet, but it should not affect the wifi module.
-
I remembered there are additional debug modes, enabled networking and wifi debug and got:
>>> M122 SENDING:M122 === Diagnostics === Used output buffers: 5 of 32 (31 max) === Platform === RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0 Board ID: 08DAM-999TL-MQ4SD-6J1F4-3SN6J-KN9RW Static ram used: 15448 Dynamic ram used: 99088 Recycled dynamic ram:WiFi: recv: 152 Stack ram used: 3576 current, 8592 maximum Never used ram: 7792 Last reset 00:24:57 ago, cause: power up Last software reset at 2018-01-27 11:42, reason: User, spinning module GCodes, available RAM 7792 bytes (slot 2) Software reset code 0x0003 HFSR 0WiFi: xmit: 0 x00000000, CFSR 0x00000000, ICSR 0x044WiFi: recv: 0 1f000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 [ERROR] Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min 43.5, current 43.7, max 44.7 WiFi: fw: 0 Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, oWiFi: drop: 0 ver voltage events: 0 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: standstWiFi: chkerr: 0 ill, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 2018-01-30 17:06:47 CaWiFi: lenerr: 0 che data hit count 4294967295 Slowest main loop (seconds): 0.155984; fastest: 0.000110 === Move === MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreWiFi: memerr: 0 eDm 240, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 0, completed moves: 0 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.0WiFi: rterr: 0 00 0.000 0.000 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 0 is on, I-accum = 0.0 Heater WiFi: proterr: 0 1 is on, I-accum = 0.4 === GCodes === Segments left: 0 Stack records: 1 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0WiFi: opterr: 0 file is idle in state(s) 0 serial is ready with "M122" in state(s) 0 aux is idle WiFi: err: 0 in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. Network state is running WiFi module is connected to access point Failed messages: pWiFi: cachehit: 0 ending 0, notready 0, noresp 0 WiFi firmware veWiFi: rsion 1.20 WiFi MAC address 5c:cf:7f:2c:28:22 WiFi Vcc 3.40, reset reason Turned on by main processor WiFi flash size 4194304, free heap 16248 WiFi IP address 192.168.178.15 WiFi signal strength -58dBm, reconnections 0, sleep mode modem HTTP sessioWiFi: xmit: 7 ns: 1 ofWiFi: recv: 7 8 Socket states: 0 0 0 0 0 0 0 0 Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) WiFi: fw: 0 WiFi: drop: 64 WiFi: chkerr: 0 WiFi: lenerr: 0 WiFi: memerr: 0 WiFi: rterr: 0 WiFi: proterr: 64 WiFi: opterr: 0 WiFi: err: 0 WiFi: cachehit: 4853 WiFi: WiFi: xmit: 4883 WiFi: recv: 7382 WiFi: fw: 0 WiFi: drop: 417 WiFi: chkerr: 0 WiFi: lenerr: 0 WiFi: memerr: 0 WiFi: rterr: 0 WiFi: proterr: 0 WiFi: opterr: 0 WiFi: err: 0 WiFi: cachehit: 0 WiFi: WiFi: xmit: 22 WiFi: recv: 12 WiFi: drop: 0 WiFi: chkerr: 0 WiFi: lenerr: 0 WiFi: memerr: 0 WiFi: proterr: 0 WiFi: rx_v1: 0 WiFi: rx_group: 0 WiFi: rx_general: 12 WiFi: rx_report: 0 WiFi: tx_join: 4 WiFi: tx_leave: 2 WiFi: tx_report: 16 WiFi: WiFi: xmit: 0 Was again able to ping the duet but the webpage wont load. protokoll errors and drop increase when trying to load the webpage.
-
Please try the following:
1. With network debug enabled and with the WiFi in that state (i.e. M122 or M552 says it is connected and you can ping it but not connect to it from a browser), send M586 P0 S0 from USB, followed by M586 P0 S1 to disable then enable HTTP. Watch out for any network debug messages when you do that.
2. Try installing DuetWiFiServer 1.21RC1 from https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease. It should work OK with main firmware 1.20.
-
Will try this the next time.
Until then maybe this helps:
I had the debug enabled when loosing the connection in the web interface ('Communication Error'):New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 1 for local port 80 Found responder Received 411 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 3 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 3 for local port 80 Found responder Received 475 bytes New conn on socket 4 for local port 80 Found responder Received 475 bytes New conn on socket 5 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 3 for local port 80 Found responder Received 475 bytes New conn on socket 4 for local port 80 Found responder Received 475 bytes New conn on socket 5 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 3 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 5 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 5 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 6 for local port 80 Found responder Received 475 bytes New conn on socket 5 for local port 80 Found responder Received 475 bytes New conn on socket 7 for local port 80 Found responder Received 475 bytes New conn on socket 2 for local port 80 Found responder Received 475 bytes New conn on socket 6 for local port 80 Found responder Received 475 bytes Class Network spinning Class Network spinning Class Network spinning Class Network spinning For a very long time it uses socket 0 (not included in the log above), than for a long time using socket 1 and finally in quick succession other sockets. Additionally the number of bytes increase from 411 to 475.
As reloading the webinterface got it connected again, i could not try your instructions. (now its using socket 6 and size is back to 411 bytes) -
If pressing the Connect button doesn't work but reloading the web interface does, that suggests the browser tab may have locked up, probably because of an unhandled exception. If the Connect button is completely unresponsive, try pressing control-shift-J to open the debugging console, and see whether any Javascript exceptions have been reported.
-
Sorry for the confusing order of my reports, as the problems aren't reproducable at will it have tom report them as they appear.
Just now i had again the problem of not fully loading web interface.
Restarting HTTP did not work and produced no additional messages.Here are the different errors i got from the developer tools in my browser when repeatedly loading the page: (Sorry for the german message text)
Error: Invalid dimensions for plot, width = 1647, height = 0 dwc.js:3:35051 HTTP404: NICHT GEFUNDEN: Der Server hat keine Übereinstimmungen für den angeforderten URI (Uniform Resource Identifier) gefunden. (XHR)GET - http://192.168.178.15/rr_download?name=0:/sys/oem.json Laden fehlgeschlagen für das -
Thanks, I'll ask chrishamm to take a look (he wrote DWC and is German himself).
The "oem.json not found" is normal, that's an optional file.
The "could not load the script" is odd. Are any further details given about the nature of that error?
-
No, got no further details. But it noticed sometimes it takes >30 seconds to load http://192.168.178.15/js/dwc.js in an own browser tab, so i suspect its a timeout. After restarting wifi the loadtime is consistantly around 1 second.
This javascript is very large, above 1MB (300 KB zipped) and not cached in the browser. This could probably be optimized, but should not be the root cause. But if memory is in short supply and the gzip version is created on the fly this could be a problem(?)webinterface just lost connection again, this time if found an "Unexpected state change on socket X":
New conn on socket 6 for local port 80 Found responder Received 488 bytes New conn on socket 7 for local port 80 Found responder Received 475 bytes Client disconnected on socket 6 New conn on socket 6 for local port 80 Found responder Received 475 bytes New conn on socket 7 for local port 80 Found responder Received 488 bytes New conn on socket 6 for local port 80 Found responder Received 475 bytes Unexpected state change on socket 7 New conn on socket 7 for local port 80 Found responder Received 488 bytes New conn on socket 6 for local port 80 Found responder Received 475 bytes Unexpected state change on socket 7 New conn on socket 7 for local port 80 Found responder Received 488 bytes New conn on socket 6 for local port 80 Found responder Received 488 bytes Unexpected state change on socket 7 -
What make and model is your router?
-
Hi!
Same problem. Try connect … connect ... connect ... F5 ... nothing.
I connect via USB. I make Disable Wi-Fi / Enable Wi-Fi. After that it works 1 hour ... 2 ... 3 hours ... Ping is always stable (2-100 ms).
1.20 firmware.
-
I'm using a Fritz!Box 7490.
Just now lost connection again (webinterface won't load at all, but ping is successful) and tried your instruction but with no usefull output during deactivating/activating http and couldn't connect after that.
>>> M552 SENDING:M552 WiFi module is connected to access point ewl-internet.ch_40357, IP address 192.168.178.15 >>> M586 P0 S0 SENDING:M586 P0 S0 HTTP is disabled >>> M586 P0 S1 SENDING:M586 P0 S1 HTTP is enabled on port 80 I tried rebooting the Fritz!Box and duet wifi will timeout while trying to reconnect (as booting the router takes about a minute). I reactivated wifi with M552 S1 but webinterface will still not load. Diable/Enable HTTP did again not help. (ping does work)
Disabling and reenabling Wifi (M552 S0 M552 S1) did bring the webinterface back.
So M552 S0 seems to "unblock" the webinterface.Did not yet update the webserver to 1.21, will do next.
-
Tonight i printed a model and closed the webinterface windwo in the brower.
This morning i couldn't connect to the webinterface (but ping still ok), so its probably not the polling from the webinterface thats causing the issue.
The log only contains about a hundret entries "Class Network spinning", no error messages. -
When you are unable to connect but able to ping, if you run M552 without parameters, does it report that the Duet is connected to your network, or not?
-
Yes, i actually included that part in my last message because i thought you would ask that
>>> M552 SENDING:M552 WiFi module is connected to access point ewl-internet.ch_40357, IP address 192.168.178.15 -
Updated Webserver to 1.21.RC1 and immediatly having an instable connection, debug log:
WiFi: fGLUE: fragmented pbuf (932!=1514)! WiFi: GLUE: fragmented pbuf (932!=1514)! WiFi: GLUE: fragmented pbuf (932!=1514)! WiFi: GLUE: fragmented pbuf (932!=1514)! [...] When reloading the page:
Unexpected state change on socket 0 Can't send anymore New conn on socket 0 for local port 80 HTTP connection accepted Found responder New conn on socket 5 for local port 80 HTTP connection accepted Found responder Received 330 bytes Sending reply, file = yes HTTP req, command words { GET / HTTP/1.1 }, parameters { } Received 339 bytes Sending reply, file = yes HTTP req, command words { GET /css/dwc.css HTTP/1.1 }, parameters { } New conn on socket 0 for local port 80 HTTP connection accepted Found responder Received 357 bytes Sending reply, file = yes HTTP req, command words { GET /js/dwc.js HTTP/1.1 }, parameters { } WiFi: GLUE: fragmented pbuf (788!=1514)! [...] Still having the same issue with http://192.168.178.15/js/dwc.js
When the connection is stable there are no messages with 'WiFi: GLUE: fragmented pbuf <…>', so this might be the cause of the problem.
Edit:
Additionally there is a problem with the html in line 1708:should be
-
Webinterface was online 6 hours without a problem then failed again.
I used Wireshark to capture the network traffic, maybe this can help fpr further analysis.This happened in the moment the connection was lost:
https://www.dropbox.com/sh/r9zkw9id482i9z0/AAA-x0NTtIISPxijZnqTiZj0a/Wireshark_DuetWifi.PNG?dl=0
This was from Microsoft Edge Browser. So my PC sent an reset and from then on all requests to the duet wifi return a reset. This continues until the ajax retry limit is reached (i set it to 50 retries).
I found other occurences earlier where my PC closed the connection but a new one could be established without problems.Then tried to open the webinterface in a different browser (Firefox) and got:
https://www.dropbox.com/sh/r9zkw9id482i9z0/AADPnonPL1ApvNZzF8qBnV-Va/Wireshark_DuetWifi_2.PNG?dl=0I suspect for some reason all available sockets from the wifi module in the duet to the internal modules get blocked and won't be unblocked until restarting the wifi. This would explain why the wifi connection works in general (can ping and open tcp connection) but it fails when trying to get the status report.