Hey!
As far as I can tell, homing moves always immediately stop (with infinite acceleration?) when hitting an endstop. That seems reasonable for light machines, but problematic for very heavy axis. Those might allow for some overshoot (e.g. with long levers on the endstops) and cannot tolerate high decelerations.
For my actual use-case, I’m somewhat abusing the homing mechanism to just get a motor to stop when triggering a switch. But the problem I’m facing - very high deceleration with a heavy axis - is the same.
The lever is generally made of a spring steel and will give you a millimetre or two for the gantry to stop.
In any case, when homing you should not be moving so fast that when you stop sending step pulses to the gantry/toolhead steppers, things stop rather than continue moving due to momentum and overpower the stop position of the stepper.
I am not concerned about hitting the endstop - I’m having problems with a heavy axis being unable to immediately stop after triggering the endstop, needing some deceleration as to not lose steps and/or damage components.
As I mentioned in my original post, endstops with long levers do allow for some travel after an endstop is triggered. But klipper does not make use of that, and immediately stops with infinite deceleration instead.
It would be helpful if you defined what you consider a “very heavy axis” along what you consider to be a “reasonable rate”. It seems counterintuitive to me to have something that’s very heavy but can be damaged by an immediate stop.
I don’t think there’s much you can do other than what I suggested:
Home at a speed in which stopping pulses going to the stepper driver results in movement stopping.
Have some buffer space with an endstop switch lever.
I guess you could use something that provides you with a known amount of space before parts collision could be used, like a Hall Effect switch, an inductive sensor or an eddy current sensor. When you get the endstop point, then you could add custom code to Klipper to decelerate the moving mass when the endstop is triggered.
Don’t forget, for the X/Y Axis, it is generally not critical to stop at exactly the same point; being repeatable to within a few tenths of a millimetre is not going to be a problem.
Is this something that can be done nicely (e.g. without moving 1mm, stopping, moving an other mm, ..) with macros or the python API, without any modification to the C firmware?
Edit: Ah, I misunderstood - that’s what you were talking about, emulating `[probe]`.
For my usecase, that sadly doesn’t cut it.
Also, I’d like to reiterate that decelerating is not something optional that you only need when moving way too fast. Maybe big printers are out-of-scope for klipper, but just imagine a (2m)³ printer with thick steel beams as axis. You’d have to home painfully slowly to prevent skipped steps when the axis go from homing speed to zero in an instant.
There are a few large commercial printers that are in this size range, like:
If you look at them, you’ll see that they all use the same approaches end stop detection as much smaller printers, even though they use much larger steppers (or servos) and extruders.
I’m asking if this is a thought experiment because, it seems to me that being worried that the inertia of the gantry/toolhead is so great it will overpower a stepper that is stopped then I would expect that you will have problems getting the gantry/toolhead moving in the first place as you’re applying a similar amount of torque from the stepper. Remember that when the stepper stops moving (ie no more step commands to the driver) when it encounters the endstop the coils in the stepper are still energized to hold the stepper in the current position - the holding torque is similar to the torque used to start the gantry/toolhead moving.
My recommendation to you would be to do some research on the large 3D printers that are in existence and reach out to their designers to see what control software and firmware is being used and what kind of problems they experienced with endstops.
Homing always is way slower than usual moves. And for more precision, a second home move is made that is usually half the speed of the normal homing speed.
Most switches have overtravel so you can go past its trigger point a certain distance before the switch stops giving way or breaks, some machines may even have a switch mounted in such way that axis overtravel isn’t limited by the switch. Example
This seems like a very interesting idea!
Going extremely slow feels more like a hack to a problem deceleration would fix.
Even if I am able to home fairly quickly, and the gantry is able to stop “instantly”, this cannot be good for the motion system.
However, this would mean that a deceleration curve would need to be instantly calculated after an endstop triggers, and sent to the stepper. This might not be easily possible with the way Klipper operates, where the main computer calculates the moves before sending them to the MCUs to execute, as there might be a need to constantly have a buffer of commands in the MCU, adding latency after the deceleration commands get to the MCU.
(I have never looked at the Klipper codebase, this is just an educated guess)
Maybe someone with more knowledge on the inner workings of Klipper could comment on the feasibility ?
