I suggest adding a check box to add M501
-
I feel like having M501 to read saved parameters should just be default for anyone building a config for their own machine. I have been running klipper for a few years now, and trying Duet RRF on my newest build. So looking at all of this with a fresh set of eyes.
Adding a checkbox in the config to add this option with the text "Include M501 to enable reading of stored parameters" would be a nice addition to the config tool.
-
@turtlecrawler It's there already:
"Read config-override.g file at end of startup process (provides similar functionality to the EEPROM option in Marlin)"
Ian
-
@droftarts Ohh I am just blind, thank you
-
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.
-
@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
-
@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.
-
@infiniteloop said in I suggest adding a check box to add M501:
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.
-
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 …
-
@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
-
@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.
-
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.
-
@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?
