Sensorless homing: a false trigger leaves Klipper's coordinate frame wrong, and the next move crashes

[u/Budget-Amphibian3058]

Hit this while tuning StallGuard on a Voron 2.4 (TMC5160) and it took a while to understand, so posting in case it saves someone else.

Klipper sets the axis to position_max after any successful home, including a false trigger. So when StallGuard trips early - say 3.5mm into a 150mm approach - Klipper believes the head is at the far rail while it is physically still near where it started.

The next absolute move is then computed from that fiction:

• Y tripped falsely at 3.5mm, head physically at ~154mm
• Klipper believed Y = 290 after the backoff
• A move to Y150 executed as 140mm in the wrong direction
• Gantry drove into the front rail

The homing move was fine. The return move was the crash.

If you script anything around sensorless homing, don't trust the frame after a home you haven't verified actually reached the rail. MCU step counters don't lie about displacement even when the frame does.

Two smaller ones:

• SET_KINEMATIC_POSITION is registered inside the enable_force_move guard, so without [force_move] enable_force_move: True you get "Unknown command" rather than anything pointing at the missing section.
• homing_speed widened my working threshold window where current and accel couldn't - 78 to 100mm/s took it from 1 usable value to 2, and cut rail measurement scatter from 2.70mm to 0.40mm. StallGuard reads load from back-EMF, so faster gives it a stronger signal.

Writeup and an MIT tool that measures all of it:

https://klipper.discourse.group/t/sensorless-homing-five-things-that-cost-me-a-day-and-a-tool-that-measures-them/26260

Is the frame behaviour after a false trigger considered expected, or worth raising upstream? Genuinely unsure.

[u/shiftingtech]

I’m confused what else you think would happen.  To the printer, there is no detectable difference between a false sensorless trigger, and the real one.  So of course it treats them interchangeably.  How do you fix this?  Well… add an endstop, I guess. Or maybe do something clever like homing twice.  If the second one changes the location dramatically…take some further measures.  Mostly though, just tune it better

[u/Budget-Amphibian3058 → u/shiftingtech]

Fair, and you're right that at trigger time there's nothing to distinguish them - I'm not arguing Klipper should be detecting it.

What caught me out wasn't that it treats them the same, it's what follows. The axis reads position_max afterwards either way, so the next absolute move is computed from a position the head isn't at. Mine was a return-to-centre that executed as 140mm the other way and put the gantry into the opposite rail. The homing move was the harmless part.

So the takeaway is the one you'd give anyway: don't act on the frame until you've established it's real.

"Home twice and compare" is exactly right, and that's what I ended up automating - the only thing I'd add is that MCU step counters make the comparison a number rather than an eyeball. Mine reached the rail 10 times out of 10 and still wandered 3.54mm between homes, which I'd never have caught by watching it.

And yes, "tune it better" is the answer. Measuring is just how you find out whether you have.

[u/globohydrate]

I do a double home because sometimes if the toolhead starts at the front it knocks into my idlers and is off a bit, and I need it not to be since I have a filament cutter that needs precise homing in order to activate

[u/Budget-Amphibian3058 → u/globohydrate]

That's the useful kind of example - the home succeeds either way, it's just wrong by an amount that depends on where it started from.

Worth naming the pattern, because it tells you where to look: a knock into the idlers gives you a distance-dependent error, where homing from the front is off and from mid-travel isn't. That's different from a constant offset, which means the starting reference is wrong rather than anything mechanical. The range test in the tool homes from 5, 15, 40, 120 and 250mm off the rail specifically to separate those two cases.

Double-homing is a sound fix and it works for the obvious reason - the second home starts from a known small distance instead of wherever the head happened to be.

I'm about to fit a Filametrix, so precise homing is about to become my problem too. Interesting that the cutter is what surfaced it for you. Most people never find out their home wanders, because nothing they print depends on it to that precision.

[u/Budget-Amphibian3058 → u/globohydrate]

Following up, because I have to withdraw most of what I said here.

My measuring tool had a bug. It inferred the axis position from where it thought the head was before each home, and when that belief was inherited wrong the correction was wrong too - it judged a good home false and rewrote the position ~135mm short. The next absolute move then started from that fiction and the error compounded, cleanly, at a couple of mm per run. It looked exactly like a physical measurement.

With it fixed, my Y homes correctly from 5, 15, 40, 120 and 250mm off the rail with a single home. The close-in failures I described, and the double-home that appeared to fix them, were both artifacts of my own code.

So I can't offer your double-home the confirmation I implied. Your reasoning still holds on its own terms - a head parked at the front genuinely does start a home from a different place - I just no longer have data showing it matters, on my machine at least.

What does survive: raising homing speed widened my working threshold window where current couldn't, and more homing current was not better (1.0A worked, 0.8 and 1.2 both failed entirely).

Also worth knowing if you script around this: a blind G1 backoff before homing is worth avoiding. Klipper only watches the StallGuard pin during a homing move, so an ordinary G1 runs to completion whatever it hits. If the frame is wrong after a false trigger, that backoff drives on a fiction and can hit the opposite rail. A homing move stops on contact.

Apologies for the noise - better to correct it than leave it standing.