Klipper: Use ConfigParser instead of RawConfigParser

[mamoit]

The RawConfigParser does not support BasicInterpolation.
I changed it on my local instalation for the ConfigParser and it works like a charm.
The reasoning behind it is to bind configs together.
In my case, I wanted to bind stepper_z:position_endstop with the probe:z_offset since the z endstop is the probe.

PS: I can PR it if you think it can be useful

[hg42]

I think ExtendedInterpolation would be even better then, because it can interpolate values from other sections ${section:key}.
I also think ${name} is more readable, because it uses the more common '$' and lacks the 's' postfix of BasicInterpolation %(...)s

[hg42]

With such a parser, we could allow additional sections for defining some common variables that can be used in other sections.

[KevinOConnor]

Well, I don't think I'd have any hope of documenting what BasicInterpolation does. I can barely follow the cryptic syntax myself.

I'd say what we really want is a mechanism to auto save/restore feedback from bed_tilt_calibrate and similar. I suspect adding complexity to the config parser wont gain much.

-Kevin

[mamoit]

That's indeed true (both that it can be complicated, and that we need to save feedback).
To save changes done to the config file we can always do as described on the first example here and use config.write to do it.
It can also allow for setting offsets in the configs permanently with commands, instead of editing the file manually.
PID tuning is another use case for eg.
The ConfigParser syntax is quite simple once you get used to it, and it would allow to do some nifty tricks for advanced users.

[mamoit]

By the way, @hg42 I don't think ExtendedInterpolation is available in python 2.7 :disappointed:

[KevinOConnor]

To save changes done to the config file we can always do as described on the first example here and use config.write to do it.

FYI, using the ConfigParser write mechanism would result in user comments being stripped from the config file. I don't think that would be acceptable.

-Kevin

[mamoit]

That's an issue I did not consider.
You are right.
Maybe we could have a base config file (with all the comments) that would serve as the current one does, and have another solely for overrides that may vary within 2 printers of the same model, such as bed tilt parameters and nozzle offsets for dual carriages.

[KevinOConnor]

Maybe we could have a base config file (with all the comments) that would serve as the current one does, and have another solely for overrides that may vary within 2 printers of the same model, such as bed tilt parameters and nozzle offsets for dual carriages.

Yes, that's a possibility (have a printer.cfg and a printer-autosave.cfg). Another option I was considering is automatically appending a comment block to the end of printer.cfg - something like:

#*#
#*# The remainder of this file is auto-generated.  DO NOT EDIT.
#*#
#*# [bed_tilt_override]
#*# x_adjust = .000200
#*# y_adjust = .000219

The gain of this method is that it allows the user to more easily see what the stored parameters are and to more easily backup/restore them. The disadvantage is that it is more complex and it requires care to ensure that the users config isn't corrupted.

-Kevin

[mamoit]

I get the idea of having a single file may be quite interesting, but imagine, I have a printer A, and I configure it, I setup all the pins and whatnot, and I share with everybody my config file.

• If it is a monolithic file, then all the calibration that I made for my specific printer (tilt for eg), would go with it, making it harder for new users to troubleshoot issues on newly setup klippy instances. Also, the parsing would be quite troublesome since it would not leverage directly the ConfigParser module.
• If the configuration is separated in 2 files, one can easily be written without the worries of comments (the auto generated one) and no fancy parser would need to be implemented and the other could be shared easily with any who have the same printer model A.

With the 2 files we could actually just load one file over the other, and let the 2nd one replace values of the first one.

[cmock]

I see another use case for non-monolithic configs: When you have different toolheads for a printer -- like a V6 and a Volcano.

With that, I'd like to have a main config file (pin configuration, most of the printer geometry etc) and then #include one file per toolhead with stuff like x/y/z offsets, nozzle diameter, acceleration and speed settings.