Priority of [include....]

General Discussion
1

Basic Information:

Printer Model: ratrig vcore 31
MCU / Printerboardoctopus pro + Sht42
klippy.log

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
Be sure to check our Knowledge Base and in particular this and this post

Describe your issue:

Hi,

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
…

2

So much stuff. Risk to lose the overview…

Oh, you already did.

You should consider whether you really need all that stuff.

Stick to KISS:

I’ve seen printer.cfg with about 250 lines that run perfectly fine.

Mine has 650 lines because of the IDEX kinetics.

1 Like
3

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:

  • Update log
  • [printer] parameter defining the printer
  • [virtual_sdcard] parameter
  • [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
  • [mcu] parameter(s)
  • [extruder(s)] parameter
  • [heater_bed] parameter
  • [fan] parameter(s)
  • [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
  • [homing_override] macro(s)
  • [quad_gantry_level]’ parameter (if required)
  • [bed_mesh] parameter
  • [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.

3 Likes
4

TBH, I started off with such an organization and reverted all of it.
I found that it actually spoils the idea of “as quickly readable as possible”. Why?

  • I have no need to edit the cfgs very often
  • When I do, I have forgotten in which include I have put it and need to start searching

I keep all in the printer.cfg with the exception of:

  • The RPi Pico config as it is not always connected → Easy to (un-)comment just the include
  • The very few macros I have, because they really clutter the config

The Ratrig way of doing it, i.e. hiding everything behind aliases and includes is in my opinion:

  • Very well done
  • From an engineering point of view very cool
  • From a user point of view a bloody mess since especially beginners have a hard time understanding it and this obfuscation makes it even harder
3 Likes