After update to 3.5.0-beta.4 - wifi module reported failed

OwenD

@Plohish
Also ensure that it's only trying to connect to a 2.4Ghz network.
If you have a dual band router and both networks have the same SSID it might be trying to connect to the 5.0Ghz network

Plohish

@OwenD
Until the update, I did not experience any problems with WiFi.
I have two bands on my router, but they have different SSIDs.
I didn't reset with M587, is that important?

OwenD

@Plohish
This is from the change log when wifi 2.1b2 was released.
Same would apply to 2.1b3

For WiFi enabled boards, DuetWiFiServer version 2.1beta 2 is included with these files; however you can continue using version 1.27 if you wish. In some systems, version 2.1beta2 may give a lower upload speed than 1.27, however it supports additional features such as WiFi scanning and WPA Enterprise (details to follow) and it may work better with some WiFi access points than 1.27 does. Note, if you do upgrade to 2.1beta2 then you will have to re-enter your access point details using M587.

Maybe try deleting the access points and redoing again?
You'll need to do it via YAT or similar

M552 S0
M588 S"*"
M587 S"yourSSID"

Plohish

@OwenD

i did only M587 S"your-network-ssid" P"your-network-password"
I will do it
M552 S0
M588 S"*"
M587 S"yourSSID"
if it doesn't work, I'll go back to the old version of WifiServer

OwenD

@Plohish
You will need the password in M587 of course
I omitted that

Plohish

@OwenD
Unfortunately it didn't help...
I returned to 1.27, no more problems!

Plohish

@OwenD
there is another small problem, the printer does not turn off the power at the end of printing
i read this:
The use of M1 to end a job is deprecated. The M1 command no longer runs file sleep.g, instead it runs stop.g like M0. In future we expect to change the behaviour of M1 to be in line with the NIST standard.
what should i use instead of M1 ?

OwenD

@Plohish
You should create a stop.g in the /sys directory if you don't already have one.
This will be run at the end of every print job or when M0 is called.
You used to have to call M0 implicitly, but I'm pretty sure in one of the 3.5 betas it started being run automatically.
It should contain your shutdown procedure such as turning off heaters and calling M81
Change your M1 calls to M0

Plohish

@OwenD
The stop.g file is present in my system, I entered the code into it:
M81 S1
It works, I didn't have to change M1 to M0 in the final code

droftarts

@Plohish said in After update to 3.5.0-beta.4 - wifi module reported failed:

@OwenD
Unfortunately it didn't help...
I returned to 1.27, no more problems!

The initial release of 3.5beta4 was posted with the wrong version of DuetWiFiServer firmware; it was 2.1beta3, it has now been updated to 2.1beta4. Can you try that? You will have to connect via USB and re-enter your access point SSID and password using M587.

Ian

Plohish

@droftarts
unfortunately my printer is busy for a few days now, maybe I can do it later...

boldnuts

I have also seen the same issue using the DuetWiFiServer firmware 2.1beta4 with my Duet2 Wi-Fi, with YAT connected I get SPI errors" unable to get WIFI module status" but on returning to version 1.27 it works ok.

Plohish

@droftarts
Now I think there is no need to repeat the experiment? boldnuts had the same problem with the 2.1beta4 update...

droftarts

@Plohish @boldnuts
We think that the wrong wifi firmware has been installed. Initially, the firmware for the ESP32-equipped boards (Duet 3) was called DuetWiFiServer_32S3.bin because that's how it's built, but DWC renames that to DuetWiFiServer.bin so it incorrectly gets installed on the ESP8266 module on the Duet 2 WiFi, causing the failure you see. The ESP32 firmware has been renamed to DuetWiFiModule_32S3.bin, so it will be ignored on Duet 2 WiFi now. Please download and try the DuetWiFiServer.bin in the 3.5.0-beta4 release: https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.0-beta.4

Ian

boldnuts

@droftarts that seems to have fixed this issue, thank you