Can anybody helpme
I install Klipper Mainline latest version but i get
stepper_x:TRIGGERED stepper_y:TRIGGERED stepper_z:open
at soon as machine start.
later a simply g28 does not work.
Someone (probably following a Sovol guide) hand-copied Sovol's custom `extras/` modules
straight into a mainline Klipper checkout instead of installing them as a proper out-of-tree
component. That's why it's flagged `-dirty` — `git pull` will now either silently blow away those
files on the next update or refuse to fast-forward.
**2. Two macros are erroring on every single boot, unrelated to homing:**
- `[delayed_gcode bed_mesh_init]` unconditionally runs `BED_MESH_PROFILE LOAD=default` 0.01s after start with no existence check → `bed_mesh: Unknown profile [default]` because no mesh has ever been saved on this fresh setup.
- `[delayed_gcode TEST_BELT]` reads `printer.save_variables.variables.x_freq` (and `y_freq`) to display input-shaper results, but those saved variables were never created either → `jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'x_freq'`.
Both are symptomatic of the same thing: Sovol's stock macros assume a machine that's already been through calibration (mesh saved, belt resonance test run), and this one hasn't been. Neither one crashes Klippy or blocks homing — but it tells you the config was never actually walked through its own setup sequence, which is exactly the "deeper problems" smell.
## Why "TRIGGERED / TRIGGERED / open" isn't actually the bug
Look at the endstop config:
X/Y aren't physical switches — they're TMC2209 StallGuard virtual endstops. The `diag_pin` state Klipper reports for QUERY_ENDSTOPS on a sensorless axis is meaningless noise until a homing move is actually underway; it commonly reads TRIGGERED at idle and that's normal, not a fault. `stepper_z:open` is also exactly what you want at idle — the probe isn't in contact with the bed. So the status line in the post is a red herring, not the root cause.
## What's actually needed to find the real G28 fault
This log doesn't contain the failure, so:
1. Reproduce it and grab a *fresh* `klippy.log` immediately after — don't reuse an old one. Moonraker rotates logs, so pull the newest.
2. Run `STEPPER_BUZZ STEPPER=stepper_x` and `STEPPER_BUZZ STEPPER=stepper_y` before ever calling G28 — confirms motor + UART + driver are alive independent of homing logic.
3. Then try `G28 X` alone and read the console message verbatim:
- **"Endstop x still triggered after retract!"** → diag pin never releases: check the diag wire/connector, the `!PE15` polarity, or `driver_sgthrs=73` being too sensitive (false-triggers from normal current ripple).
- **Times out with no trigger at all / crashes into the frame** → `sgthrs` too high (not sensitive enough) or `run_current=1.4` too low for reliable stall detection on that motor/belt.
4. Do the same for Y (`sgthrs=75`) — asymmetric X/Y thresholds like this are always tuned empirically per printer, so don't assume the value itself is wrong without testing.
## Recommended cleanup order
1. Fix the two live errors first, since they're 30-second fixes and clear noise out of the log:
- Guard `bed_mesh_init`: `{% if 'default' in printer.bed_mesh.profiles %}BED_MESH_PROFILE LOAD=default{% endif %}`
- Guard `TEST_BELT` the same way around the `save_variables.variables` lookups, or just run the belt resonance test once to populate them.
**2. Decide once and for all: full stock Klipper mainline with Sovol's macros ported in cleanly,
or Sovol's actual maintained fork. Stop hand-copying loose `.py` files into a dirty mainline
checkout — that's the thing most likely to bite them again on the next update.**
3. Only then chase the sensorless-homing tuning (current/sgthrs/wiring) with the STEPPER_BUZZ + isolated G28 X/Y steps above — trying to tune StallGuard on top of an unstable install order just wastes time re-diagnosing the same symptoms.