Should physical-endstop homing retract off the endstop after the final touch? (differs from Klipper)

[biga888]

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.

[pellcorp]

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]

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.