Version 3.1.3 Release
I am testing the latest release to see how it works compared to Grbl_Esp32. I have written a YAML configuration based off of the examples. No matter what I do, the configurations are not valid, but it does not show me any ERR messages to determine what they are.
I have reduced the YAML down to the most basic settings to see if I would be able to determine where the problem is. I find that it fails even with just Wi-Fi settings.
Example YAML:
name: Wi-Fi Test
board: Wi-Fi Test
comms:
telnet_enable: true
telnet_port: 23
http_enable: true
http_port: 80
hostname: fluidnc
wifi_sta:
ssid: My Wifi Network
Here is what happens:
[MSG:INFO: STA SSID FluidNC DHCP]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: No SSID]
[MSG:INFO: WiFi off]
As you can see it tries to connect to a Wi-Fi STA called "FluidNC", not my specified Wi-Fi network.
I realize that wifi_ap may be a required key, so I add that back in and update the YAML.
name: Wi-Fi Test
board: Wi-Fi Test
comms:
telnet_enable: true
telnet_port: 23
http_enable: true
http_port: 80
hostname: fluidnc
wifi_ap:
ssid: FluidNC
wifi_sta:
ssid: My Wifi Network
We then get a correct attempt at connection, followed by a failure and a fall back to the AP in test drive mode.
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8
[MSG:INFO: STA SSID My Wifi Network DHCP]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 192.168.0.XX]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: SSDP Started]
[MSG:INFO: HTTP Started]
[MSG:INFO: Telnet Started on port 23]
Grbl 3.1 [FluidNC v3.1.3 '$' for help]
[MSG:INFO: Configuration is invalid. Check boot messages for ERR's.]
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400e5443 PS : 0x00060630 A0 : 0x800e5ebd A1 : 0x3ffd1280
A2 : 0x00000000 A3 : 0x3ffc5920 A4 : 0x3ffd12f0 A5 : 0x3ffccc74
A6 : 0x00000003 A7 : 0x00000000 A8 : 0x3f800000 A9 : 0x3ffd1260
A10 : 0x3ffd12f0 A11 : 0x3f409a1e A12 : 0x00000000 A13 : 0x00000000
A14 : 0x3ffe7194 A15 : 0x00000000 SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000010 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xfffffffe
ELF file SHA256: 0000000000000000
Backtrace: 0x400e5443:0x3ffd1280 0x400e5eba:0x3ffd12c0 0x400e6bff:0x3ffd1320 0x400e52e1:0x3ffd1360 0x400dbde2:0x3ffd1380 0x40108b38:0x3ffd13d0 0x40092d16:0x3ffd13f0
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8
[MSG:INFO: Machine Default (Test Drive)]
[MSG:INFO: Board None]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19 CS:gpio.5]
[MSG:INFO: Stepping:RMT Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (-200.000,0.000)]
[MSG:INFO: Axis Y (-200.000,0.000)]
[MSG:INFO: Axis Z (-200.000,0.000)]
[MSG:INFO: No spindle]
[MSG:INFO: Using spindle NoSpindle]
[MSG:INFO: AP SSID FluidNC IP 10.0.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP Started]
[MSG:INFO: Telnet Started on port 23]
Grbl 3.1 [FluidNC v3.1.3 '$' for help]
As you can see it connects to the Wi-Fi network specified in the YAML file. Then it determines that something is wrong with the configuration, so it decides to disconnect the Wi-Fi and broadcast the access point. This does not happen every time, sometimes it stays connected to the Wi-Fi in STA mode.
A problem arises when trying to adjust the settings after a configuration failure.
FluidNC commands and setting use a $ format. They can only be used in idle mode.
When the configuration fails, it produces the following error: 152: Configuration is invalid. Check boot messages for ERR's.
However, some things need to be changeable during a 152 error, but trying to make changes causes the following error: 8: Command requires idle state.
Examples of settings that may need to be changeable during a 152 error:
- $Sta/Password
- $Config/Filename
There may be others. The only way to recover from this problem was to use a $NXV and erase the configuration in whole, then start over by going into AP (test drive) mode and then setting the Wi-Fi password and updating the configuration file and trying again.
Trying to clear the alarm using $X does nothing. It just repeats the 152 error.
For full information the YAML I am trying to use is this:
name: Test
board: Test
stepping:
idle_ms: 250
engine: I2S_STREAM
axes:
shared_stepper_disable: gpio.13:low
x:
steps_per_mm: 800
max_rate: 2000
acceleration: 25
motor0:
limit_pos: gpio.18
stepstick:
step: i2so.13
direction: i2so.12
y:
steps_per_mm: 800
max_rate: 2000
acceleration: 25
motor0:
limit_pos: gpio.23
stepstick:
step: i2so.10
direction: i2so.5
z:
steps_per_mm: 800
max_rate: 2000
acceleration: 25
motor0:
limit_pos: gpio.19
stepstick:
step: i2so.4
direction: i2so.3
a:
steps_per_mm: 800
max_rate: 2000
acceleration: 25
motor0:
limit_pos: gpio.22
stepstick:
step: i2so.2
direction: i2so.1
i2so:
bck: gpio.2
data: gpio.15
ws: gpio.14
coolant:
flood: i2so.11
mist: i2so.15
comms:
telnet_enable: true
telnet_port: 23
http_enable: true
http_port: 80
hostname: fluidnc
wifi_sta:
ssid: My Wifi Network
wifi_ap:
ssid: FluidNC
verbose_errors: true
NoSpindle:
I should mention that one of the example config files does not have the correct form. I had originally based my configuration on this file: https://github.com/bdring/FluidNC/blob/main/example_configs/3axis_v4.yaml
It appears to be based on an older schema.
Finally, this is just my opinion after struggling for several hours testing configurations:
Wi-Fi / AP / Bluetooth settings should go back to being configured in the memory variables. It is counter productive to have Wi-Fi password stored exclusively in the memory while all other settings are stored in the YAML. What I would like to see is a hierarchy such as this:
- Wi-Fi settings, mode, password.. etc should be configured in memory using the previous Grbl_Esp32 style variables.
- Wi-Fi, AP.. etc. can be superseded by YAML configuration.
- If YAML is undefined. Settings in memory should be used (even in Test Mode).
- If YAML STA mode fails, should fallback to YAML AP (if defined), then the memory variables.
My reasoning for this, other than the headache of dealing with the ESP32 connecting to STA then dropping back to AP mode during a failed configuration, is that I envision devices being used in environments where a Wi-Fi (or Ethernet) connection is required and AP mode would be unwanted due to security concerns. Yes I realize the access point can have a really complex password, but I imagine some do not want a forced fallback to an AP. Can access point fallback be an option, not something that happens by default?
Would it be possible for YAML files to write to memory (such as a Wi-Fi password) then erase the password from the YAML and save the updated file to the SPIFFs filesystem?
Example: If Wi-Fi password is found in YAML, copy to memory variable, then overwrite the YAML using $CD=(current config filename), or some other method to remove the line and overwrite the file.