Settings bug in unreleased code

Software Maslow Firmware
1

I was just about to do a firmware release and I ran into an issue with the way settings are working. It seems like when I build the latest code from source these settings are now being reset on the machine every time it powers on overwriting the stored values.

@md8n and @dlang Do either of you know what might have changed that in the recent changes?

No rush, I’m going to bump the firmware release till next week so we have more time for testing. I think the issue is in index.html, but I’m not sure where.

$/Maslow_vertical=false
$/Maslow_calibration_grid_width_mm_X=1500.000
$/Maslow_calibration_grid_height_mm_Y=800.000
$/Maslow_calibration_grid_size=9
$/Maslow_Retract_Current_Threshold=1300
$/Maslow_trX=2958.300
$/Maslow_trY=2068.300
$/Maslow_Acceptable_Calibration_Threshold=0.450
$/Maslow_tlX=12.100
$/Maslow_tlY=2074.800
$/Maslow_trX=2958.300
$/Maslow_trY=2068.300
$/Maslow_brX=2939.700
$/Maslow_tlX=12.100
$/Maslow_tlY=2074.800
$/Maslow_trX=2958.300
$/Maslow_trY=2068.300
$/Maslow_brX=2939.700
$/Maslow_vertical=false
$/Maslow_calibration_grid_width_mm_X=1500.000
$/Maslow_calibration_grid_height_mm_Y=800.000
$/Maslow_calibration_grid_size=9
$/Maslow_Retract_Current_Threshold=1300
$/Maslow_trX=2958.300
$/Maslow_trY=2068.300
$/Maslow_Acceptable_Calibration_Threshold=0.450
2

Not sure if it’s related, but I was updating my yaml file and noticed the old settings kept persisting unless I power cycled the machine. Also having an issue where post calibration I get an error on the FLuidNC page.

1 Like
3

This issue is only there if you re-compile your own index.html.gz file from the source code so probably not related, but if you want to start a thread for those things I would love to learn more!

4

Okay cool. I was collecting more info then I can start a thread.

1 Like
5

There’s nothing specific that I changed recently that would do this. However, this is an area where I have been ‘moving things around’ so possibly some kind of regression.

1 Like
6

There are two calls to settings.js saveMaslowYaml

  • calculatesCalibrationStuff.js findMaxFitness and specifically the iterate function within that
    • which in turned is called from handleCalibrationData in grbl.js
  • maslow.js saveConfigValues
    • this is only invoked by the onclick handler for the ‘save’ button in tablettab.html

There’s nothing else in the front end that send the $CO message to the back end to save the config.

So, looking at the back end code …
ProcessSettings.cpp overwrite_config has only a single call to it - the handler for CO.
In turn it calls dump_config.

However, dump_config can also be called in response to the CD message. So heading back to the front end … and thankfully no invocations of that.

Exploring things from the perspective of the maslow.yaml string in the backend code base. That gets defined as config_filename and used throughout the codebase that way. And I can’t see any place where it maybe used incorrectly either.

My next recommendation is to make sure that your local ‘Maslow-Main’ branches for both projects are fully up to date. And then merged into whatever current branches you’re working on.

And then try and diagnose the problem again …

And I would recommend that we get rid of the $CD handler.

7

Bar wrote:

I was just about to do a firmware release and I ran into an issue with the way settings are working. It seems like when I build the latest code from source these settings are now being reset on the machine every time it powers on overwriting the stored values.

@md8n and @dlang Do either of you know what might have changed that in the recent changes?

my guess would be that the routine that is trying to detect a corrupted config
is triggering, replacing the real config with a default one.

David Lang

1 Like
8

That was my first thought as well. But I couldn’t clearly see the process.

1 Like
9

The check is done in src/Machine/MachineConfig.cpp

 bool MachineConfig::load() {
     bool configOkay;

     // If the system crashes we skip the config file and use the default
     // builtin config.  This helps prevent reset loops on bad config files.
     esp_reset_reason_t reason = esp_reset_reason();

     // TEST: Uncomment the following to mock an ESP panic reset
     //reason = ESP_RST_PANIC;
     if (reason == ESP_RST_PANIC) {
         log_error("Skipping configuration file due to panic");
         configOkay = false;
     } else {
         configOkay = load_file(config_filename->get());
     }

     if (!configOkay) {
         log_info("Using default configuration");
         configOkay = load_yaml(new StringRange(defaultConfig.c_str()));
         Maslow.using_default_config = true;
     }
     //configOkay = load(config_filename->get());
     return configOkay;
 }

so this sounds as if it’s failing to read the config

David Lang

1 Like
10

If this is the piece of code involved, and it is a good explanation for what is experienced,

Then by definition

The ‘stored values’ are not overwritten in the maslow.yaml file. But any values stored in memory may be overwritten with the defaults, as we now have them for an M4 machine.

So then the actual question is, what is causing the ESP panic resets?

1 Like
11

Well I jumped into this and I can’t make it happen again. I don’t know what I was seeing on Friday, but I think that it was me not understanding what was going on, not a real bug :slightly_frowning_face: