Repository navigation
Should physical-endstop homing retract off the endstop after the final touch? (differs from Klipper) #944
Description
Question / observation
On Kalico, home_rails (klippy/extras/homing.py) does an extra retract after the second/final homing touch — the second if hi.retract_dist: block ("Retract (again)") — moving the axis homing_retract_dist (default 5 mm) off the endstop once homing completes. Mainline Klipper leaves the toolhead on the endstop after the final touch. This looks like it came in with "Sensorless retract dist fix (#109)".
Is the post-home retract intended to apply to physical endstops too (not just sensorless)? Asking because it changes physical-endstop homing behavior vs Klipper, and I ran into an edge case where it matters.
The edge case
On printers whose X and Y endstops are co-located / share a corner — e.g. the Creality Ender 5 Max — X can only reach its switch with Y fully at the rear. With the post-home retract, after Y homes it sits ~5 mm forward of the rear, so the subsequent X home misses the shared-corner switch. The same machine homes fine on Klipper, where the axis stays on the endstop.
Repro
Ender 5 Max (physical endstops, CoreXY, home Y before X): G28 → Y homes and retracts ~5 mm → X drives past its endstop.
Possible directions (whichever fits your intent)
- Limit the post-home retract to sensorless endstops, or
- A config knob to disable it independently of
homing_retract_dist(which currently also controls two-touch homing).
Happy to test or open a PR in whichever direction you prefer.
Environment
Kalico v2026.04.00 (pellcorp/kalico-rpi build), physical endstops, CoreXY. Downstream context: pellcorp/creality#1434.
Activity
pellcorp commentedon Aug 6, 2026
I am eagerly waiting Kalico direction on this, is this a bug / missing feature in Kalico or something we got to work around? Something perhaps we misconfigured?
nmw commentedon Aug 9, 2026
I ran into this too. Just decided to try Kalico for the first time, and crashed on homing, since my printer homes X by running the axis bar into a switch, but then the print head cariage presses against the y endstop at the end of travel. Because it retracts after homing X, it misses the Y endstop and crashes into the side.
For now, I've just added a "G0 X250" to move it back to the switch between the X and Y homing in my [homing_override] as a workaround, which isn't a big deal, but it is different behaviour from klipper, and many people will assume that after homing an axis they're at the home, and not some mm away from it.
rogerlz commentedon Oct 2, 2026
Thanks for the detailed report. The final retract came in with the sensorless homing rework and was only meant for sensorless, it shouldn't apply to physical endstops. #993 limits it to
use_sensorless_homing, so physical endstops stay on the endstop again, same as Klipper.homing: Skip final retract on physical endstops