Wifi module keeps disconnecting
-
Don't suppose there's any way to enable WPS for the ESP module?
-
Well some routers like the TP-Link one that DC mentioned have a AP Mode where they connect to your main router on a cable and then act as a WiFi access point that routes stuff to your main router. It's a while since I looked at the settings on a BT Hub?
-
Ah, might have solved it. I've moved the wifi booster to a new location and reset. Rebooted the router, WPS the booster in the new spot, fired up the Duet and it connected. Turned the Duet off and on several times, and it's reconnected each time… :-0
I think what may have been happening is that the booster was intermittently losing the wifi from the router. It doesn't give any indication the signal has been lost, it just reconnects immediately. But I noticed once I got it connected, that it dropped and the Duet claimed it was still connected because it had an IP address. Then after a few minutes it got back on as the booster sorted itself out. This is just a complete guess though - TBH I have no idea and I have no intention to move the booster back to the old spot to find out!!
Fingers crossed this is it!
-
I just want to give a heads up to anyone who might suffer similar issues to this.
I did get a robust solution eventually. My wifi signal booster, a cheap tp-link model, gives you the option to not only boost the wifi signal, but to also to "extend" it by giving it another name (but still sharing the same password). You'll need the tp-link app to set this up.
I placed the signal booster in the same room as my printer. Using the app, I then added an 'x' to the SSID name of my wifi extension. I then set the Duet to only connect to the wifi extension, not the general wifi. Provided you connect your laptop or whatever to the same extension, you should guarantee a robust connection with the DWC.
I think all the issues I had were some sort of signal interference or configuration between the router's wifi and the booster wifi. I never got to the bottom of the issues, but creating the wifi extension via the signal booster cured all the issues. The Duet never drops the connection now.
I hope this might help someone at some point - the dropped connections had me tearing my hair out and it's so hard to find out what's wrong.
The TP-link app for the wifi signal booster really saved the day for me in this instance!
-
Thanks for sharing your solution.
-
I've had 1.20 installed for 2 days now. After say 15mins of use get an unrecoverable wifi disconnect. Which is to say am unable to reconnect again. If I open a new browser window and try to go to the IP address the error will be "the server unexpectedly dropped the connection". So it is there but not responding. Also unable to ping from that point on.
In addition have noticed that no longer see the network name for the Duet at the wifi router. Before nor after the "disconnect". Just a "*".
Here's the moment Pinging stopped:
[c]
64 bytes from 192.168.0.128: icmp_seq=23555 ttl=255 time=8.044 ms
64 bytes from 192.168.0.128: icmp_seq=23556 ttl=255 time=113.279 ms
64 bytes from 192.168.0.128: icmp_seq=23557 ttl=255 time=40.027 ms
64 bytes from 192.168.0.128: icmp_seq=23558 ttl=255 time=29.561 ms
64 bytes from 192.168.0.128: icmp_seq=23559 ttl=255 time=19.960 ms
64 bytes from 192.168.0.128: icmp_seq=23560 ttl=255 time=4.129 ms
64 bytes from 192.168.0.128: icmp_seq=23561 ttl=255 time=4.433 ms
64 bytes from 192.168.0.128: icmp_seq=23562 ttl=255 time=4.404 ms
64 bytes from 192.168.0.128: icmp_seq=23563 ttl=255 time=6.956 ms
64 bytes from 192.168.0.128: icmp_seq=23564 ttl=255 time=5.140 ms
64 bytes from 192.168.0.128: icmp_seq=23565 ttl=255 time=4.366 ms
64 bytes from 192.168.0.128: icmp_seq=23566 ttl=255 time=4.298 ms
64 bytes from 192.168.0.128: icmp_seq=23567 ttl=255 time=4.431 ms
64 bytes from 192.168.0.128: icmp_seq=23568 ttl=255 time=4.811 ms
ping: sendto: Network is down
Request timeout for icmp_seq 23569
Request timeout for icmp_seq 23570
Request timeout for icmp_seq 23571
Request timeout for icmp_seq 23572[/c]
And here's the M122 that I get whilst printing and after the Duet is no longer responding to web requests. Have connected by USB.
Have been through the wifi/ajax help page a dozen times. Any further suggestions much appreciated.
[c]
SENT: m122
SENT: M105
READ: === Diagnostics ===
READ: Used output buffers: 2 of 32 (14 max)
READ: === Platform ===
READ: RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
READ: Board ID: 08D6M-91AST-L23S4-7JTDL-3SD6N-96X5K
READ: Static ram used: 15448
READ: Dynamic ram used: 99064
READ: Recycled dynamic ram: 176
READ: Stack ram used: 3576 current, 8592 maximum
READ: Never used ram: 7792
READ: Last reset 01:18:15 ago, cause: power up
READ: Last software reset at 2018-03-11 05:37, reason: User, spinning module GCodes, available RAM 11904 bytes (slot 3)
READ: Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
READ: Error status: 0
READ: Free file entries: 9
READ: SD card 0 detected, interface speed: 12.0MBytes/sec
READ: SD card longest block write time: 40.6ms
READ: MCU temperature: min 27.5, current 31.1, max 31.4
READ: Supply voltage: min 24.1, current 24.3, max 24.8, under voltage events: 0, over voltage events: 0
READ: Driver 0: ok, SG min/max 0/192
READ: Driver 1: ok, SG min/max 0/1023
READ: Driver 2: ok, SG min/max 65/278
READ: Driver 3: ok, SG min/max 0/1023
READ: Driver 4: standstill, SG min/max not available
READ: Date/time: 2018-03-11 08:38:16
READ: Cache data hit count 4294967295
READ: Slowest main loop (seconds): 0.160038; fastest: 0.000042
READ: === Move ===
READ: MaxReps: 4, StepErrors: 0, FreeDm: 227, MinFreeDm 120, MaxWait: 463565ms, Underruns: 0, 0
READ: Scheduled moves: 6152, completed moves: 6147
READ: Bed compensation in use: mesh
READ: Bed probe heights: 0.000 0.000 0.000 0.000 0.000
READ: === Heat ===
READ: Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
READ: Heater 0 is on, I-accum = 0.3
READ: Heater 1 is on, I-accum = 0.5
READ: === GCodes ===
READ: Segments left: 1
READ: Stack records: 1 allocated, 0 in use
READ: Movement lock held by null
READ: http is idle in state(s) 0
READ: telnet is idle in state(s) 0
READ: file is doing "G1 E1.6000 F2700" in state(s) 0
READ: serial is ready with "m122" in state(s) 0
READ: aux is idle in state(s) 0
READ: daemon is idle in state(s) 0
READ: queue is idle in state(s) 0
READ: autopause is idle in state(s) 0
READ: Code queue is empty.
READ: Network state is running
READ: WiFi module is idle
READ: Failed messages: pending 0, notready 0, noresp 0
READ: WiFi firmware version 1.20
READ: WiFi MAC address 5c:cf:7f:2b:ee:bb
READ: WiFi Vcc 3.42, reset reason Turned on by main processor
READ: WiFi flash size 4194304, free heap 18344
READ: HTTP sessions: 1 of 8
READ: Socket states: 0 0 0 0 0 0 0 0
READ: Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
READ: ok
READ: ok T:204.6 /205.0 B:70.0 /70.0
[/c]What seems to have changed vis a vis when it was working are the nearly last lines. Before they read:
[c]
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
[/c] -
HTTP(1) means that one HTTP responder is processing a request.
Suggestions:
1. Work through https://duet3d.dozuki.com/Wiki/WiFi_disconnections_and_AJAX_timeout_errors if you haven't already.
2. Try upgrading to main firmware 1.21RC3 (or RC4 which I hope to release later today) and wifi firmware 1.21RC4. Read the upgrade notes first.
-
Thanks. The wifi help page already done many times. Eager to try the upgrades.
The links to the Betas at the following address do not work and haven't been able to find them browsing/searching Github?
https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_Betas
-
OK have figured out that the correct URL for the Betas is:
https://github.com/dc42/RepRapFirmware/tree/dev/EdgeRelease
(Note: @dc42 - links in the guide need updating)
-
Upgrades performed. First check is the wifi modem.
Bizarrely not only is the host name wrong in the modem but also the Mac Address? (Yet the IP is that of the Duet and I can connect to webcontrol.)
How can this be?config.g reads:
M550 PBigBoxPro
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Addresswifi router says:
mac address: 5C:CF:7F:2B:EE:BB
IP: 192.168.0.128
host name: *M122 reveals the following mac address:
5c:cf:7f:2b:ee:bb
Which matches what the Router is saying yet is different from config.g.
So config.g is not being taken into account? How so?
Here it is:[c]; Configuration file for BigBox 3D printer
; Communication and general
M111 S0 ; Debug off
M550 PBigBoxPro ; Machine name and Netbios name (can be anything you like)
M551 Preprap ; Machine password (used for FTP)
;*** If you have more than one Duet on your network, they must all have different MAC addresses, so change the last digits
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
;*** Wifi Networking
M552 S1 ; Enable WiFiM555 P2 ; Set output to look like Marlin
M575 P1 B57600 S1 ; Comms parameters for PanelDue
; Movement section
M569 P0 S1 ; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes forwards - Z axis
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S1 ; Drive 4 goes forwards
M574 X1 Y1 Z1.2 S1 ; set endstop configuration (X and Y endstops only, at low end, active high)
M906 X800 Y600 Z800 E1000 ; Set motor currents (mA)
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X8000 Y8000 Z360 E1000 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M208 X300 Y240 Z270 ; set axis maxima (adjust to suit your machine)
M208 X0 Y0 Z-0.2 S1 ; set axis minimum (adjust to make X=0 and Y=0 the edge of the bed)
M92 X160 Y360 Z1600 ; Set axis steps/mm
M92 E304:354 ; Set extruder steps per mm
G21 ; Work in millimetres
G90 ; Send absolute coordinates…
M83 ; ...but relative extruder moves
M350 X16 Y16 E16 I1 ; Set 256x microstepping with interpolation; Z probe section
M558 P1 X0 Y0 Z1 H3 F200 T5000 ; Smart IR Z probe, used for homing Z axis, dive height 3mm, probe speed 200mm/min, travel speed 5000mm/min
G31 X-5 Y35 Z1.90 P500 ; Set the probe height and threshold (put your own values here)
G29 S1 ; load height map from mesh levelling; Heater and thermistor section
M305 P1 X200 ; specify channel PT400 board
;*** If you have a Duet board with 1K thermistor series resistors, change R4700 to R1000 to the following M305 commands: set to R400 if using PT100 daughter board
M305 P0 T100000 B4388 R4700 H30 L0 ; Put your own H and/or L values here to set the heated bed thermistor ADC correction
M305 P1 T100000 B4388 R400 H30 L0 ; Put your own H and/or L values here to set the first nozzle PT100
;M305 P2 R400 H0 L0 ; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
M301 H1 P10 I0.10 D100 T0.50 S1.0 ; default PID settings for extruder 0 (over-ruled by below FOPD settings from calibration)
M301 H2 P10 I0.10 D100 T0.50 S1.0 ; default PID settings for extruder 1M307 H1 A384.2 C170.8 D9.5 B0 ;FOPD nozzle calibration system overrides above M301
M307 H0 A225.5 C555.7 D4.3 B0 ;FOPD bed calibration system overrides above M301M570 S120 ; Increase to allow extra heating time if needed
M106 F10 ; Fix for Bigbox Blower - Drop Blower Fan PWM from 250 to 10 Hz per Tim Elmore
M106 P1 F22500 S0.4 T40 H1 ; Trigger hotend 1 (left) fan at 40 C, PWM 40% @ 22500Hz; Tool definition section
M563 P0 D0 H1 ; Define tool 0 to use extruder drive 0 and heater 1
G10 P0 S0 R0 ; Set tool 0 operating and standby temperatures
;*** If you have a dual-nozzle build, un-comment the following 2 lines
;M563 P1 D1 H2 ; Define tool 1
;G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures; Bed probe section (not needed if you use a bed.g file)
;*** Adjust the XY coordinates in the following M557 commands to suit your build and the position of your Z probe
M557 P0 X60 Y0 ; Four...
M557 P1 X60 Y165 ; ...probe points...
M557 P2 X200 Y165 ; ...for bed...
M557 P3 X200 Y0 ; ...levelling
;M557 P4 X141 Y82.5 ; 5th probe point for levelling (un-comment this to get a 5th point at the centre of the bed); Epilogue
;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0 ; Axis compensation here
T0[/c] -
See under M540 in the GCore wiki page at https://duet3d.dozuki.com/.
-
Thanks for the heads up on M540.
Still have the permanently–not-responding-over-wifi problem.
When it's in that state this is what M122 looks like now under 1.21RC3:
[c]SENT: m122
READ: === Diagnostics ===
READ: Used output buffers: 5 of 32 (14 max)
READ: === Platform ===
READ: RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21RC3 running on Duet WiFi 1.0 or 1.01
READ: Board ID: 08D6M-91AST-L23S4-7JTDL-3SD6N-96X5K
READ: Static ram used: 16144
READ: Dynamic ram used: 100448
READ: Recycled dynamic ram: 2192
READ: Stack ram used: 3568 current, 4648 maximum
READ: Never used ram: 7640
READ: Last reset 00:57:47 ago, cause: software
READ: Last software reset at 2018-03-11 13:17, reason: User, spinning module GCodes, available RAM 3752 bytes (slot 1)
READ: Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
READ: Error status: 0
READ: Free file entries: 10
READ: SD card 0 detected, interface speed: 12.0MBytes/sec
READ: SD card longest block write time: 0.0ms
READ: MCU temperature: min 30.6, current 30.8, max 31.1
READ: Supply voltage: min 24.5, current 24.6, max 24.6, under voltage events: 0, over voltage events: 0
READ: Driver 0: standstill, SG min/max not available
READ: Driver 1: standstill, SG min/max not available
READ: Driver 2: standstill, SG min/max not available
READ: Driver 3: standstill, SG min/max not available
READ: Driver 4: standstill, SG min/max not available
READ: Date/time: 2018-03-11 14:14:53
READ: Slowest main loop (seconds): 0.156608; fastest: 0.000047
READ: === Move ===
READ: MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
READ: Scheduled moves: 0, completed moves: 0
READ: Bed compensation in use: mesh
READ: Bed probe heights: 0.000 0.000 0.000 0.000 0.000
READ: === Heat ===
READ: Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
READ: Heater 1 is on, I-accum = 0.0
READ: === GCodes ===
READ: Segments left: 0
READ: Stack records: 1 allocated, 0 in use
READ: Movement lock held by null
READ: http is idle in state(s) 0
READ: telnet is idle in state(s) 0
READ: file is idle in state(s) 0
READ: serial is ready with "m122" in state(s) 0
READ: aux is idle in state(s) 0
READ: daemon is idle in state(s) 0
READ: queue is idle in state(s) 0
READ: autopause is idle in state(s) 0
READ: Code queue is empty.
READ: === Network ===
READ: Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
READ: HTTP sessions: 1 of 8
READ: - WiFi -
READ: Network state is running
READ: WiFi module is idle
READ: Failed messages: pending 0, notready 0, noresp 0
READ: WiFi firmware version 1.21RC3(28b1)
READ: WiFi MAC address 5c:cf:7f:2b:ee:bb
READ: WiFi Vcc 3.42, reset reason Turned on by main processor
READ: WiFi flash size 4194304, free heap 18200
READ: Socket states: 0 0 0 0 0 0 0 0
READ: === Expansion ===
READ: ok[/c] -
The report says "WiFi module is idle" meaning that either it was never connected to the AP, or it was but something caused it to disconnect.
-
It was connected to the access point. And working fine.
I think it continued to be connected to the access point. Because if I try to connect, the web browser gives the message:
"unable to open the page because the server unexpectedly dropped the connection….. This sometimes happens when the server is busy..."
Whereas if I invent an IP on the same network the browser gives a message:
"unable to open the page.... because the server where the page is located isn't responding"
Also the Duet continues to show on the wifi router admin page.
So... something weird going on in the wifi stack?
-
I had erroneously loaded 1.21RC3 WifiServer….. Have now tested 1.21RC4 for a good hour and it seems to have cracked the problem.
Well done!
On the wifi router still see a "*" instead of the name of the printer, but who cares?
Really this embedded wifi has caused such grief over the years.... Yet also on home network have another ESP device - https://luftdaten.info/en/construction-manual/ - and it just seems to tick over without causing any trouble.
-
Thanks. It looks like the new SDK from Expressiv that fixed the KRACK WPA vulnerability introduced a new issue, but they seem to have resolved it in the more recent version that we use in RC4. Your other device is probably using the SDK that predates the KRACK fix.
-
ps don't forget the two links (from the documentation to the Betas on github) are broken: https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_Betas
-
ps don't forget the two links (from the documentation to the Betas on github) are broken: https://duet3d.dozuki.com/Wiki/Firmware_Overview#Section_Betas
Thanks, I've corrected that link.
-
I've gone through the Troubleshooting AJAX errors and my last signal strength says 50dbm. I can't stay connected for more than a minute before I get a request timeout. I'm using firmware, server & web control 1.21. Where should I go from here?
-
@kirk001, have you tried changing your router WiFi channel between 1, 6 and 11 ?