IDEX: Homing issues

Basic Information:

Printer Model: Creality CR10 modified: IDEX, SKR Mini, CANBUS, etc

klippy(2).log (3.0 MB)

Describe your issue:

I have two X carriages, and am using the sample sample-idex.cfg as a base. Both carriages home to the same side (the left) but I then need to park dual_carriage on the far right. Currently they both home against their switches and remain there.

issue #1: So eventually I need to modify the homing macro, trouble is I do not see a G28 Macro specified anywhere in any of the .cfg files.

issue #2: after homing, I need to figure out which position to park dual_carriage at. I would normally drive it manually from the klipper frontend to figure out the position. Problem here is that the homing routine seems to set carriage=0 at the end, but it is carriage=1 that I need to move. No problem, hit the T1 macro, but this causes the homed status to be lost, so I cannot move it without re-homing… which sets us back to T0, so I can never get manual control of T1. My question here is: Is losing home status when switching tools the expected behavior? if not is there a fix? if so, how should I proceed?

Hello @Fuergrissa !

Quite uncommon, is there a reason for that?
With a endstop on the right side for the 2nd extruder, things would be way more easy.

This is a bug that was introduced when mirror/copy modes were added.
It didn’t get caught during beta testing because nobody who homed T1 left helped test.

There is a pull request to fix it which will probably be merged within a couple weeks judging from the discussion.

So your solution is to use an older version of Klipper which doesn’t support copy or mirror modes, use the pull request build, or wait for the fix to be merged. Ideally you’d test the most recent pull request build and let the developers know how it works.

1 Like

I have separate EBB CAN boards for each X stepper that are mounted on the same side, so it was easier to wire the end-stop on that side as well. I could have the endstops on the carriages but the second carriage is currently empty, I haven’t bought a second extruder or CAN board for it yet. So it was really just easiest from a cable routing point of view.

I read through that thread and it definitely sounds like it will fix the loss of homing status when switching tool-heads.

If I want to use this branch I need to re-flash my main board and all of the CAN boards as well, is that right?

1 Like

Re-flashing would be best practice, but I do not know if it is required for the changes involved.

My printer homes T1 right, so I have not used the pull request.

EDIT: looks like the PR will be merged very soon

Not needed for the change as described in the PR.

Could someone help me with how to implement this PR? I have tried git pull from the klipper directory on the pi which produces fatal: refusing to merge unrelated histories. Do I need to clone the dmbutyugin repository over the local branch?

using git is clearly still very confusing to me

EDIT: This required me to enter a commit message, but it shouldn’t matter to anyone as long as I don’t try to push (which hopefully wouldn’t be allowed right?). So I should have the fixes now right?

pi@idexpi:~/klipper $ git pull idex-homing
 * branch              idex-homing -> FETCH_HEAD
Auto-merging docs/
Merge made by the 'recursive' strategy.
 docs/          |  9 +++++++++
 docs/        |  8 ++++++++
 klippy/kinematics/ | 53 ++++++++++++++++++++++++++++++++++++++++++++---------
 3 files changed, 61 insertions(+), 9 deletions(-)

Usually you would do:

git fetch origin pull/6310/head:pr-6310
git checkout pr-6310
sudo service klipper restart

To return to default Klipper:

git checkout master
git branch -D pr-4128

Last command just deletes the PR branch. Only needed if you want to.

Now you messed up your installation a bit since you pulled the development branch. Since I’m not a git guru, I don’t know how to best return to the default origin.

I’d probably choose the brute force approach:

cd ~
rm -rf klipper
git clone

Then you could get the PR with the above approach

Thank you!

This did fix the issue allowing me to switch between toolheads T0 and T1 without losing the home status, only one issue remains. Currently Home all will:

  1. Home X1
  2. Home X2
  3. Home Y
  4. Home Z (crashes, because X2 is in the way of X1 moving to the correct position to home Z).

What I would like it to do is:

  1. Home X1
  2. Park X1
  3. Home X2
  4. Park X2
  5. Home Y
  6. Home Z

The macros for parking X1 and X2 already exist and work fine. Is there a way to changing the homing behavior to implement this?

1 Like

I can’t walk you through it, but you’ll have to use homing override.

Home X axis, then switch to T0 (which will probably park T1).
Then home Y, then Z.

A couple issues you may run into:

Safe Z home and homing override cannot both be used at the same time, so you’ll have to incorporate the safe z home coordinates into your homing override routine.

If your T0 macro references homing, klipper may throw an error that it is being called recursively. A macro can’t call itself or another macro that calls it. The workaround is to duplicated the gcode in the other macro instead of using the other macro.

Thank you,

I have it working with this section added to config:

    G28 X0
    G28 Y0
    G0 X150 Y150
    G28 Z0
1 Like

Hi all,

I had installed the IDEX branch about a month ago and I had the same home loss issue and am just now able to come back to it. I tried doing a fresh install of Klipper with the same branch link but I’m having the same issue. Is there a better way to go about this? A lot of this stuff is over my head but I’m making an effort to figure it all out.


What exactly is your issue?
Did you use the IDEX branch I linked on Facebook?