Fill out above information andin all cases attach yourklippy.logfile. Pasting yourprinter.cfgis not needed Be sure to check our Knowledge Base and in particular this and this post
Describe your issue:
My printer settings use a lot [include…], this has advantages but is often also worse than a toothache.
Since when sections are repeated by mistake, and I think I’m changing a value I’m not actually doing, since I have the same section with another d3 configuration file that has priority over the one I modify
What priority criteria does Klipper use, when something similar to mine happens? When repeating a section in two include
Klipper uses the last cfg parameter encountered. There’s no priority, just the last parameter is the one that is used. There’s also no warning/error messages for repeated parameters.
I know, from a software development standpoint, that it doesn’t feel right to lump everything into one source file when you can put related statements into a single file and keep everything small and organized but it’s the wrong way to do things in Klipper.
The primary reason to put everything in a single printer.cfg file is the SAVE_CONFIG overwritten parameters (Z height offset, temperature PIDs, input shaper, etc.) which must be defined in the based printer.cfg file - otherwise they won’t get automatically updated correctly. The only time you should use [includes] is for mainsail.cfg and any LED enhancement macro files.
Personally, I found that the best way to organize printer.cfg is to put things in the following order:
[printer] parameter defining the printer
[includes] loading in mainsail.cfg and any LED enhancement macro files
I use global defines for default values (like stepper current values) so that I can ensure any changes (ie experimenting) results in everything being updated
[stepper_x] and [stepper_y] stepper motor parameters
Z axis [stepper] parameter(s)
If I was using a dockable Z axis sensor (ie klicky), I would put the definition parameter(s)/macros here
[quad_gantry_level]’ parameter (if required)
[gcode_macro PAUSE] along with the various CANCEL and RESUME macros
LED (ie NeoPixel) definition parameters
User Interface (if part of the printer) definition parameters
Even though this approach is somewhat organized and the order is defendable, I wish I could put many of these list items into [include] files to keep printer.cfg as quickly readable as possible.