FR simultaneous xy homing

Hello all,

I’ve asked around to see if a macro for this exists but it doesn’t seem to. It’s a feature included in rrf and I’d assume is possible in klipper but I’m not nearly knowledgeable enough to work this out myself. As an example (for core xy kinematics) the toolhead would move diagonally towards the 0,0 position and home whichever endstop is reached first then continue to home the second axis.

I don’t know of any practical benefits other than being a little more efficient but it seems like a cool feature.

Hello @Smolboi !

That could be quite difficult.
Homing works this way:

  send step pulse to the stepper motor
  check endstop switch
  if endstop switch is triggered
    exit loop
repeat loop

This need full attention of the firmware. A bit more delay and you have a crash.
Marlin does it the same way.

Either way it’s “crashing” though right? There’s no way to have it instantly stop at the endstop trigger point so there’s always a delay. Running both and waiting for a trigger on either seems like it would just increase the delay slightly and I’d think microswitches have more than enough extra travel. Though like I said, I have nowhere near enough knowledge to get it working myself. I’m not sure if the way it’s implemented into rrf could be done in klipper but it just seems like it’d be a cool feature to add.

When you home an axes one at the time, you just have one loop to program.
If you want it for 2 axes at the same time, it way more complex.

Well so based on the order you described it would need to send a pulse to either steppers and then check each endstop individually. Unfortunately I’m not sure I’m able to understand the complexity of implementing this feature if I don’t understand how it works in the first place :joy:. If you say it’s too complicated to implement then I’ll take your word for it though being able to home multiple axis individually at the cost of an (I’d assume) small delay would allow for homing individual idex print heads at the same time and croxy systems with dual steppers per axis could auto tram the cross rails though both use cases are fairly niche.

It seems this exact functionality would be possible with the “manual_stepper” function. Rather than “homing” you seem to be able to imput a position for it to move and “stop_on_enstop=1” to end the move early. Unfortunately it doesn’t seem like you can change the function that homing an individual axis serves.

Homing is a very sensitive topic especially due to Klipper’s multi-MCU capabilities, where endstop and stepper controller can be distributed over multiple MCUs.
For no practical benefit (except the coolness factor) I would believe that no developer is touching this piece of code.


Same multi-endstop homing logic may be applied to multi stepper z axis. Or for emergency stop button. Or for preventing probe crashing.
Only limitation is all involved endstops and steppers should be on same mcu.

1 Like

I agree that this would be pretty tough to implement. However, for really large beds and slow-moving axes like I have on one of the printers that I work with, “no practical benefit” doesn’t seem accurate. It’s definitely not too important, but could save some people(like me!) 15-30 seconds/home, which isn’t a lot, but it does add up. And the coolness factor is certainly at play here :grinning:

Understood. Would it be possible to jerry rig a gcode to make this work? It would be used as a coarse homing and would be followed by a g28. I’m just not sure of a way to read endstop state or hault movement on a single axis. Any help is apriciated! There should be roughly .5mm of post travel distance on a d2f microswitch so it wouldn’t need to be perfect.

That wont work: As long the firmware does not know where the print head is, how should it know where to stop? It is too coarse to get a trigger from the end switches

1 Like

Like I said, im not sure of a way to read the individual endstop state or hault the linear move. Something like wiring a second endstop to a gpio port and using them as a gcode button might work for the endstop state though I’m not sure how to hault a linear move.

This is a lot of work for basically no benefit. I have my end print and cancel macros leave the head near my X and Y endstops. this means each axis only takes a second or two to home.

But it’s a fun project and the end result would be so damn cool

I have a printer that does what you’re proposing (Zortrax M200) and it does it well but this feature is not a game changer or a differentiator that I would like on my other printers.

While what you’re proposing could be a good way to learn more about programming Klipper, it does have risks as others have pointed out in terms of collisions due to switch closures being missed due to how they are polled. Even though this functionality appears simple, it’s actually not a trivial operation to code and, along with polling the switches, you also have to work with a real time delay and requests from the Klipper system (ie the “Emergency Stop”/EPO).

1 Like

its a little bit offtopic,
but I like the Idea to move multiple axis and check for some triggers. but there is a much harder missing function “multiple independent g-code streams” on that duet3D is working Tony from Duet3D: solving my 10+ hotends tool changer firmware at formnext - YouTube
if we get both functions will give us a huge benefit.