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?
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.
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.
Could someone help me with how to implement this PR? I have tried git pull https://github.com/dmbutyugin/klipper.git 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 https://github.com/dmbutyugin/klipper.git idex-homing
From https://github.com/dmbutyugin/klipper
* branch idex-homing -> FETCH_HEAD
Auto-merging docs/Config_Reference.md
Merge made by the 'recursive' strategy.
docs/Config_Changes.md | 9 +++++++++
docs/Config_Reference.md | 8 ++++++++
klippy/kinematics/idex_modes.py | 53 ++++++++++++++++++++++++++++++++++++++++++++---------
3 files changed, 61 insertions(+), 9 deletions(-)
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 https://github.com/Klipper3d/klipper
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:
Home X1
Home X2
Home Y
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:
Home X1
Park X1
Home X2
Park X2
Home Y
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?
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.
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.