M500 wipes config-override.g while saving settings

gnydick

If the point of that file is to be able to override config.g with your own changes, it kinda sucks that after heater tuning, I used M500 and it erased all of my changes, and now I don't know what the hell they were

wilriker

@gnydick Unfortunately, the point of that file was explicitly not to be user-edited. The second line in this file even says it:

; This is a system-generated file - do not edit

Though, I am sorry that you lost your configuration. That is really annoying when this happens.

To got a bit more into detail: M500 does usually save values to the EEPROM but the Duet does not have one. So this alternative solution using a defined file with the name config-override.g was introduced.

deckingman

IMO, the very best way to manage configuration setting is create a folder on a PC or laptop and put all the configuration files in there. Then make any changes to those files and upload them to the SD card, and always keep backups of that folder. SD cards aren't the most reliable media to store critical files.

gnydick

@wilriker I hear ya. FWIW, in my field, tech, override files are specifically intended to be where you put your settings so you can leave the stock settings as reference.

Phaedrux

@gnydick said in M500 wipes config-override.g while saving settings:

in my field

In your field is it advisable to read and follow the directions at the top of a file saying not to edit it?

dragonn

@gnydick at the end of config.g, just put a comment:

;my custom settings

This is how all users do it and this is how it should work. config-override.g Is only for saving M500 settings and should not be edited.

wilriker

Another solution that comes closer to what you wanted to do is to add

M98 Pcustom-config.g

at the end of your config.g and add all your overrides to /sys/custom-config.g (or any other name that suits you and is not config-override.g). This file will not be touched by RRF and gives you the same workflow you are used to.

gnydick

@wilriker very true

gnydick

@phaedrux yeah, but that's only there AFTER it gets generated

Phaedrux

@gnydick hmmm, fair enough.

T3P3Tony

@gnydick yeah we should add a config-override.g to the stock build with nothing but the warning in it.

More generally I just edit config.g directly - there is nothing special about the stock settings - most of the time theya re there just for our in house testing and don't really relate to a real printer.

If you have used the RepRapFirmware configurator to generate your start config then just save that output as your start state if you like.

gnydick

@t3p3tony yeah, but I think it's just good to know that there's probably an assumption that when you save your settings, you're not going to lose others. Maybe the convention should be changed so instead of config-override.g it's generated-do-not-edit-changes-will-be-lost.g

DocTrucker

Why not have a feature for the autotune data to be written back into the config file?

deckingman

@gnydick Or better still, just don't use config-override.g.

Seriously, the only purpose it serves is to save people the effort of copying and pasting the result of heater tuning into config.g. It serves no other purpose.

What happens when you turn the printer on is that the config.g commands are read and acted on in sequence. Then if a config-override file is present, the commands in that file will be read and acted on in sequence. And as the name suggests, they then override earlier commands that are in config.g. Sooner or later it will bite you in the a**e because you'll want to edit something in config. g and wonder why your changes are having no effect (because they are being overiden elsewhere).

deckingman

@doctrucker said in M500 wipes config-override.g while saving settings:

Why not have a feature for the autotune data to be written back into the config file?

There is Wes. It's called copy and paste

wilriker

@doctrucker said in M500 wipes config-override.g while saving settings:

Why not have a feature for the autotune data to be written back into the config file?

RRF does not really edit files ever. It writes them new. And in case anything is going wrong while writing config.g... I guess you know where this is heading.

wilriker

@deckingman said in M500 wipes config-override.g while saving settings:

Seriously, the only purpose it serves is to save people the effort of copying and pasting the result of heater tuning into config.g. It serves no other purpose.

Sorry Ian, I have to be nitpicking here. It can also contain tool offsets, Z trigger heights and Workplace Coordinate System offsets. But for most users it won't.

Oh and (primarily) for Deltas it also contains the measured axes lengths.

But you are right in that all of these could also be put directly back into config.g.

Phaedrux

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.

gnydick

@wilriker

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.

wilriker

@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.

DocTrucker

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.

DocTrucker

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.

gnydick

@wilriker not necessarily.

deckingman

@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.

Dougal1957

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