M500 wipes config-override.g while saving settings

gnydick

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

fcwilt

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

Dougal1957

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.