Wifi/Web Console issues
-
Does it make any difference using
M552 S1 P"Spiffy"
if you have a look at the markdown page, especially the code block, you'll be able to make the output a lot easier to read
https://commonmark.org/help/ -
From the console can you please send the following:
M552 S0 M588 S"*" M587 s"Spiffy" p"Password1" M552 S1 M122
This will take the wifi module to idle, clear all saved SSIDs, re-add your SSID, and re-enable the module and hopefully connect. Then the diagnostic should show the connection stats.
How far away is the access point from the printer?
Do your other devices get a strong signal in that area?
Is the access point 2.4Ghz? 5Ghz won't work. -
m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SN-6J9F4-3SD6R-TUZHF
Used output buffers: 1 of 24 (1 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93244 of which 0 recycled
Exception stack ram used: 304
Never used ram: 11844
Tasks: NETWORK(ready,1244) HEAT(blocked,1236) MAIN(running,4468) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:12:58 ago, cause: power up
Last software reset at 2019-09-02 22:49, reason: User, spinning module GCodes, available RAM 11844 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04433000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 32.6, current 35.4, max 35.5
Supply voltage: min 1.5, current 1.7, max 1.7, under voltage events: 0, over voltage events: 0, power good: no
Driver 0: ok, SG min/max not available
Driver 1: ok, SG min/max not available
Driver 2: ok, SG min/max not available
Driver 3: ok, SG min/max not available
Driver 4: ok, SG min/max not available
Date/time: 1970-01-01 00:00:00
Cache data hit count 2516579683
Slowest loop: 99.70ms; fastest: 0.06ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== 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 ===
Slowest loop: 15.36ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 0 of 8- WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 84:f3:eb:41:4e:f8
WiFi Vcc 3.39, reset reason Exception
WiFi flash size 4194304, free heap 23696
WiFi IP address 192.168.0.19
WiFi signal strength -60dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
ok
So now my problem is still powering down and then moving the board to my printer. wifi remains disabled
- WiFi -
-
@shaun said in Wifi/Web Console issues:
WiFi signal strength -60dBm
I suspect this is the problem. -60 is already on the low end. When you move to the printer location I suspect the signal is too weak for it to connect.
You may find this helpful: https://duet3d.dozuki.com/Wiki/WiFi_disconnections_and_AJAX_timeout_errors
-
Thanks but i think you misunderstood. the wifi is disabled after power cycle.
-
@phaedrux said in Wifi/Web Console issues:
When it is powered by the PSU, can you connect via USB as well and send M122
Can you check this?
-
I don't think it's disabled, I think it's trying to find an SSID and cannot, so it stops.
It's working and connecting reliably when you're powered via USB, correct?
-
If you have M552 S1 in config.g and you do not also have another M552 command in there that cancels it, then when it has finished running config.g is will do a site scan and connect to the strongest network that you have told it about via M587. So:
-
Make sure there is exactly one M552 command in config.g and it has parameter S1.
-
Retype that line in case it contains hidden characters.
-
When you start the Duet, look out for the blue LED on the WiFi module flashing.
If it tries to connect but fails, the state falls back to Idle, not Disabled. State Disabled is what you get if you never used M552 to enable the WiFi module, or if you send M552 S-1.
-
-
@phaedrux At my desk, i power cycle the board and the wifi doesnt light up. check the config and wifi disabled.
there in lies my problem.
-
Thanks for all the help, ive managed to resolve this issue myself. Nothing like recompiling the Config.g from scratch.
-
I assume you mean run through the configurator again to get a new set of configs?
It's not so complicated once you're connected. The config.g is just a plain text file with gcode commands. You can edit it right from the web interface.
-
Something i noticed which may or may not have a bearing on things, I thought that in the config.g that the network section was always generally at the start of the file, in this gents case it was well down his list.
So does the duet execute the g code in the order in which its in the file or is it irrelevant and you can put the g code in any order at all ?
-
Everything is executed line by line, be it a config file or a sliced file to print.
The order is only important for a few commands, more so in RRF3 as you have to define pins and stuff before using commands that use them etc. The wiki has some notes on the commands where the order do matter.
(But as evident in another recent thread having the network config at the top may allow you to have working network even if there is a problem further down in the config file?) -
@calvinx said in Wifi/Web Console issues:
Something i noticed which may or may not have a bearing on things, I thought that in the config.g that the network section was always generally at the start of the file, in this gents case it was well down his list.
So does the duet execute the g code in the order in which its in the file or is it irrelevant and you can put the g code in any order at all ?
Good point buddy, thought this would be something support would have noticed had they looked. I dropped the wifi into the general settings second line and all working fine. I had to emulate the code execution before it highlighted that due to errors further up it never got to executing the wifi config down the bottom.
Only spent hours and hours redoing everything. The new configuration wizard places the network settings right at the bottom. Something they might want to add further to the start of the config.g
; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"CR10" ; set printer name
M552 S1 ; enable network
M911 S10 R11 P'M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000' ; set voltage thresholds and actions to run on power loss -
@shaun said in Wifi/Web Console issues:
M911 S10 R11 P'M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000' ; set voltage thresholds and actions to run on power loss
replace
'
with"
-
@bearer said in Wifi/Web Console issues:
@shaun said in Wifi/Web Console issues:
M911 S10 R11 P'M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000' ; set voltage thresholds and actions to run on power loss
replace
'
with"
Thanks Bearer, done.
@Admins the configuration wizard sets this so you might want to double check your code.
M911 S10 R11 P'M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000' ; set voltage thresholds and actions to run on power loss
'M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000' as Bearer pointed out should look like "M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000"
-
Seems it was flagged as a bug about a week ago, there is also a more recent issue specifically detailing this issue so it'll probably be updated as soon as the guy who maintains the configuration tool sees it.
-
Good catch guys. Those wrong quotes were stopping the execution of the rest of the config.