Unexpected behavior with sample-idex config

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.

Hello @Muz94 !

Would be a bit more easy to find out with a klippy.log.

Please attach it to your next post.

BTW: How do you home Z?

1 Like

Hello Eddy
I know, I don’t have the machine at home and I wanted to describe the issue now that I have time. I can post the log file tomorrow at work.
However it’s not a behaviour related to my specific printer, the log file didn’t show much info, just a few out of bounds errors. I think the example configuration just needs a little more details to make it easier for the users.
It wasn’t something impossible to fix, I just thought I’d post it here as I didn’t find much about this “issue” and I started to think I was doing something wrong.

I home Z with an inductive sensor placed at the end of travel on Z+. Then I have an inductive probe on the main carriage to compensate for thermal expansion, bed deformation and other stuff.

Here is the log
klippy.log (115.1 KB)

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.