Web interface AJAX timeouts
-
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.
