Basic Information:
Printer Model: Custom bed slinger IDEX printer
MCU / Printerboard: Octopus Pro + 2 EBB42 boards connected via CAN
I want to discuss a weird behavior that I had to fight after configuring my DIY IDEX machine following the example “sample-idex.cfg”.
My machine is an IDEX bed slinger, where the 2 extruders are parked in the opposite sides of the X axis rail.
I managed to put together a working configuration following the aforementioned sample without much trouble, but I faced some strange bugs that I finally traced down to an incomplete configuration + an unexpected (to me) homing sequence management.
The problem was the following:
-Machine is turned on and homed. Carriage 0 and extruder 0 are selected by default and they work as expected
-Calling the T1 macro everything works correctly, carriage 0 is parked and extruder 1 / carriage 1 are enabled.
-Homing the machine again triggers the problem: the default homing procedure leaves carriage 0 enabled regardless of the previous state, and obviously doesn’t change the enabled extruder (still extruder 1). This means that carriage 0 is the one responding to commands, but M104 still heats up the extruder on carriage 1.
The T1 macro as it is coded in the “sample-idex.cfg” file first parks the enabled carriage, inferring however the enabled carriage using “printer.toolhead.extruder”. Due to the fact that extruder 1 is still enabled, the parking procedure causes an “out of boundaries” error, because it tries to park carriage 0 to the carriage 1 parking location. This error prevents the subsequent instructions from being executed and thus carriage 1 never becomes active.
This caused a lot of trouble, prints that started with the wrong tool, tool not heated, wrong material, messed up GCODE_OFFSETS etc… and took me a really long time to figure out, as the out of boundaries errors are sometimes covered by the macros popup in klipperscreen (and regardless of that it still wasn’t obvious what triggered the issue till when I decided to finally dedicate a day to trace down the issue).
The solution in my case was to implement a homing_override that ensures that the state of the machine after homing is consistent (it actively enables both carriage 0 and extruder 0 at the end).
Is it possible to update the homing routine for multi-carriage printers so that it leaves the machine in the correct state at the end? Alternatively the sample-idex configuration could be updated to compensate for this behavior, or at the very least i think this should be mentioned in the configuration reference where multi carriage is introduced.