Web interface AJAX timeouts
-
I was having connection issues with the original firmware shipped (had to restart the board or wifi interface, or there was a time or two where I waited an hour and it was working again), but only after a couple hours normally. The issues became more frequent with the newer firmwares for me, but I'm not sure if its actually because of the newer firmwares, since hackney has tried downgrading to the shipped firmwares with the same issues.
-
Those of you who haven't tried the new firmware bundle and are getting occasional disconnects, please can you try installing the DuetWebControl.bin from the new firmware bundle. You need to upload is to the SD card /sys directory (which you can do via the Settings page of DWC), then run M997 S2. It takes a few minutes to install, so preferably have Pronterface or a PanelDue connected so that you can see the progress and make sure it completed successfully.
-
This is interesting, using some network monitoring tools and the admin console for my Verizon Quantum router I discovered that I had a few odd things going on on my network. Several devices which I could not identify were issuing a lot of packets and that seemed to be causing timeouts. Also, the Windows laptop that I VPN in into work was chewing up a lot of bandwidth. The Quantum router supports dual frequency but none of my devices were connecting the the 5GHz. So I created a new SSID for 5GHz and connect my lap worktop to it. Now, I haven't had a single disconnect in several hours from the Duet WiFi! And the Wireshark logs looks clean as a whistle.
-
I had issues when I was using safari+the 5ghz frequency on my router so I switched and they seemed to go away. I switched to firefox because of other ajax issues I encountered, so me watching youtube etc while on the 2.4ghz frequency probably was causing the issues. I just switched back to the 5ghz network and I haven't had a disconnect in the 5 minutes its been up so its a good sign so far.
-
Since I posted it I have gotten 0 timeouts. Guess the network load really does affect it quite a lot.
-
Turns out that it was my network - it was congested. I cleaned up some devices and also repartitioned to have an explicit SSID for 5GHz and now I'm connected rock solid.
-
does the beta firmware have these changes as well? as I'm still getting timeouts with it.
-
It's really weird that some nights I get the timeouts constantly, and some nights I make it 4+ hours without one.
See my previous couple of posts. I had a very similar behavior running Duet on Wifi with the previous generation of boards. Now that I've found issues on my network and corrected them, I'm staying connected again. Could be that during those times of high disconnect someone on your network is using a lot of bandwidth? Get a copy of Wireshark and learn how to capture a basic session if you don't already. It might be very revealing as it was for me.
-
does the beta firmware have these changes as well? as I'm still getting timeouts with it.
The change that I made to try to reduce the number of ajax timeout errors was to add one retry when the browser times out waiting for a reply to a status request message. That change is included in the new DuetWebControl.bin file. You can use that file independently of which other firmware files you have installed. You can tell if you are running it because on the SettIngs page of DuetWebControl, the web interface version will be "HTML: 1.11b-dc42, JS: 1.11b-dc42".
I haven't added retries to the other message types yet. Also, if the Duet is losing the wifi connection to the router completely (which was happening to mhackney), a retry won't help and you will find that you can't reconnect unless you stop and restart the wifi module.
-
I'm running all the latest since earlier today and I've not had a single drop out yet after fixing my network problem. I suspect the issue on my network was transient. A good Wireshark capture from anyone having dropped connections should help diagnose if its a network or firmware issue.
-
I got a disconnect during a print, but it was going fine so I let it be. I came back and theres some splitting so I wanted to bump the temp up a bit, so I connected via PC to the duet, toggled the server, and I still can't connect to it. Not sure if this is related, but it says "restart Reason 6" when it starts up, not sure if thats a disconnect from wifi, or if its just saying it was turned off because of the M552 command.
-
Did you try connecting from a new browser tab?
The newer firmware decodes the restart reason, so I guess you are not running it yet.
-
I tried a new browser tab this morning. Its no longer connecting for some reason. I'm going to try updating to the latest firmware bundle. I will report back with what happens.
-
I seem to not be able to connect via the host name (eg rostock.local) but connecting via IP is working fine it seems. I'm running the latest everything right now. Not sure whats up but it seems to be running okay.
-
Being connected via IP is working well. Running a print right now that has been going for 40 min with no disconnects. The web interface is a bit buggy on the print status screen. Every once and a while the progress jumps up about 9.9% for a second and then back. Also there is a weird thing that happens when I first start a print. The progress bar jumps to 100% and sits there, and it says 100% complete, but everything else works fine. If I disconnect and reconnect manually then it starts working fine (except for the other issue I mentioned).
-
Can you post the gcode file that provokes that behaviour?
-
https://dl.dropboxusercontent.com/u/3308187/Z_endstop.gcode.zip
Theres a link to it. I still get disconnects but I've been restarting the interface and it stays connected for a while. I'll try to diagnose my network problems, theres probably some random things connected to the 2.4ghz network that are causing problems like with mhackney. I think some of my hassles will be solved when a new firmware is released that either restarts the web interface automatically or is able to reconnect it to the network.
