CONSTANT AJAX disconnect errors
-
Well, I changed the channel for my network to a new channel just as a test, updated the machine name and password, and have been running just off of wifi for about 30 mins now.
My RSSI is -44dBm
I was missing the "P" in front of the machine name/pass in my config.g files, so that fixes the issue with the web control always showing "My Duet."
I haven't been able to print, as my G32 went crazy after the update to 1.19.2
I will continue to test.
-
I've run with channel as auto, channel 1, channel 6.
No difference for myself in ability to stay connected.
I also do have the "P" in front of machine name.I've been connected for now 2 days without dropping,, As soon as I print, or sometimes calibrate I drop connection within 20 min, sometimes 2 min.
Edit:reason I have not lost connection in 2 days is because I've been busy and not done anything with the gui, nt because I've solved the issue.
I believe this dispels any lack of signal strength reasoning. Signal is strong but for some reason once commands, prints, calibration starts causing the printer to be active the wifi connection drops, as if it can't keep parallel processes going.Edit 2: reconnecting to the laptop remotely that has the browser interface running, which ran for 2 days, and now an hour later when I reconnect it has the AJAX error and another disconnect.
-
To all of you who are experiencing disconnections, but only when the printer is not idle:
After doing a print, what is the MaxReps figure in the M122 report? Please note, MaxReps gets reset every time you run M122.
-
David, just to be clear what you are asking… when the disconnect occurs during the print do you want us to let the print complete then attempt to connect and get the M122 report or use Pronterface and do M122 while the print is running? Or something else? I just want to collect the most useful info for you.
-
It doesn't really matter. It's probably most useful if you run M122 shortly after the disconnection, and again at the end of the print.
Also please report your printer geometry, steps/mm and maximum travel speed.
-
After print completed, reconnected and M122 from DWC:
MaxReps: 411, StepErrors: 0, FreeDm: 240, MinFreeDm 120, MaxWait: 10976ms, Underruns: 0, 0
Delta, M92: 800 steps/mm M350: 64 microsteps
Max travel: X Y Z 7200
-
Thanks. The MaxReps is too high, so the step ISR is starving the webserver of CPU cycles. For now, I suggest you reduce either max travel speed or microstepping. When I have implemented dynamically varying microstepping, you will be able to increase them again.
-
is reducing microsteps to 32 enough? or do I just need to test it?
-
Reducing to 32 will probably be enough, but run M122 and check MaxReps again at the end of a print.
-
I have created a new wiki page at https://duet3d.com/wiki/WiFi_disconnections_and_AJAX_timeout_errors with suggestions for users who experience this issue.
I have it on my list to investigate the CPU starvation cause and see what can be done to reduce its impact or at least provide easier diagnosis.
-
Thanks David, will do on the M122.
The interesting thing is, how or even IF this would affect idle connectivity? Since changing this, I have not had a disconnect just idling in an hour, whereas I would barely stay connected for 10 minutes up until now.
-
No, this issue should not affect the connection when the printer is not moving, because no step interrupts will be generated. However, I've seen it once when I homed the printer with high microstepping selected, starting with the head close to the bed so that the homing move was a long one.
-
Odd! I am still connected - over 90 minutes - and until I made that change I've not stayed connected for more than 10 minutes on idle since upgrading to 1.19.2. And this is without homing or anything, just starting up and letting sit.
-
M122 via usb shortly after a disconnect during a print
MaxReps: 5, StepErrors: 0, FreeDm: 122, MinFreeDm 120, MaxWait: 246857ms, Underruns: 0, 0
WiFi signal strength -38dBm
Reconnections 0
HTTP sessions: 1 of 8 -
That all looks good, assuming you only ran M122 once so that the MaxReps value was from the whole of the print so far. Did the Ajax error message box give the error reason as Timeout? Were you able to reconnect the web interface?
-
Well, I just had the printer on and connected for about 6+ hours, 4 of which were printing. I didn't have a single disconnect from DWC on my computer and was able to connect to it multiple times from my iPhone. That is a night and day difference from when I made this post, where I was getting disconnected every few minutes. I was also plugged into USB the whole time.
The only changes I made were changing the channels on my router (the old channels were not auto, and were not defaults though) and fixing my error in my config file for the printer's name and password.
My next "test" will be to do similar tomorrow, but with the USB unplugged.
-
David, here's more information and things are not improving…
Shortly after my last post about the printer staying connected for 90 minutes, it disconnected - completely on idle. RSSI was about -81. So I installed the new wifi extender and connected Duet to it. RSSI is now -34 and stable. Every device in my office near the extender has significantly better signal. This was about 9pm yesterday.
This morning I checked and the DWC showed still connected. I homed to verify and the printer homed. Then I immediately got a disconnect. I am completely unable to connect after an hour. In Pronterface I ran M122 and it seemed to have stopped responding after partially sending the results. Here's what I got:
M221
SENDING:M221
Extrusion factor override for extruder 0: 100.0%M122
SENDING:M122
=== Diagnostics ===
Used output buffers: 32 of 32 (32 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0
Board ID: 08DAM-999TL-MQ4S8-6J9F6-3SJ6L-T4BBW
Static ram used: 21176
Dynamic ram used: 96168
Recycled dynamic rHowever, the Home button still functions butafter homing and running M122 again, I get the exact same truncated results shown above. I'm going to reboot and keep an eye on it.
-
Here's the M122 after the reboot:
M122
=== Diagnostics ===
Used output buffers: 3 of 32 (10 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0
Board ID: 08DAM-999TL-MQ4S8-6J9F6-3SJ6L-T4BBW
Static ram used: 21176
Dynamic ram used: 96104
Recycled dynamic ram: 1504
Stack ram used: 1304 current, 5116 maximum
Never used ram: 7172
Last reset 00:00:22 ago, cause: software
Last software reset reason: User, spinning module GCodes, available RAM 6932 bytes (slot 4)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
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 28.7, current 30.0, max 30.1
Supply voltage: min 24.5, current 24.6, max 24.9, under voltage events: 0, over voltage events: 0
Driver 0: stalled standstill
Driver 1: stalled standstill
Driver 2: stalled standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-09-15 09:36:48
Slowest main loop (seconds): 0.007894; fastest: 0.000034
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 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.000 0.000 0.000
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
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 idle in state(s) 0
serial is idle 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
WiFi firmware version 1.19.2
WiFi MAC address 5c:cf:7f:2b:e6:eb
WiFi Vcc 3.10, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 38904
WiFi IP address 192.168.1.190
WiFi signal strength -50dBm
Reconnections 0
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
That all looks good, assuming you only ran M122 once so that the MaxReps value was from the whole of the print so far. Did the Ajax error message box give the error reason as Timeout? Were you able to reconnect the web interface?
The print was a short one, only 5 min i think, the disconnect happened at about the 2:00 min mark, I ran the M122 command via pronterface at about 2:30 mark.
- I do not recall the Ajax error for that one, I believe it always states the same message. I'll record it next time.
- Unable to reconnect via browser connect button, maybe 20 tries, then reconnected after a wireless module off/ on command (run via paneldue as a macro)
Edit: microsteps are at 16 with interpolation.
-
After rebooting Duet I started a print. It remained connected and is still connected now after about an hour. Here is the MaxReps after the print completed:
MaxReps: 6, StepErrors: 0, FreeDm: 240, MinFreeDm 120, MaxWait: 10979ms, Underruns: 0, 0
This is after turning down microsteps from 64 to 32 as you recommended yesterday.
