New Duet WiFi user
-
Myself and one or 2 others have found that the router can be the cause of the disconnect issue Mine does it all the time if I try and use the Netgear router direct but if I use my TP-Link Travel router set as an AP then it works fine.
at least 2 other people I know have had similar experiences as well
-
@Dougal1957, I've managed to re-position the router and lifted the Duet slightly and angled the antenna section upwards. WiFi strength is now showing as -59dBm. Sitting less than 1.5 meters away from the Duet with a MacBook (typing on it now), it's showing WiFi strength as -48dBm on the same signal (2.4GHz). I'll let the Duet idle along for the day and see if it improves. Thanks to all for comments, suggestions, etc.
-
The signal strength seen by the Duet will be degraded if the Duet is mounted within a metal printer enclosure or close to a metal frame, because the metalwork may shield the wifi module and/or cause reflections that weaken the signal seen by the Duet. Whereas your MacBook has the internal antenna positioned so as to be unaffected by metalwork in the MacBook, and it may also have a larger antenna than the wifi module in the Duet.
-
Update: The WiFi module on the Duet seems more susceptible to noise and interference than most wireless devices. Case in point, two Raspberry Pi boards in the same room (further away from the access point) and working fine for months. As it turns out, my Wifi router was setup as a default for the channel and it defaulted to channel 6. I started scanning around the house and there were four additional signals on channel 6 (2.4GHz WiFi) showing up (neighbors… everyone has WiFi). I changed the configuration on my router to channel 10 and the frequent disconnects went away.
I let the Duet board idle for a simple test, it ran fine without any disconnects for about 10 hours, then the WiFi module on the Duet went out (no blue light) and the web console disconnected. I did load the firmware back to the 1.20 release level for testing however. As of now, I don't think I have a WiFi problem as all other devices (and I have a lot of them) are not having any signal or connectivity issues. The signal strength on the Duet is ranging from -58dBm to -61dBm. I'll do some additional testing over the next few days. Still, I've had the Duet WiFi module go offline during a print job, the job finished fine but the WiFi module never came back online.
Again, thanks to all for their quick responses and insight.
-
I continue to experience WiFi module disconnects. It will run for hours, do prints jobs, etc., but will still simply disconnect for no apparent reason. It happened again this morning while idle. I plugged into the USB interface and ran M122 command. The output is shown here:
m122
=== Diagnostics ===
Used output buffers: 1 of 32 (14 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
Board ID: 08DGM-9568A-F23SD-6JTDG-3SJ6K-1AR7H
Static ram used: 15448
Dynamic ram used: 99016
Recycled dynamic ram: 224
Stack ram used: 3576 current, 8440 maximum
Never used ram: 7944
Last reset 20:55:09 ago, cause: reset button or watchdog
Last software reset at 2018-01-22 21:21, reason: User, spinning module GCodes, available RAM 7944 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, 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 38.9, current 39.1, max 39.3
Supply voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-01-25 06:11:52
Cache data hit count 4294967295
Slowest main loop (seconds): 0.160391; fastest: 0.000043
=== Move ===
MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 9, completed moves: 9
Bed compensation in use: 5 point
Bed probe heights: -0.290 -0.190 -0.350 0.145 -0.058
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== 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 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 idle
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20
WiFi MAC address 60:01:94:34:3e:7a
WiFi Vcc 3.39, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 18568
Socket states: 0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)I then entered the M552 S1 command as shown:
M552 S1
Wifi module is connected to access point BSSNext, IP address 10.0.0.67
The WiFi module is going into idle mode on it's own, but it's not crashing. Is it possible the WiFi module is intermittant or the server code still has some problems?
-
Do you have logging enabled? If so, please provide the log, because network status changes will be recorded in it.
-
Thanks David, I turned on logging and reset the board, etc. It was fine all day long until around 04:12:07 this morning. The log shows the connection as lost, then times out and finally reconnects. I decided to look at the WiFi log on the MacBook and it also shows the connection being re-established at the same time. I started digging into my Comcast/Xfinity service… hard to imagine why, but they do a remotely initiated reset every morning somewhere between 3AM and 4AM!
Turns out the WiFi module on the Duet doesn't always recover from this. It did this morning and I could reconnect just by clicking on the web interface. I then issued a reset command to the modem via their web interface. Again, the Duet lost it's connection, but this time it showed as having connected but I couldn't connect via the web interface. I had to stop the network, then restart it and was able to connect again. Here's the log file data:
2018-01-25 13:30:06 Event logging started
2018-01-25 13:32:51 Event logging stopped
power up + 00:00:01 Event logging started
power up + 00:00:01 WiFi module started
power up + 00:00:09 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
power up + 00:00:13 HTTP client 10.0.0.33 login succeeded
2018-01-25 13:33:05 Date and time set at power up + 00:00:13
2018-01-26 04:12:07 WiFi reported error: Lost connection, auto reconnecting
2018-01-26 04:12:47 WiFi reported error: Timed out while trying to connect to BSSNext
2018-01-26 04:12:52 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
2018-01-26 08:27:35 HTTP client 10.0.0.33 login succeeded
2018-01-26 08:36:30 WiFi reported error: Lost connection, auto reconnecting
2018-01-26 08:37:10 WiFi reported error: Timed out while trying to connect to BSSNext
2018-01-26 08:37:14 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
2018-01-26 08:40:12 Error retrieving WiFi status message
2018-01-26 08:40:12 Wifi module is idleBSSNext, IP address 10.0.0.67
2018-01-26 08:40:15 WiFi reported error: no known networks found
2018-01-26 08:40:15 Wifi module is idle
2018-01-26 08:40:43 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
2018-01-26 08:40:48 HTTP client 10.0.0.33 login succeededNote: after the second reconnect at 08:37:14 I was unable to connect to the Duet via the web interface. I went in via the USB console and stopped/started the WiFi module and was then able to connect via the web interface. To fix things on my end, there's only a handful of options;
1- Change internet provider
2- Try manual IP config so the DHCP client isn't trying to reconnect
3- Add a separate WiFI access point
4- Turn the Duet off over night and not worry about it.Still, there seems to be an intermittent problem with the WiFI module on the Duet, as the reconnect doesn't always work. At least for now the problem is understood. I have an extra R-Pi3 kicking around... I might set it up as wireless access point and connect to it instead and do some additional testing overnight.
Again, thanks for the great support! Hope the feedback here is useful for some other users as well.
-
Thanks for the feedback. I can see what is happening. If the connection is lost, code in the SDK attempts to reconnect. That will only work if the AP is still running. If that fails, code that I wrote attempt to retry. This will only work if the WiFi signal is down for only a very short time - for example if you disable wifi on the router and then immediately re-enable it. If your router is being reset completely, the wifi will be down for too long for both reconnect attempts to succeed.
Perhaps we need an option to have the Duet keep retrying the connection at intervals until either it succeeds or a new M552 command is sent.
Meanwhile, if you have a PanelDue on your printer, you can send M552 S1 from it to reconnect, or set up a reconnect macro. If not, you could set up a macro triggered from a button connected to a spare endstop input, and send the M552 command in that macro. You could even reset the wifi module completely first by sending M552 S-1.
-
Thanks David,
I took a R-Pi3 and configured it as a wireless access point with a DHCP server and linked it to the Xfinity router via ethernet. I configured the Duet to log into this access point instead of the Xfinity router. This does resolve the WiFi module timing out and it's been running fine for a couple days now. So, at least with firmware 1.20 it's a solid connection. Not exactly an elegant workaround but it's functional.Similar to another recent post, I've also experienced some occasions when the WiFi module does not connect, either during a cold start or a reboot. It's unclear as to the cause here, but you're in a better position to investigate this. I agree that adding an option to the Duet for retries. Perhaps adding something into the config.g file that allows a time period between retries and an overall retry count. If it fails, simply post a message in the log file, i.e., number of retries failed to connect to a network.
Panel Due… it's on my list. I'll probably pick one up in the next or two. Is there a difference in the screen content when moving to a larger display (4.3, 5.0 or 7.0) or is really just a larger screen display? I'm thinking about the 5" screen. Any comments welcome.
-
The 5" screen displays a little more info than the 4.3" screen. The 7" is the same as the 5".
