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: timeout
    
    

    I'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.15a
    
    

    Reading 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 8
    
    

    Thanks for any advice!

    John


  • administrators

    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>



  • @burtoogle:

    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.


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.