I suggest adding a check box to add M501

turtlecrawler

@droftarts Ohh I am just blind, thank you

infiniteloop

I feel like having M501 to read saved parameters should just be default for anyone building a config for their own machine.

No, it shouldn’t. M501 is just a means to obscure your configuration by hiding modifications in the file ”config-override.g”. With the ability to easily edit the config.g directly, there is no need to store modifications to it in a separate file - other than for historical reasons.

droftarts

@infiniteloop said in I suggest adding a check box to add M501:

No, it shouldn’t.

I concur. I don't use config-override.g except on my delta, to save delta calibration, for exactly the reasons you state.

Ian

infiniteloop

@droftarts said in I suggest adding a check box to add M501:

except on my delta, to save delta calibration,

Agreed. That's a good argument for M501.

Phaedrux

@infiniteloop said in I suggest adding a check box to add M501:

@turtlecrawler

I feel like having M501 to read saved parameters should just be default for anyone building a config for their own machine.

No, it shouldn’t. M501 is just a means to obscure your configuration by hiding modifications in the file ”config-override.g”. With the ability to easily edit the config.g directly, there is no need to store modifications to it in a separate file - other than for historical reasons.

Like anything else it requires you to understand what it does and how to use it.

infiniteloop

@Phaedrux

it requires you to understand what it does and how to use it.

True. I fully understand the need for such a mechanism as long as the initial configuration data were burnt to an EEPROM. In ancient history, when the OS of a PC was held in ROM, this was the way to apply patches/updates. But hey, the config.g nowadays is just a simple file with read/write permissions, so I question the necessity of maintaining an obsolete level of indirection - well, apart from the use case @droftarts points out …

droftarts

@infiniteloop said in I suggest adding a check box to add M501:

apart from the use case @droftarts points out

Even that use case can just be added to config.g. If anything, I use config_override.g as a convenient way to get the current settings, and copy/paste the correct commands back to config.g. I'm trying to remember without plugging it in if I have M501 in config.g on that, even.

Ian

infiniteloop

@droftarts Thanks for supporting my reasoning. Personally, I have no problem with obscure procedures - these are an inevitable part of my daily work. But I firmly oppose the idea to confront a user with unnecessary complications.

oliof

I can see how commercial machines would like to have an immutable config.g setting sane defaults, and changes/calibration results going into a separate file. M500/M501 seems to be a decent way to do that.

But unfortunately, we don't have a sane mechanism to inhibit changes to config.g (I can come up with a number of ways in SBC mode), and even then the wholly dynamic nature of RRF makes it a moot point.

What's missing for me is a way to dump the current configuration with all tweaks into a macro file I could keep around.

OwenD

@oliof said in I suggest adding a check box to add M501:

What's missing for me is a way to dump the current configuration with all tweaks into a macro file I could keep around.

Perhaps an extension of M471 would be a good idea?
At present you can rename and move a file but it deletes the original.
Perhaps a "C" parameter to only copy the file?