3.5.0b1+ Wifi error - SPI timeout

OwenD

Some more info this morning.
Normally I discover this problem either when I walk out to the garage to get a beer and see the PanelDue flashing ans SPI error, or I can't connect to DWC.
This morning I opened my phone (to a previously open tab) and DWC was frozen.
When I tried refreshing, it just said connecting and that the drive wasn't mounted.

Suspecting an SD card issue, I checked the PanelDue wasn't displaying any errors.
Sending M20 resulted in a normal listing, so the SD card has to be mounted.
Maybe this is a red herring?
DWC from my laptop just doesn't connect. "Can't find host"

M20
Begin file list
random-moves-test.g
Outer_Trays_0.2mm_PLA.gcode
freak_Pin_0.14mm_PA-CF.gcode
Inner_Trays_0.2mm_PLA.gcode
SKEW_100mm_0.2mm_PLA.gcode
cube_0.2mm_PLA.gcode
Freak body large skirt_0.2mm_PA-CF.gcode
YACS_0.2mm_PLA.gcode
calibration_0.2mm_PLA.gcode
monitor-pad-right_0.2mm_PLA.gcode
calibration piece _0.2mm_PLA.gcode
Box1_0.2mm_PLA.gcode
EspChunky_0.2mm_PA-CF.gcode
pump-filter_0.2mm_PA-CF.gcode
End file list

If I send M111 P14 S1, I immediately get a barrage of busy responses in YAT .

M111 P14 S1
Debugging enabled for modules: WiFi(14 - 0xffffffff)
Debugging disabled for modules: Platform(0) Network(1) Webserver(2) Gcodes(3) Move(4) Heat(5) Dda(6) unused1(7) unused2(8) PrintMonitor(9) Storage(10) PortControl(11) DuetExpansion(12) FilamentSensors(13) Display(15) SbcInterface(16) Can(17)
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
ResponseBusy
M111 S0
ok

If I try to do a network scan I get this

M587.1
Error: M587.1: failed to start scan: another SPI transfer is pending

Phaedrux

Can you try flashing back to 1.27 and seeing if this still happens? If so, I think it may be the module.

OwenD

@Phaedrux
Can't rule out a hardware issue I guess.
Have reverted back to 1.27 and will monitor.
I did an M122 before and after the change.
This is the network section. Note the not ready number and lack of IP address.

=== Network ===
Slowest loop: 29273.09ms; fastest: 100.43ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 0 of 8
= WiFi =
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 42217, noresp 1
Failed to get WiFi status
Socket states: 6 0 0 0 0 0 0 0

After reverting and restart.

= WiFi =
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 2
WiFi firmware version 1.27
WiFi MAC address bc:dd:c2:89:a0:bb
WiFi Vcc 3.38, reset reason Power up
WiFi flash size 4194304, free heap 24848
WiFi IP address 192.168.1.163
WiFi signal strength -35dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

StreetFurnitureAustralia

Hi, I have also been getting instability issue with the wifi since going to 3.5.0b1.

The duet will drop off from the network midprint or even not connect at all unless i power it down and then back up.

OwenD

@StreetFurnitureAustralia
Are you getting the same SPI timeout messages noted in this thread?
Can you connect via USB and grab the same reports as above?
My error is quite random and very specific.
It has not reappeared since rolling the wifi back to 1.27 but it only happened occasionally so I'm not ready to say it's definitely firmware yet.

StreetFurnitureAustralia

@OwenD I can't replicate it but when it happens again then I can try and get it.

StreetFurnitureAustralia

@OwenD I'm not in the office but a colleague sent me thisreceived_6062637163802703.mp4

As you can see its being spammed

OwenD

@StreetFurnitureAustralia
That's the same behaviour
Can you try to get the reports as shown above and then roll the wifi back to 1.2.7
I haven't had a repeat since rolling back but it's infrequent for me, so I can't be sure it's the firmware

StreetFurnitureAustralia

@OwenD I will try just never don't this before, is there a way to log this via the duet webinterface and not need to connect a laptop directly?

OwenD

@StreetFurnitureAustralia
No, if the wifi module can't connect then the only way to get the info is via a terminal like YAT using the usb connection
If you roll back to 1.27 and have no further issues it's at least showing the same results as I'm getting
Maybe it's an Aussie only issue?
Wifi channel or something related?

StreetFurnitureAustralia

@OwenD could make sense, This is at my work and we use Unifi wifi gear. How about yourself?

Aitor

Good morning @dc42 ,

I would like to share my case in this post, I don't know if it will help.

After a while (X), usually the next day, my printer loses connection and I have to reset it to get a new IP address. In addition, it often changes IP addresses, and I have even been given IP addresses that have already been assigned to other Duets.

The commands I used to use to establish a connection no longer work:

M552 S-1
G4 S1
M552 S0
G4 S1
M552 S1

To solve this problem, I have had to use the following commands:

M552 S-1
G4 S1
M400
M552 S0
G4 S1
M400
M552 S1

If I don't perform these steps, sometimes I can't connect the printer. I suppose that these commands cannot be launched during a print to switch from M552 S1 to M552 S2 (although I haven't tried it).

Finally, I would like to share the results of M122 and the object model and M540 command, as I think this may be where one of the problems lies:

In M122, the MAC address is visible.
In the object model and the M540 command, the MAC address is "00:00:00:00:00:00".

6/4/2023, 12:19:43	M540
MAC: 00:00:00:00:00:00
6/4/2023, 12:04:07	M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5beta2+ (2023-02-10 11:58:19) running on Duet WiFi 1.02 or later

=== Network ===
Slowest loop: 6.76ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 2.1beta3
WiFi MAC address e8:68:e7:79:5f:a3
WiFi Vcc 3.39, reset reason Turned on by main processor
WiFi flash size 2097152, free heap 43068
WiFi IP address 192.168.1.18
WiFi signal strength -54dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

StreetFurnitureAustralia

@OwenD I couldn't get the info due to time restraints at work but I have rolled it back.

StreetFurnitureAustralia

@OwenD @dc42 reverting back to 1.27 has made the SPI issue disappear for me.

OwenD

@StreetFurnitureAustralia
I also did not get any re-occurences with WiFi 1.27
I have been running RRF3.5b4 and WifFi version 2.1b4 for several days now with no errors.
May be too early to tell but it may be fixed.

StreetFurnitureAustralia

@OwenD I can't see beta 4 only beta 3.

OwenD

@StreetFurnitureAustralia
Typo on my part.
RRF is b3

StreetFurnitureAustralia

@OwenD ok cheers will give it a try

StreetFurnitureAustralia

This post is deleted!

StreetFurnitureAustralia

@OwenD @dc42 I am still getting the SPI issue on the new firmware and I seem to be able to recreate the issue by going into the Unifi web UI and going to the duet and clicking reconnect that seems to put it into that error state