Duet2 wifi stuck repeating Wifi Error.
-
@zBeeble I was trying to type m112, but it seemed to glitch at typing the 'm' ... now I was set for 57600 (since I didn't know what to choose)...?
-
@zBeeble If you typed M112 then that is "emergency stop" (see: https://docs.duet3d.com/User_manual/Reference/Gcodes#m112-emergency-stop), so your printer did what you told it to do!
I'd guess you wanted M122 not M112. If you are using a direct USB connection between your computer and the board then the baud rate is in effect ignored.
-
@zBeeble see our recommendations for serial terminals here: https://docs.duet3d.com/en/How_to_guides/Getting_connected/Getting_connected_to_your_Duet#h-3-connect-to-duet
Ian
-
@gloomyandy said in Duet2 wifi stuck repeating Wifi Error.:
@zBeeble If you typed M112 then that is "emergency stop" (see: https://docs.duet3d.com/User_manual/Reference/Gcodes#m112-emergency-stop), so your printer did what you told it to do!
I'd guess you wanted M122 not M112. If you are using a direct USB connection between your computer and the board then the baud rate is in effect ignored.
I did notice it showed up as umodem rather than one of the userials I'm used to:
umodem0 on uhub3 umodem0: <Duet3D Duet, class 2/0, rev 2.00/1.00, addr 2> on usbus3 umodem0: data interface 1, has CM over data, has no break```
-
@rechrtb said in Duet2 wifi stuck repeating Wifi Error.:
@zBeeble The instructions for updating WiFi firmware only is at: https://docs.duet3d.com/User_manual/RepRapFirmware/Updating_firmware#updating-wifi-firmware
You might want to clarify there a bit. There's nothing wrong with that recomendation, but you should go a step further. For instance, minicom does everything required and runs in a terminal. tmux or screen can manage long running terminals when the other computer might reboot or suffer some other calamity (like being a laptop).
If you add minicom, you might note that from stock config, turning on 'add carriage return' and turning on 'line wrap' and turning on 'local echo' are really good settings.
-
OK. The crazy that needed to finish is done. The new wifi binary is loaded and I have a minicom terminal in a tmux that should live just fine when the laptop leaves for the nation's capital at the end of the week.
I think a short hiccup with the wifi occurred. I see some disconnects in the log... but this was before the log-log.
I'm kinda relying on you guys that this setup is correct for logging. I see a print stopping, but not starting on the console and I don't see, say, if I run m111 on the web console. I do see a result to running an m command (like m111) on the serial console, tho... so... fingers crossed.
-
Hey... is it supposed to say this:
m111 Debugging enabled for modules: Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unused(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) WiFi(14) Display(15) SbcInterface(16) CAN(17) Expansion(18)
... debugging not on wifi?
-
The bottom bit of m122 is as follows (and it's a bit of pain that this code changes in my head to 112)
=== WiFi === Interface state: active Module is connected to access point Failed messages: pending 0, notrdy 0, noresp 0 Firmware version 2.1.0d MAC address 60:01:94:73:54:4c Module reset reason: Power up, Vcc 3.44, flash size 4194304, free heap 42540 WiFi IP address 192.168.221.183 Signal strength -44dBm, channel 6, mode 802.11n, reconnections 0 Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0 ok RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.1 Executing config.g... HTTP is enabled on port 80 FTP is disabled TELNET is disabled Done!
-
M115 FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.5.1 ELECTRONICS: Duet 3 Mini5plus WiFi FIRMWARE_DATE: 2024-04-19 14:41:25 M111 Debugging enabled for modules: Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Kinematics(6) InputShaping(7) unused(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) WiFi(14) Display(15) SbcInterface(16) CAN(17) Expansion(18)
WiFi is module 14, Network is module 1 (at least for me on a Duet 3 Mini 5+) so send
M111 P14 S1
andM111 P1 S1
at startup to enable logging of those, with your serial terminal connected.@zBeeble said in Duet2 wifi stuck repeating Wifi Error.:
If you add minicom, you might note that from stock config, turning on 'add carriage return' and turning on 'line wrap' and turning on 'local echo' are really good settings.
We do! See https://docs.duet3d.com/en/How_to_guides/Getting_connected/Getting_connected_to_your_Duet#minicom
Press CTRL-A then W for linewrap, CTRL-A then U for CR at end of line, and CTRL-A then E for local echo. CTRL-A then X quits Minicom, releasing the port.
Ian
-
@droftarts said in Duet2 wifi stuck repeating Wifi Error.:
WiFi is module 14, Network is module 1 (at least for me on a Duet 3 Mini 5+) so send
M111 P14 S1
andM111 P1 S1
at startup to enable logging of those, with your serial terminal connected.OK. That works, but I don't see leaving network on --- it's chatty even when the printer is not doing anything. That's just a disk filling service.
-
So... I'm preparing to leave for BSDCan. Printer has been idle for about 24h. I was in the area and saw this:
https://nextcloud.towernet.ca/s/FNtRo4MyJHiG7PR
So then I checked the console...
WiFi: I (142798071) wifi:bcn_timout,ap_probe_send_start WiFi: I (142818052) wifi:state: 5 -> 0 (6c0) ESP reported status change Error: WiFi module reported: Lost connection, auto reconnecting ESP reported status change WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/SocketServer.cpp(179): wifi evt: WIFI_EVENT id: 5 ESP reported status change WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/SocketServer.cpp(199): disconnect reason: 6 WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/SocketServer.cpp(469): Lost connection to AP WiFi: I (142820117) wifi:state: 0 -> 2 (b0) WiFi: I (142820123) wifi:state: 2 -> 3 (0) WiFi: I (142820130) wifi:state: 3 -> 5 (10) WiFi: I (142820174) wifi:connected with ac.DaveG.ca, aid = 1, channel 6, HT20, bssid = b4:fb:e4:d7:be:cc WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/SocketServer.cpp(179): wifi evt: WIFI_EVENT id: 4 ESP reported status change Error: WiFi module reported: Auto reconnect succeeded ESP reported status change WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/SocketServer.cpp(179): wifi evt: IP_EVENT id: 0
followed by...
WiFi: I (190597586) wifi:bcn_timout,ap_probe_send_start
Now... this wasn't a repeating error, but I'm reporting it anyways.
-
@zBeeble Seems like the disconnect was detected at the lower levels of the ESP WiFi stack. The upper layers did what it's supposed to and attempted a reconnect. I don't think this was what causes the repeated SPI timeout error - but noted nontheless.
-
Would you guys expected this debug wifi to be significantly slower?
-
@zBeeble You mean in terms of like upload/download speed? Debug builds would be 'unoptimized' so yes.
Also, by the way, did the repeated "SPI timeout" issue not appear till now? -
@rechrtb said in Duet2 wifi stuck repeating Wifi Error.:
@zBeeble You mean in terms of like upload/download speed? Debug builds would be 'unoptimized' so yes.
Also, by the way, did the repeated "SPI timeout" issue not appear till now?I didn't notice it until now, but I can't answer with certainty.
-
OK. So ... printers been idle for a week or two --- serial console connected to system that stays online. Nothing to note.
However, was just printing something and the web UI had a few seconds where it was complaining no connection. This is certainly something I noticed before the larger problems.
No activity on the serial console, tho. Should I be entering something to turn that up?
-
@zBeeble Nothing beyond turning on the debug messages for network and WiFi. If I'm correct, you turned off the network debug messages though since it was too noisy? Also, please make sure it's logging to file so we don't miss anything.
-
@rechrtb said in Duet2 wifi stuck repeating Wifi Error.:
@zBeeble Nothing beyond turning on the debug messages for network and WiFi. If I'm correct, you turned off the network debug messages though since it was too noisy? Also, please make sure it's logging to file so we don't miss anything.
Yeah... the networking was generating a line every so often ... printer on or not.
But the machine is connected to the home server ... which is always on. I'm using minicom ... which is set to log all traffic
-
I generally have at least 2 computers (so I expect that to be 4 connections from time-to-time)... go this just now:
WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns WiFi: /home/renz/Projects/Duet3D/WiFiSocketServerRTOS/src/Connection.cpp(578): refused conn on port 80 already 4 conns
... but can have as many as 3 or 4. Is this number tunable?
This doesn't seem to be my problem, tho... as it should recover.
-
@zBeeble From the https://docs.duet3d.com/en/User_manual/Troubleshooting/WiFi_troubleshooting page, two things that might be relevant:
-
In Duet Web Control, in the Settings > Machine specific > Communication section, check that "Maximum number of AJAX retries" is at least 3.
-
Is the connection stable when the printer is idle, but unreliable when printing? If so then there may be too few CPU cycles to service the network interface, because of an excessive step pulse rate.
- Check the M122 report after a disconnection during a print, or after completing the print, and look at the number of 'hiccups' ('MaxReps' in old firmware versions) figure in the 'DDARing' or 'Move' section of the diagnostics.
- This value should be kept below about 50. If it is higher, reduce either microstepping (M350) or maximum speed (M203).
- Please note, hiccups and MaxReps is reset when you run M122 so only the value the first time you run M122 after a disconnection or completion of a print is significant.
Edit: Sorry, the above is old info, and MaxReps isn't reported in the current firmware M122 report. I've asked @dc42 how this information is reported now.
Edit: Updated the above with info from dc42.Ian
-