For any command, call a corresponding PRE and POST macro if defined

Features
1

In trying to wrap existing commands (or macros) for setting colours on LEDs (G28, G109, etc…), and realising the current limitations that macros are bound to (no recursion, global redefinitions) it might make sense to look for and execute corresponding PRE and POST commands. This feature can also be generalised in order to solve the ‘how I do just do something extra’ problem.

Using G28 as a use case for example, I could create something like [gcode_macro PRE_G28] to set my neopixels to green and then [gcode_macro POST_G28] to turn them off again when done. Handling multiple invocations of these macros might be tricky due to the recursive nature of G28, but could likely be addressed as long as access to rawparams/params is available.

In order to support a second hook on G28, say to also connect a mag-probe whenever G28 is executed. and dock it once complete, the naming of the macro could be more flexible to allow an arbitrary value before the prefix and suffix tokens… i,.e:

[gcode_macro PRE_LEDS_G28]
[gcode_macro PRE_KLICKYPROBE_G28]
[gcode_macro POST_LEDS_G28]
[gcode_macro POST_KLICKYPROBE_G28]

The order of execution of these can be in alphabetical order in to allow for the person defining these to have some deterministic way of knowing when their hook will get called.

2

Also implied is the following:

[gcode_macro PRE_PRE_LEDS_G28]

would be executed just before calling the PRE_LEDS_G28 macro, or if there is no such macro… it would just be called before a G28, added to any other PRE_*_G28 in alphabetical order (So PRE_LEDS would be the arbitray name in this case) .

3

If you are running Klipper on OctoPrint, you can write a plugin to obtain this.

https://docs.octoprint.org/en/master/plugins/gettingstarted.html

Maybe there is already plugin that fitss your needs in the repo:

4

I don’t run Octoprint, and my needs aren’t really the issue as one could always go into their specific setup and change their current macros, or create new ones, or in the case of G28, modify [homing_override].

Where this is really needed IMHO, is when extending the functionality of the printer, there isn’t a way for the extension maintainer to deliver a conflict free way to update the functionality of the existing commands.