WiFi Disconnects
-
Greetings,
I've just completed building and commissioning a T3P3 Kossel Mini with DuetWifi. During the commissioning process, I had a number of disconnects. WiFi coverage is my house is generally very good.
The typical error message was:
Communication Error An AJAX error has been reported, so the current session has been terminated. Please check if your printer is still on and try to connect again.I've also had the similar message:
! Communication Error An AJAX error has been reported, so the current session has been terminated. Please check if your printer is still on and try to connect again. Error reason: timeoutI'm running the following releases:
Firmware Name: RepRapFirmware for Duet WiFi Firmware Electronics: Duet WiFi 1.0 Firmware Version: 1.18.1 (2017-04-09) WiFi Server Version: 1.03 (ch fork) Web Interface Version: 1.15aReading one of the other forum notes, I've captured output from M122. Complete text from three M122 messages are below:
M122 === Diagnostics === Used output buffers: 1 of 32 (5 max) === Platform === Static ram used: 20320 Dynamic ram used: 72808 Recycled dynamic ram: 1080 Stack ram used: 968 current, 11264 maximum Never used ram: 25600 Last reset 00:09:15 ago, cause: power up Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 33056 bytes (slot 2) 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 25.2, current 36.2, max 39.3 Supply voltage: min 11.8, current 12.2, max 12.5, 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-05-07 16:25:41 Slowest main loop (seconds): 0.019348; fastest: 0.000035 === Move === MaxReps: 3, StepErrors: 0, MaxWait: 219082ms, Underruns: 0, 0 Scheduled moves: 79, completed moves: 79 Bed compensation in use: none Bed probe heights: -0.005 -0.039 -0.004 0.027 0.025 Probe change coordinates: === Heat === Bed heater = 0, chamber heater = -1 Heater 0 is on, I-accum = 0.0 Heater 1 is on, I-accum = 0.3 === 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 Code queue is empty. === Network === WiFiServer is running SPI underruns 0, overruns 0 === Webserver === HTTP sessions: 1 of 8 --------------------------------------------------------------------------------- M122 === Diagnostics === Used output buffers: 1 of 32 (4 max) === Platform === Static ram used: 20320 Dynamic ram used: 72784 Recycled dynamic ram: 1104 Stack ram used: 968 current, 3776 maximum Never used ram: 33088 Last reset 00:07:00 ago, cause: software Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 25504 bytes (slot 3) 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 34.1, current 36.2, max 39.3 Supply voltage: min 12.3, current 12.4, max 12.5, 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-05-07 16:47:11 Slowest main loop (seconds): 0.002295; fastest: 0.000035 === Move === MaxReps: 3, StepErrors: 0, MaxWait: 2384ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 Probe change coordinates: === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 1 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 Code queue is empty. === Network === WiFiServer is running SPI underruns 0, overruns 0 === Webserver === HTTP sessions: 1 of 8 --------------------------------------------------------------------------------- M122 === Diagnostics === Used output buffers: 1 of 32 (9 max) === Platform === Static ram used: 20320 Dynamic ram used: 72784 Recycled dynamic ram: 1104 Stack ram used: 968 current, 3776 maximum Never used ram: 33088 Last reset 00:09:46 ago, cause: software Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: GCodes, available RAM 25504 bytes (slot 3) 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 34.1, current 36.2, max 38.8 Supply voltage: min 12.3, current 12.3, max 12.5, 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-05-07 16:49:56 Slowest main loop (seconds): 0.004791; fastest: 0.000061 === Move === MaxReps: 0, StepErrors: 0, MaxWait: 0ms, Underruns: 0, 0 Scheduled moves: 5, completed moves: 5 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 Probe change coordinates: === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 1 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 Code queue is empty. === Network === WiFiServer is running SPI underruns 0, overruns 0 === Webserver === HTTP sessions: 1 of 8Thanks for any advice!
John
-
If you connect via USB and send M552 S0 followed by M552 S1 then after reconnecting it will display the received signal strength.
-
Thank you for tip - I will check signal strength.
One other thought is that the printer is nearly equidistant between two access points (with the same SSID) I check both APs to see if the printer is switching between the two. I can also disable the 2.4Ghz radio on one AP to test.
-
Hi, an issue I have seen with both the DuetWifi and other hardware that use a wifi module is that the MDNS hostname resolution can fail after a while. It works initially but then some hours later, the hostname can no longer be resolved even though the duet can still be accessed using its IP address. This may be a problem specific to my particular wifi installation but i have only seen this occurring with wifi modules rather than pcs or other computers. To see if this is happening to you, determine the IP address of your duet and use that in the browser rather than the MDNS hostname (something.local). If it doesn't fail anymore, you have found the problem. I tell the DHCP server to reserve the IP address for the duet so it doesn't alter.
-
Interesting possibility. I did do a DHCP reservation, but since I was referring to the printer as <hostname>.local from my browser, it might have still been doing the the mDNS resolution instead. Another thing to try.
Thanks,
John</hostname>
-
To see if this is happening to you, determine the IP address of your duet and use that in the browser rather than the MDNS hostname (something.local). If it doesn't fail anymore, you have found the problem. I tell the DHCP server to reserve the IP address for the duet so it doesn't alter.
If I use the IP address, I don't lose connection.
I have both the DHCP reservation for the IP, but I think mDNS also comes into play, so both names are the same, so I continue to have issues. Maybe I need to change the name in config.g to be different than the one in my DHCP reservation.
Thanks, though – worst case, I use the IP address. Good, solid multi-hour connections!
-
Great, glad it's working for you now. My story on this is that I am using a wifi module in a product (not the same module as the Duet uses) and I found that after a while the mdns queries to it failed even though you could still access it using the ip address. After a lot of investigation that involved changing both the AP and the DHCP server I never got to the bottom of it. To this day I remain convinced that it is a bug in the wifi module. But then I got a duet and noticed the same thing could occur with the duet. So now I just access the duets using their ip addresses and the connections never drop out. Could still be something else that's causing the problem but I've wasted enough time already so I'm not chasing it any more. Cheers, Mark.
