I now also have a code fix for it, but I want to test it locally first.
Changes required:
In the FluidNC fork, change ProcessSettings.cpp to add a new command CO for “Config/Overwrite”, this first verifies that the Maslow is not running using_default_config and if that’s the case it then calls dump_config (command CD) to overwrite the existing config file.
In the ESP3D-WEBUI fork, change the saveMaslowYaml command to call the CO command (instead of CD) as well as do a bit of error handling.
Please note that if the ESP32 raises a ESP_RST_PANIC during calibration or any time before the user clicks ‘Save’ in the ‘Configuration’ dialog. Then the ‘maslow.yaml’ file will get overwritten with the FluidNC defaults (which we really really do not want) and you’ll be able to incinerate an egg on your Z-Steppers.
Would it be useful to have a persistent boot counter in non-volatile memory that gets incremented with each bootup of M4. This could help track whenever the M4 gets reset. EMI may cause resets this will help track.
The reason that FluidNC has the “return to defaults if crash happens” behavior is that if we don’t have that it can result in a situation where the device boots, crashes immediately due to bad .yaml file…boots again…crashes again…etc making it very difficult to fix.
I think that maybe the correct behavior is to have it behave like it does now (although maybe we want to have it use correct pins for the steppers and SD on failed boot?) and then have a really clear warning message to the user so it’s no mystery what is going on?
I 100% agree, I think this is valuable (although potentially for unrelated reasons…ie static issues)
In this scenario we’re at a transitional point between those issues.
The ESP has panicked and reset, FluidNC has found this out and reverted to a set of defaults, next comes the problem. The Maslow code we have at present inadvertantly writes those unwanted (from a M4 perspective) defaults back over whatever maslow.yaml file was present. And thereby it corrupts the maslow.yaml file for use with an M4.
So I’ve got code to stop that last step from happening, more correctly mitigate it.
Next step would be to create a new class for Maslow that derives from the FluidNC one, which will then emit a M4 friendly set of defaults.
Exactly the opposite. Changes that we identify in the MachineConfig.cpp (and .h) that are beneficial in general, we should still put into a PR and provide that back to the FluidNC team.
But we keep our derived M4MachineConfig.h (and .cpp) to ourselves.
Current declaration for MachineConfig is
class MachineConfig : public Configuration::Configurable
Ours would probably be
class M4MachineConfig : public Machine::MachineConfig
The separation of concerns via simple inheritance should make it easier to push and pull from FluidNC. (Here’s hoping anyway)
After trying a derived class I realised that the upstream FluidNC code is not well enough structured to support doing things properly (yet). And doing that is a long term process.
Instead I went for a halfway version which picks up some of the most recent changes from the latest FluidNC code. But leaves the rest as-is. This will still be a pain to merge, just not quite so bad (hopefully).
This ensures that the default config in the time of an ESP_RST_PANIC is such that it won’t result in compromises to the M4 - like blistering hot Z-Steppers.
I did note that an ESP_RST_PANIC can result in the WiFi completely dropping out now (not related to this code). So we probably want some guidance for users about that.
“If you cannot connect to your M4, and it doesn’t show up as a WiFi access point called ‘Maslow’, then it almost certainly needs a reboot. Please turn it off and on again.”