CONSTANT AJAX disconnect errors

KeeganB · 15 Sept 2017, 07:10

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.

mhackney · 15 Sept 2017, 13:36

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 r

However, 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.

mhackney · 15 Sept 2017, 13:37

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)

Jarery · 15 Sept 2017, 13:39

@dc42:

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.

mhackney · 15 Sept 2017, 14:25

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.

KeeganB · 15 Sept 2017, 23:07

Well, I spoke too soon.

Yesterday's print was done via DWC over about 3-4 hours with the USB cord plugged in the whole time.

Today I disconnected the USB, connected to DWC, and started a print. before the hot end even finished preheating it has disconnnected and I was unable to reconnect.

M122
SENDING:M122
=== Diagnostics ===
Used output buffers: 3 of 32 (9 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4SD-6JTF0-3S86N-TLWZX
Static ram used: 21176
Dynamic ram used: 96168
Recycled dynamic ram: 1440
Stack ram used: 4048 current, 9068 maximum
Never used ram: 3220
Last reset 01:43:44 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 4348 bytes (slot 0)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
[ERROR] Error status: 0

Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 75.2ms
MCU temperature: min 30.2, current 33.1, max 33.8
Supply voltage: min 11.6, current 11.8, max 12.3, under voltage events: 0, over voltage events: 0
Driver 0: stalled
Driver 1: stalled
Driver 2: stalled
Driver 3: stalled
Driver 4: standstill
Date/time: 2017-09-15 19:05:18
Slowest main loop (seconds): 0.104980; fastest: 0.000000
=== Move ===
MaxReps: 4, StepErrors: 0, FreeDm: 164, MinFreeDm 144, MaxWait: 962417ms, Underruns: 4, 0
Scheduled moves: 422, completed moves: 403
Bed compensation in use: none
Bed probe heights: 0.021 -0.103 0.041 0.235 0.119
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X7.961 Y8.640 E11.0987" 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
WiFi firmware version 1.19.2
WiFi MAC address 5c:cf:7f:ef:51:6f
WiFi Vcc 3.10, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 39712
WiFi IP address 10.0.1.38
WiFi signal strength -44dBm
Reconnections 0
HTTP sessions: 2 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)

KeeganB · 16 Sept 2017, 00:19

I just came back to my computer and the Safari window that had DWC in it was up, and it had apparently reconnected itself?

T3P3Tony · 16 Sept 2017, 08:21

Keegan is there a correlation between USB cable plugged in and stability of the connection?

KeeganB · 16 Sept 2017, 09:40

@T3P3Tony:

Keegan is there a correlation between USB cable plugged in and stability of the connection?

I really have no idea. It was a theory I was testing. After a couple days of disconnects I noticed my first successful 4hr print with 6hr connection time was when I was also plugged in to USB. Then the next day I tried it without the USB and got nearly an immediate disconnect. Then about an hour later the same DWC window in Safari had reconnected on its own?! It's been working and connected since then for nearly 10 hours. (No usb)

KeeganB · 17 Sept 2017, 00:06

The last two failures both happened within minutes of starting a print. I didn't get the diags for the first failure, but interestingly enough it came back online by itself and worked fine until a few seconds after starting the second print. Here is the M122 after the second print and subsequent AJAX failure. I suspect this will come back online again too, sometime in the middle of the print.

M122
SENDING:M122
=== Diagnostics ===
Used output buffers: 5 of 32 (13 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.19.2 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4SD-6JTF0-3S86N-TLWZX
Static ram used: 21176
Dynamic ram used: 96280
Recycled dynamic ram: 1328
Stack ram used: 4048 current, 9104 maximum
Never used ram: 3184
Last reset 04:50:44 ago, cause: power up
Last software reset reason: User, spinning module GCodes, available RAM 4348 bytes (slot 0)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 8
[ERROR] Error status: 8

Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 35.7, current 35.9, max 36.2
Supply voltage: min 11.7, current 11.8, max 12.1, under voltage events: 0, over voltage events: 0
Driver 0: stalled
Driver 1: stalled
Driver 2: stalled
Driver 3: stalled
Driver 4: standstill
Date/time: 2017-09-16 20:04:42
Slowest main loop (seconds): 0.003906; fastest: 0.000000
=== Move ===
MaxReps: 4, StepErrors: 0, FreeDm: 221, MinFreeDm 189, MaxWait: 2ms, Underruns: 0, 0
Scheduled moves: 2311, completed moves: 2306
Bed compensation in use: none
Bed probe heights: -0.019 -0.083 -0.078 0.096 -0.127
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "G1 X25.168 Y2.626 E93.1502" 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
WiFi firmware version 1.19.2
WiFi MAC address 5c:cf:7f:ef:51:6f
WiFi Vcc 3.11, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 39392
WiFi IP address 10.0.1.38
WiFi signal strength -46dBm
Reconnections 1
HTTP sessions: 2 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)

dc42 · 17 Sept 2017, 06:31

Thanks. I can't see anything wrong in the M122 report. it's interesting that you have a a reconnection count of 1 indicating that the WiFi module became disconnected from the router and successfully connected again, even though you have a very high signal strength.

KeeganB · 17 Sept 2017, 15:44

David,

I think I have established a bit of a pattern in my situation. It seems that right at the beginning of every new print, it disconnects. Then sometime after that (I estimate between 15-30mins) it just reconnects itself and is fine from then until I start the next print.

dc42 · 17 Sept 2017, 16:04

I did a little investigation this morning, and I found that for homing moves (i.e. G1 S1 moves), the maximum step rate possible is many times lower than for ordinary moves. So a high microstepping value can cause MaxReps to get very high during a homing move even if the combination of M350 microstepping and M203 maximum speeds is OK for normal moves. So if your print files have a G28 homing command at the start, that could be why you get a disconnection at the start of a print. The workaround for this particular issue is to use slower homing moves.

KeeganB · 17 Sept 2017, 17:02

I will try slower homing moves. I don't have a separate G28 at the start of my prints, but there is on inside of beg.g that runs (as G32) at the start of all prints.

My micro stepping is 16x

I should add though, that it doesn't necessarily disconnect during the homing move, sometimes it can be a few minutes into the print.

dc42 · 17 Sept 2017, 17:20

I would not expect you to have this problem with only x16 microstepping.

Jarery · 18 Sept 2017, 00:26

Similar to KeeganB, my board is set to 16x micro stepping (with interpolation).
I also do not have a G28 homing in any of my Gcode but as KeeganB states in my Bed command is a G28 at the start. After that the Gcode has no homing until finished.

My disconnects happen early in a print but unlike KeeganB, mine has never reconnected on its own that I'm aware of.
I have never seen the reconnect count above 0.
Edit: mine don't always happen only near start of a print, just that they are a high chance at start. Mine also disconnects just sitting idle sometime.

I'm about a week away from commissioning a second delta with another duet wifi, based on dc42's large Kossel build. So in a week or so I'll be able to tell if both boards exhibit the same behaviour in my wifi network or if its specific to the one board.

lolorc · 18 Sept 2017, 08:09

Hi there.

I also have the constant disconnections.
the disconnections also happen when the printer is idle…

I also have a tons of issue uploading g-code files through wifi. (when usb is plugged)

BlackTom · 18 Sept 2017, 14:08

I have had the same kind of issue with 1.19.2, 1.19 is correct.

I had issues when I was running my bed compensation routine and I had it too when I was printing,
I always finish by being disconnected of the web interface when I print and I cannot reconnect to it.

The print continue without issue until it's done so it doesn't affect it

The only way to get back access to the web interface is by powering off / on the board,

lolorc · 18 Sept 2017, 14:26

@bloood3d:

The only way to get back access to the web interface is by powering off / on the board,

same here.

bot · 18 Sept 2017, 15:57

What about when you do a "hard refresh" of the web page through the web browser? On chrome this is done by holding the CTRL key while clicking refresh. In the past, this has helped me get back into a web interface session.