Configuration is invalid. Check boot messages for ERR's. #15
Comments
|
Fixes to example YAML file "3axis_v4.yaml". |
|
We are still making subtle changes to the schema. Some of the examples are probably broken. We are also trying to improve the feedback on yaml errors. I will try to load and fix your file soon. |
|
I tried loading it and had similar issues. If you send $CD to show the loaded config, it appears to have loaded everything. I am not quite sure what it is unhappy about. Can you tell me what version (wifi,wifibt, bt, noradio) you loaded? I have a new version I am working on. It appears to load fine in that. Not sure why. I might be able to send you a compiled binary by the end of the day. The new version was only designed to allow more flexibility with the SD card and SPI bus. |
I have tested on Wifi and Wifibt with similar results. Strangely exporting the default Test Drive ($CD=test.yaml) and then setting the config ($Config/Filename=test.yaml) also throws the same error about the configuration being bad. |
|
Right, I don't know what the problem is. Typically saving like that is a good thing because you see all the default values for later reference. Search the wiki for Discord. You can get live help there, but we are working on it already. |
|
Tested the new binary. It is working, but I did find perhaps what part of the problem was. This doesn't work: 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 Wi-Fi Network
wifi_ap:
ssid: FluidNCBut this does: 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 Wi-Fi Network
wifi_ap:
ssid: FluidNC
The difference is purely that there is an additional line at the end. This is the error:
I have also found that when a Wi-Fi connection is successful, but the configuration is invalid, the device will reset to default AP settings as soon as a connection is attempted. So it will successfully connect to my STA Wi-Fi, then as soon as I open the WebUI, it resets the device in Test Drive mode. |
|
Glad to hear you are having more success. Thanks for the feedback.
I am currently working on making the config file creation less frustrating with better information. More warn and ignore and less fail and fall back to the default. |
|
That would be ideal. I am working on something that I believe will be a huge help as well. This is a JSON Schema that I have created for the YAML files. https://gist.github.com/ajquick/d6d3b67b5b8aede986e500d3be40b5ee Basically, JSON and YAML are very similar. JSON has a very widely adopted validation schema already where YAML pretty much has none. The conversion back and forth from YAML <-> JSON <-> YAML is fairly straight forward. What I envision by creating this:
JSON Schema libraries exist widely across many different languages, so hopefully many useful things could be created from it. |
|
Thanks, We have talked about making an on line tool that does exactly what you are talking about. We will eventually have a serial upload protocol for the local file system. That will help get a stable config before the Wifi is established. Validate, upload, monitor in one place would be great. You should join us on Discord. |
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:
Here is what happens:
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.
We then get a correct attempt at connection, followed by a failure and a fall back to the AP in test drive mode.
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.
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:
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:
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:
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.
The text was updated successfully, but these errors were encountered: