M500 wipes config-override.g while saving settings
-
It's very useful for the system to have the ability to write values to somewhere. Measuring offsets and things like that to use in automation macros will become very helpful when conditional gcode becomes available.
While it's true config-override can cause some headaches it has its place.
-
My following assumption that the firmware only ever writes complete files, not ever edits in-place, could be wrong. BUT, if it's not, then I assert the following.
I think we're asking too much of the firmware to do in-place editing of text files though. It may sound simple, but it's actually quite a bit more effort than it is to just write a complete file. You have to read in the file, store it's contents in a structure that can be manipulated, like an associative array, then insert new or edit existing values, and then output it out in the same order it was ingested. That "same order" part is actually another expensive operation. You're effectively implementing a very simple on-disk database, which is not trivial.
Aside from that, and I KNOW this is not likely, but if you have concurrent users making changes through functions that generate config, now you have to worry about not overwriting each other or corrupting the file if the changes happen at the same time. That requirement literally puts in-place editing out of the question.
So, complete file generation totally makes sense.
-
@gnydick Are you sure you wanted to address me with that reply? Because I already said it does only (over)write complete files and does no in-place editing.
-
It does add simulation results data to the tail of gcode files. Main issue would be the indefinate line length and as far as I'm aware the user isn't limited to a set precision for decimals.
-
Come to think of it the merge back feature could possibly be a feature request for DWC.
That said, never had a problem with config-override.
-
@wilriker not necessarily.
-
@wilriker For sure you can have anything you like in config.override but why have 2 configuration files? A case in point..... It sometimes happens that the auto tune is less than perfect and users are encouraged to increase or decrease the dead time. If you do that to the values that are in config.g the changes won't stick because they will be overridden by what's in config override. So you have to edit what's in config override. Oh wait - config override has a great big warning - do not edit. No wonder new users get confused.
-
I Have a config-override file BUT I only ever use it to make copy and paste commands into Config.g I DO NOT EVER use M501 to read it back to the printer been bitten far to often with eprom settings
-
@dougal1957 said in M500 wipes config-override.g while saving settings:
I Have a config-override file BUT I only ever use it to make copy and paste commands into Config.g I DO NOT EVER use M501 to read it back to the printer been bitten far to often with eprom settings
That seems a bit odd.
The config.g file is read and then (given a M501) the config-override.g is read.
Why to you think the second file is going to be the one to have problems?
-
I do not have a M501 at the end of config.g so it is never going to be read.
I don't use the override because as Ian pointed out you can make an intentional change to the config.g only to find it doesn't work as expected purely because the override is doing exactly that overriding the master config file spent several hours/days in the past trying to figure that one out (that was on Marlin/Repetier mind never on Duet) I learnt long ago ref that.