anyone have any cautions in adding custom macros in klipper ?
example of why i ask my question:
i Hate that Klipper automatically starts dropping the extruder and build bed temps when a print completes;
there are a number of things that might require keeping those temps where they were for a minute or two;
maybe visually inspect the product print in case print it again, maybe change filament, maybe finish doing a slice adjustment that you just thought up, others…
so my thinking is to program and add a macro that maintains the current temps for a minute (adjustable in the future after seeing how that goes) ;
but i dont know whether the macros can be automatically triggered
or if they must be triggered manually;
my thinking is to make a driver macro that starts a print and has as a finishing step a call to another macro that does what i need;
absent that “call” i guess i need just add the line-by-line-code;
Klipper macros are a great part of the system but:
They Jinja2 based which means they do not follow typical programming paradigms and they can be confusing to follow and copy into a system correctly
There are a ton available that look like they do just what you want and I’ve seen many people (me included) getting caught copying in macros that don’t work as expected and you end up damaging a part of the printer (for me, it was ruining a brand new PEI print surface and steel nozzle)
Macro execution takes priority over other functions in the printer (including user IO) and can result in some situations where printer operations are suspended while macros are executing
Basic Klipper operation (with Mainsail or Fluidd) is very good, other than the minimum macros listed next, there’s really no reason to add any unless you have some custom/nonstandard or hardware that doesn’t perfectly fit the Klipper paradigm
You’ll find that most people experienced with Klipper will run with a minimum of macros with the base ones have standard code and are:
PAUSE
RESUME
CANCEL_PRINT
There are a number of NeoPixel macros that can be added to give you different types of control over them and are usually pretty safe to run.
If you’re running a CoreXY/Voron 2.4 printer, you may want to add:
homing_override (if you are using TMC2209 stepper drivers and doing sensorless homing)
BED_MESH_CALIBRATE (Does a bed leveling operation first)
Yes, the capitalization is critical for correct operation of the macros.
I’m not quite sure why you’re asking for something that keeps the heater PWMs active for a minute or two at the end of a print; I find that when the nozzle heater block and bed have power turned off, they stay pretty hot for at least a minute or two and take just a few seconds to come back up to temperature. Regardless, I would think that you would add the macro call at the end of your gcode (specified in your slicer) - You don’t want to start a print from a macro.
Can I suggest that you first read this:
secondly join the discourse group:
and read through what people have already done in terms of macros.
When you join the discourse group, I would suggest lurking for at least a week so you can see how questions are most effectively asked (ie ALWAYS include your klippy.log in any question).
I’m saying this because Klipper macros are problematic - many new users do searches for functions they want and discover macros that sound cool add them and their printers stop working. If you add something yourself and can’t explain it, you’ll be told to remove all of them and get your printer working again because nobody has the time or inclination to try and debug a printer (or some unknown type and setup) remotely or write a custom macro for you.
Did I say it’s a good idea to keep your macros to Klipper to an absolute minimum?
