Hi Klipper developers, starting this thread to share ideas and get feedback on Multi-tool/MMU support.
Klipper offers a lot of flexibility and excensibility to define custom macros and that has been the go-to solution when it comes to multi tool support. That unfortunately results in a lot of bespoke solutions and becoming proficient in macro development becoming pretty much a requirement. On top of that Slicers are doing their own interpretatations what is the proper way, so essentially each Printer + Slicer needs a bespoke Klipper macro setup.
This is a complex and multi-faceted area. The GCode standardization looks like the lowest hanging fruit to address. PrusaSlicer has already introduced a Klipper GCode flavor. Cura has a Klipper plugin for simiar result.
To kick this off here are GCode areas that I have found troublesome so far. Ideally if we can agree and publish guidelines what Gcode is to be used in each case. And maybe update Gcodes Klipper supports natively to better work for multi-tool scenarios.
On high level I am leaning towards endorsing Slicers to use a Klipper dialiect and adapt the Klipper specific commands. That allows for a clean cut and possibly a better API.
Tool change:
T0, T1, … is accepted industry standard. What exactly it does and what needs to be performed separately, depends on the slicer.
My 2 cents for Klipper Tn should do as much as practical, and Slicers should be generally agnostic to how physically a tool change is performed. However the items below are still controlled by Slicer and needs to work in conjunction with the T commands.
Temperature
Toolhead needs certain temperature to extrude. MMUs have a single toolhead, toolchangers/Idex have multiple toolheads. A lower Idle temerature is useful to prevent oozing
- Klipper has M104 Sx Ty, where T is extruder number
- Prusa has separate MMU mode that uses single toolhead and separate multi extruder mode that switches.
- Cura does not support MMUs and always issues M104 Sx for each tool.
- My 2 cents - continue using M104 Sx Ty, where T means tool/filament number not extruder number for MMUs. Or add TOOL=x to SET_HEATER_TEMPERATURE. Both options means introducing some tool to extruder mapping however.
Part Cooling
Each toolhead has it’s own part fan. There might be auxiliary chamber fans, or only chamber fans. The slicer wants to control “amount of print cooling”, ie first layer no cooling, overhangs get extra cooling, etc.
- Klipper’s M106 is limited to “Primary fan” only. Fan_generic has a more versatile SET_FAN_SPEED.
- Cura uses M106 S255 Ix - to specify fan index, which Klipper does not support.
- Prusa just assumes the firmware will carry over M106 speed to appropriate fan when changing tools.
- My 2 cents lean towards Prusa’s approach - allowing Tx command to reconfigure what M106 applies to. Alternatively a new SET_PART_COOLING SPEED=X may be introduced for clarity.
Pressure advance
Each toolhead/filament/nozzle can have distinct pressure advance. Pressure advance tends to be disabled for purges/MMU filament change moves.
- Klipper has SET_PRESSURE_ADVANCE EXTRUDER=x, V=y
- Cura allows firmware to handle this.
- Prusa’s Klipper Gcode flavor attempts to control PA for tool change retractions using SET_PRESSURE_ADVANCE V=0, but is bugged.
- My 2 cents is that Firmware should control this, Slicer should just command T1. That leaves out per-filament PA (flexibles) however. Alternatively SET_PRESSURE_ADVANCE TOOL=x V=y could be added?
Purges
MMus need significant purge after filament change. Toolchangers generally do some purge to counter oozing. Some printers have dedicated purge buckets, the rest use Slicer controlled purge towers.
This area seems to be fine in current status quo - either Tx does the purge or it can be enabled in the slicer.
Let me know what you think. Overall significant improvements call for decoupling Tool# and extruder/fan#, which is a big change. Then again satatus quo is redefining half of the GCodes.