Save_Config Priority over other printer.cfg sections?

[remarkable_sir]

I looked around a bit and checked the config reference but was not succesful yet to find an answer to my question.

In several different areas it is possible to specify values for stuff like probe, bed meshing, PID tuning or input shaping…

Lets stick to input shaping in my example.

I ran Klippain Shaketune and manually entered a section according to the reference.

By accident I also initiated the standard [Input_Shaper] command that executed save_config and appends values to the end of my file.

My queston to you is what has the priority?
Machine runs but I wonder which parameters are in use…

Oh I just noticed that the duped lines are outcommented now in my config.
Obviously outcommenting took place automatically. Where is this mechanism documented?

[EddyMI3D]

@remarkable_sir

My queston to you is what has the priority?

The priority is the config_block.

Things PID, shaper values, offsets etc. that are determined by Klipper functionality are stored in that block and yes, the according settings in the config are commented out.

Just to be curious: After 1 1/2 years you noticed the existence of the config lock?
Never done a PID or so?

[Sineos]

There is nothing like a priority: The configuration is parsed and collected from top to bottom. This means that later entries can potentially overwrite earlier ones. The same logic applies to [include ...] statements. They are parsed or collected at the location where they appear in the configuration and can be potentially overwritten later.

[koconnor]

The config is parsed from top to bottom, later entries will override previous entries.

However, entries in the “auto save” block (those lines at the end of the main printer.cfg that start with #*#) do not override normal entries in the config. (The entries in the auto save block only take effect if they are not specified anywhere in the main config files.)

In any case, the best reference for what has taken effect is to look at the log file. On every start, the actual config that is utilized is written to the log. It wont have duplicates and it is an authoritative reference on the active configuration.

Cheers,
-Kevin

[remarkable_sir]

Great, thanks!
Good information. Parsed from top to bottom and logfile as reference. That’s what I need to know.

The content of config block is in most cases not applicable anymore in my config. PID tuning parameters or other stuff is found more upward in the config section. And adaptive bed meshing is executed prior every print and not saved in the config. So there is really only a beacon model and nothing else in the moment…