Welcome here Justin!
As far as I know and work with it there is no need or way to independently home each extruder/print head.
You just call G28 X0 and then X homes and after that the Dual_Carriage (X1) homes.
Depending on the endstop config X1 either homes against X or against the right endstop.
After the homing finished you can toggle the print heads and move them.
Okay thanks! I’ll play with it again with that in mind and see if I can get it working. Basically once x homes it doesn’t think that it’s homed so it won’t allow me to move dual_extruder.
Best is to open a sperate thread if you won’t get it fixed as this is not the right one for such topics here.
There upload your whole klippy.log as the template requests.
So we can see any errors in the config.
If you have your carriages homing in the same direction, you can check out the PR - in these cases the mainline Klipper has a regression and that PR proposes a fix which you could test then. If you do home carriages in the opposite direction, the problem could be elsewhere. One possibility that I previously saw is that if one sets position_min (or _max) too close to position_endstop and uses multi-MCU homing, then due to inherent latencies of such homing setup the carriage may end up below position_min (or above position_max, depending on the homing direction), which is technically an invalid position. And that may throw off the kinematic range calculations when changing the carriages. In this case the fix is to introduce a small position difference between position_endstop and position_min/max (just ~0.5mm should suffice).
Hello together, I also tried the current version of Klipper with COPY and MIRROR mode. It works pretty good, thanks for the work!
But I have one issue. When I use BED_MESH_CALIBRATE on T0, everything works fine. But when I switch to T1 the printhead moves to the first probing position and after the first “trigger” it just moves to its homing position and crashes into the endstop. Did anyone else observed this behavior?
Please note that bed mesh cannot reasonably work with COPY and MIRROR modes. This is because the two toolheads will be in the different places and cannot physically have different height (unless you’d be able to somehow independently control their Z offsets). So in general, there isn’t much point in probing with T1 (T0 should suffice, but in general, bed mesh probing shouldn’t be used at all). That said, this behavior is still undesirable and may be a bug, so may need to be fixed.
Hello, thanks for your reply. I agree that bed_mesh doesn’t make any sense to use in COPY or MIRROR mode. But if I want to use my T1 printhead for printing, I would like to probe the bed with T1. I have a probe on each of the printheads so I don*t have to keep me busy with the z_offset between the heads…
Wouldn’t the mesh be the same regardless of which probe is used?
The bed is shaped how it is shaped regardless of probe.
There is the issue of having to heat T0 for homing Z in case there is cold plastic on the nozzle.
I guess if you are doing the mesh by probing with the nozzle, that could also throw things off.
I heat and home with T0 regardless of whether it will be used in the print or not.
If you don’t want to do that, perhaps you could bake application of the offset into your print_start macro.
If using prusa-slicer 2.6 or newer, you could utilize the recently added is_extruder_used placeholder to determine if only T1 will be used for the print and adjust the offset if that condition is met.
The question is:
While printing in copy/mirror mode, does bed mesh compensation make any sense at all?
To what extruder should the z-axes be compensated to? T0? T1?
And if T0 compensates for a low spot, there can be a high spot with T1 and vice versa. Trouble ahead.
I suggest a average constant z-offest and a thicker 1st layer.
There is no question there.
Everyone so far has agreed that it’s best to clear the bed mesh before printing in Copy or Mirror mode.
MScott was inquiring about probing for the mesh with T1 instead of T0 if only T1 is going to be used in the print. I don’t see where it makes any difference.
The difference is, that I am probing with the nozzle. So T0 and T1 have different mesh. The benefit of probing with the nozzle for me is, that I don’t have a z offset between the nozzle.
So for now I will switch to an older version of Klipper and see if in a few months the issue was solved.
Thx for your great work on IDEX feature dmbutyugin
May I ask a quick question here. Is it not an easy job to implement “multiple stepper motors supports” for “dual_carriage” in Hybrid-corexy Kinematic?
I had a quick look the code between corexy.py and hybrid-corexy.py. In which, I found that hybrid-corexy kinematic is now supporting single stepper motor for A/B drive only atm. In order to enable mulltiple stepper motor support, I found that we can modify the code for X-Axis/Primary print head with simple replacemnet of method “PrinterRail” with “LookupMultiRail” for stepper_x for the following line of statement.
self.rails = [ stepper.PrinterRail(config.getsection(‘stepper_x’)),
stepper.LookupMultiRail(config.getsection(‘stepper_y’)),
stepper.LookupMultiRail(config.getsection(‘stepper_z’))]
Sorry if I shouldn’t reply on this post with new question 
Hi @dmbutyugin, thanks so much for your work.
I run a Discord group of about 250 members for a budget IDEX printer based on Marlin. We are excited to finally try Klipper on our printers.
During our testing, should we be using your branch and reporting bugs there? Or just use mainline klipper?
All currently relevant topics are merged into main line.
Did the issue of losing home position when both heads are homed to one side get resolved? I haven’t been able to find anything that explicitly says so yet.
Thanks. I could not remember how to find that to check.
I did find a bug where if you choose T1 and then home X, the printer thinks T1 is still selected but T0 is actually moving. T0 and T1 parking routines will then fail with invalid position. The fix is to issue manually:
ACTIVATE_EXTRUDER EXTRUDER=extruder
SET_DUAL_CARRIAGE CARRIAGE=0
Can you provide more details, like printer configuration and the minimum gcode sequence that demonstrates the problem?
TBH, I’m not sure, perhaps the calculation of the reverse kinematics for the homing may need some minor adjustments. But should be doable in principle.