Sensorless homing sensitivity changes during print.

[lyric violet]

Disclaimer, I am using Kalico.

Having an odd issue. Just redid a few bits on my v0, and now sensorless homing won't work. It will home successfully at startup, but after a print completes a re-home will fail with the message Early homing trigger on second home! However, fiddling around with my SGTHRS settings and adjusting the sensitivity downwards (as if i were calibrating it again) will eventually get me to a different value that will home correctly.

For example, I home with a value of 160 at startup, but after a print 110 might be effective. Of course, keeping that value of 110 will slam my toolhead around if I use it on a fresh start. Historically, 110 is closer to what I'd expect from this printer. (been using it for 2+ years)

I also tried to experiment with the home_current and homing speed and experienced this at all the values I tried.

I suspect one of a few things might be happening:

• Something in the stepper driver is misconfigured on startup, meaning my sensitivity is unusually high there.
• Something is changed in the stepper driver config is changed at the end of the print to change the needed sensitivity.
• My drivers have gone bad (both X/Y) on the SKR Pico
• My steppers are bad, somehow.

All of my configs are here: https://github.com/jelkand/v0-config
Klippy.log is attached. In that log I rolled it over, homed, did a small test print, failed to home, adjusted my x sensitivity, and homed x successfully.
I also dumped stepper configs and TMC data before and after a print.

[queen slate]

I'm loathe to skip over all your logs, but the first thing that I usually check when seeing this phenomenon is belt tension and mechanical health

[lyric violet]

If it's helpful, this is from shaketune.

[queen slate]

how is absolute tension?

[lyric violet]

2.2 lbs (measured with a pf makes tension meter)

(at least, i think it's lbs? units are not marked lol)

Belt paths are good. I do know that there is sort of a "resting spot" at 60,60 where it seems to settle a bit. I'm going to try parking it somewhere else and homing from there... but still, I don't understand why it would be fine before a print and not after, even if that point is an issue.

Just confirmed, it doesn't matter where it starts from on the second home.

[queen slate]

can you try upping your home_current slightly?

[lyric violet]

I've tried at multiple values from .49 to 1.0. Happy to try again and confirm.

Same issue occurs at 1.0 home_current

[lyric violet]

Ok, I ripped everything down to a "stock" config and it seems to not have this issue. So it's definitely something in how I've configured this! There is hope. I don't need to buy another SKR Pico.

wait... i lied. It worked on one gcode file but not another. also progress

[lyric violet]

It turns out it's a rogue g-code--SET_VELOCITY_LIMIT ACCEL=500 ACCEL_TO_DECEL=250 throws it off.

OrcaSlicer was emitting it. I'm guessing setting the accel lower than the defaults means the homing was actually happening under different parameters. It sounds plausible to me--if the home move is way slower to accel after a print, then it'll hit the stallguard prematurely?

[lyric violet]

Ah, it's my first layer accel-so the solution is not to not emit them, but to make sure they're reset in the print end macro.

[austere lagoon]

If you run Kalico you can add RESET_VELOCITY_LIMIT at PRINT_END

https://docs.kalico.gg/G-Codes.html#reset_velocity_limit