Using Klipper Macros for Comments/Versioning Information

Developers
1

As I was working through getting the TMC2240, I wanted to have some way of being able to track the changes to printer.cfg and have them visible in the klippy.log so I could track what changes resulted in different connection/execution issues just be scrolling up/down rather than consulting another document (paper or digital).

This worked out very well for me and I wondered about using this approach for not only notes regarding configuration change text but also using to record the version information of the printer.cfg like:

[gcode_macro version]
variable_line01: "****************************************************************" 
variable_line02: "** 2025.11.22 - Initial Version, Test TMC2240 Operation       **" 
variable_line03: "**            - Copied in Original manual_stepper printer.cfg **" 
variable_line99: "****************************************************************" 
gcode:

It’s nice to have as a reference to go back on when debugging.

Will doing this have any negative impact to the operation or speed of Klipper?

I’m asking because I would expect the typical macro data size required in a printer instance to be normally in hundreds of bytes, if not tens, and doing this could very quickly increase into thousands of bytes.

2

I’d guess it wouldn’t be an issue. That info is only stored in the host computer so it doesn’t impact the micro-controllers. The GUI frontends will often read the config, which would convey that information, so it is a little more information sent over the “webhooks api”. As long as you kept it to under a few 100KB I doubt it would be an issue.

-Kevin

1 Like
3

That’s what I thought.

I just looked at my longest version comments in a printer.cfg and it’s around 8k.

I’m loquacious in my version commenting but you’re talking a couple of orders of magnitude more than I would expect version information/specifics to take up.

Thanx for the reply.

4

As afar as I know, some values, as the date, have been automatically captured from somewhere, or you mean that you need to write the date each time you make changes?

5

I typically track changes by date but, as I said in the OP, I started doing this when I was experimenting with different settings and I wanted a more easily read and tracked record specific to the printer.cfg version referenced with the information following it in the printer’s klippy.log.