Posibilities for having more than one endstop per stepper

Basic Information:

Printer Model:
MCU / Printerboard:
Host / SBC
klippy.log

Printer: Voron 2.4 350
MCU: BTT Manta M8P
Host: CB! on Manta M8P board
klippy.log (615.7 KB)

I have a Voron 2.4 witch I modet with a toolchanger setup.
Now.. How the title says, im looking for a solution for having the x endstop for each toolhead. There are some posibilities, like using sensorless, or some strange levers that would interact whit a switch mounted near the y switch somewhere the right gantry motor mount…
What I want is to use the x-endstop pin on each toolboard. From what I searched on the internet klipper does not allow multiple endstop pins for a stepper.
Here comes a user named “kensand”(i dont know if its active here…) on github, in a post for using multiple pins for a stepper, with a modified version of the klipper “multi-pin.py” that lets you use multiple pins for a stepper trogh a [multi_pin xendstop] section…
Here is the file:

multi_pin.zip (1.1 KB)

and here is the link: Feature Request - Handling multiple X Endstops, one on each tool · Issue #35 · viesturz/klipper-toolchanger · GitHub

Now…(again), I tryed it and it, kinda, works… I repalced the original multi-pin.py(after I made a back-up) whit the modified one. It works, but whit a delay between the triggering of the endstop and the actual stoping of the movement of the toolhead big enough to crash the toolhead on the end of the travel, end klipper sending an error. My question is: is this a limitation of the multi-pin function in klipper, because its intendet for use whit non priority “things”, like fans and heathers(i dont know what else), or the modified multi-pin file is not, how do I put this, in its best form? Can it be improoved to work how I espected to work, to stop the movement instant on triggering of the endstop?
I hope I dont upset annybody with my questions…

Im asking this because I can see the code in that file, I see the words, letters, numbers, but all I understand is… not much(much close to nothing…)

Currently, there is no proper way to achieve this. A complete overhaul of Klipper’s homing logic is in the planning, but no ETA is available.

Yeah, but this answer is not for my question… I did not asked when will klipper do this. I can understand that there are more importand things to do first.
Does this file I posted in that zip work at its best or that delay is caused by some wrong lines in the code? Sorry for insisting…

We do not comment on unknown code modifications. Please revert to the original author.

Thank You. Unfortunately, I cannot get a hold of him…

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