AJAX timeout error during a print
-
@W3DRK I'll look into that, thanks for the info
-
I am on my phone right now so can't check but I thought the latest version of DWC has the ability to set the number of AJAX timeout retries…
-
Yes you are right, I've just set it to 3 so I will see how that performs.
-
In regards to the WIFI channel selection, there are free programs available that detect and list all SSIDs in range, their strength, and the channel they are broadcasting on. This is really useful information for selecting a channel to use for your own SSID.
Microwave ovens can disturb wifi signals at 2.4Ghz. As can wireless landline telephones.
-
I'll try independently testing the increase retries for dwc (how do I set this?) and installing a WiFi access point in the room near to the printer.
-
Definitely fewer disconnects with a router in the room with the printer in it, on a clear channel and fairly close by.
-
Switched to Chrome Canary and had even fewer but still maybe 2 today in about 3-4 hours. This is not really a problem. Still unsure why these are happening though.
-
also for me i get a lot of timeouts.
it dose seem to be when its trying to do something, like download a file or during printing.
some times when i go to the G code tab it starts lagging and will not display stuff, or just time out.
I think part of this is the connection for me ( but I'm not sure of that yet) , but i though i would post for more feed back!
~Russ
-
FWIW the WiFi received signal strength is reported to the USB port when you enable WiFi. This might help diagnose connection issues. I'll make it easier to retrieve this information in a future firmware release.
-
I improved mine a lot but I've got a router 4 feet away from it. I imagine the environment immediately near to a 3d printer is not the best in terms of EMI.
Is it possible to have an external wifi antenna, in a future revision? Or the port for one if its needed?
-
We'd love to use an external antenna, and we produced a few pre-production boards with them. There are two issues that prevent us from making it standard:
1. The ESP8266 versions supporting external antenna are not FCC certified. I have read that it is impossible to get a wifi module with external antenna certified, you have to get the entire piece of equipment certified instead.
2. The version of the ESP8266 with external antenna is the ESP-08, but that has only 512kbytes or 1Mbyte flash memory, compared to the 4Mbyte flash on the ESP12F that we use. Currently we could manage with 1Mbyte, but it would limit the possibilities for firmware expansion. For the prototypes we changed the flash chip on the ESP-08, but this is not practical to do in production.
-
We might be able to supply a boards with no esp mounted from the next production run… If you then choose to mount an esp7 or 8 then that's fine. Changing the flash chip is fiddly but doable if you have a rework station.
-
I think it would be neat if the ESP's could be setup to run the web interface in a manor similar to OctoPrint so it could be used on various other controllers over a serial connection…
-
I think it would be neat if the ESP's could be setup to run the web interface in a manor similar to OctoPrint so it could be used on various other controllers over a serial connection…
It's already been done and there is a thread on the reprap.org forums about how to do it. But the file upload speed to SD card is very slow. I put a lot of effort into the Duet WiFi design and firmware into getting a good file upload speed, because I know that it matters to users.
-
Nightmare. Wireshark shows me a lot of retransmissions. Duet WiFi beta board is in about 1 meter from Mikrotik router. Mikrotik shows from -27 to -31 dBm signal strength, everything else with WiFi (TV, two phones, tablet, notebook) is working very good without any troubles.
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Version: 1.15e (2016-10-02)
WiFi Server Version: 1.02
Web Interface Version: 1.1210 ajax retries in settings.
-
Are you using that computer for anything? In my experience, albeit on a Duet 0.8.5, the web interface can disconnect/ajax error out if the computer it is running on has its cores maxed out (like when rendering, for example). Is anything like this possibly the case?
-
@bot - no, computer's CPU isn't overloaded. I'm using Intel Core 2 Quad Q6660 @2.4 GHz, Win10, FF 49.
I had never seen before so many AJAX timeouts, connection was stable and connection speed was acceptable. Nothing changed at hardware side (router and printer stay in the same positions, no wiring changed, no new metal things lay near and so on).
I think (but I'm not sure) that this is due to interference in the WiFi radio link multiplied to handling of TCP retransmits and other TCP-specific things on the ESP8266 side.
-
Are you doing ANYTHING with the computer, though? The computer has the ability to cause the ajax errors, not just the duet or the router.
Also, a Q6660 is nearly ten years old. How much ram do you have in that PC?
-
@bot - no, nothing else CPU-hungry is running both in background and foreground. 8 GB RAM is installed and quad-core Q6600 is still fast enough to show DWC page in Firefox.
It seems that this timeouts appear during the day, not at night. Now (00:38 here) DWC running for about ~20 minutes without any issues.
I'm C++ programmer with 20+ years of experience, also with 18+ years of knowledge of network programming, TCP sockets, HTTP protocol and so on. I can post raw HTTP request using telnet with hidden eyes
I'm able to distinguish browser timeouts caused by high CPU load and other errors. I'm quite comfortable in Wireshark and I saw TCP retransmits and other errors in logged traffic.I suspect that this AJAX timeouts for me caused by high WiFi network load in my area AND incorrect handling of lost TCP packets and other TCP transmit errors in sockets library from ESP8266 side. But I have to thoroughly understand the problem before I'll be something to argue.
-
It seems to me that "Maximum number of AJAX retries:" isn't working as expected for me (retry ajax requests N times on any failure) or I'm not using this right way.
I don't know why this happens but in 50%/50% issues after receiving empty response DWC shows AJAX error or just doing nothing and after this stops any further attempts to connect.
Sometimes answer from ESP8266 is really empty (ESP8266 just closes connection after receiving GET request body), sometimes ESP8266 sends correct answer but this answer appears as empty in Firefox browser. Both types of errors causes stop of any further attempts to connect.
I've never seen repeated attempts to make the request in spite of the this setting.
