This document contains guidelines for contributing an example Klipper configuration to the Klipper github repository (located in the config directory).
Note that the Klipper Community Discourse server is also a useful resource for finding and sharing config files.
- Select the appropriate config filename prefix.
printerprefix is used for stock printers sold by a mainstream manufacturer.
genericprefix is used for a 3d printer board that may be used in many different types of printers.
kitprefix is for 3d printers that are assembled according to a widely used specification. These “kit” printers are generally distinct from normal “printers” in that they are not sold by a manufacturer.
sampleprefix is used for config “snippets” that one may copy-and-paste into the main config file.
exampleprefix is used to describe printer kinematics. This type of config is typically only added along with code for a new type of printer kinematics.
- Use the appropriate filename suffix. The
printerconfig files must end in a year followed by
-2019.cfg). In this case, the year is an approximate year the given printer was sold. All example configuration files must end in
- Klipper must be able to start
kitexample config file without error. These config files should be added to the test/klippy/printers.test regression test case. Add new config files to that test case in the appropriate section and in alphabetical order within that section.
- The example configuration should be for the “stock” configuration of the printer. (There are too many “customized” configurations to track in the main Klipper repository.) Similarly, we only add example config files for printers, kits, and boards that have mainstream popularity (eg, there should be at least a 100 of them in active use). Consider using the Klipper Community Discourse server for other configs.
- Only specify those devices present on the given printer or board.
Do not specify settings specific to your particular setup.
genericconfig files, only those devices on the mainboard should be described. For example, it would not make sense to add a display config section to a “generic” config as there is no way to know if the board will be attached to that type of display. If the board has a specific hardware port to facilitate an optional peripheral (eg, a bltouch port) then one can add a “commented out” config section for the given device.
- Do not specify
pressure_advancein an example config, as that value is specific to the filament, not the printer hardware. Similarly, do not specify
- Do not specify a config section containing a host path or host
hardware. For example, do not specify
- Only define macros that utilize functionality specific to the given printer or to define g-codes that are commonly emitted by slicers configured for the given printer.
- Where possible, it is best to use the same wording, phrasing,
indentation, and section ordering as the existing config files.
- The top of each config file should list the type of micro-controller the user should select during “make menuconfig”. It should also have a reference to “docs/Config_Reference.md”.
- Do not copy the field documentation into the example config files. (Doing so creates a maintenance burden as an update to the documentation would then require changing it in many places.)
- Example config files should not contain a “SAVE_CONFIG” section. If necessary, copy the relevant fields from the SAVE_CONFIG section to the appropriate section in the main config area.
field: valuesyntax instead of
- When adding an extruder
rotation_distanceit is preferable to specify a
gear_ratioif the extruder has a gearing mechanism. We expect the rotation_distance in the example configs to correlate with the circumference of the hobbed gear in the extruder - it is normally in the range of 20 to 35mm. When specifying a
gear_ratioit is preferable to specify the actual gears on the mechanism (eg, prefer
- Avoid defining field values that are set to their default
value. For example, one should not specify
min_extrude_temp: 170as that is already the default value.
- Where possible, lines should not exceed 80 columns.
- Avoid adding attribution or revision messages to the config files. (For example, avoid adding lines like “this file was created by …”.) Place attribution and change history in the git commit message.
- Do not use any deprecated features in the example config file. The
pin_mapparameters are deprecated and should not be in any example config file.
- Do not disable a default safety system in an example config file.
For example, a config should not specify a custom
max_extrude_cross_section. Do not enable debugging features. For example there should not be a
Example config files are submitted by creating a github “pull request”. Please also follow the directions in the contributing document.