[BUG] SENSORLESS QUICK_HOME on SKR 1.4 with TMC2209 sometimes move to wrong direction

[yarda]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Marlin 2.1.2.7, SKR 1.4 with TMC2209 in UART mode, SENSORLESS_HOMING enabled. If QUICK_HOME is enabled, sometimes one axis (mostly the Y axis) starts homing to the wrong direction and didn't stop when reached the HW limit. It happens in cca. 1 from 5 cases, IMHO most probably after power on. If QUICK_HOME is disabled, everything works as expected.

Bug Timeline

Expected behavior

I expect it to home to X min / Y min everytime as it does if QUICK_HOME is disabled and that the motor stops when the HW limit is reached.

Actual behavior

If QUICK_HOME is enabled sometimes one axis (mostly the Y axis) starts homing to the max (Y max) and didn't stop when the HW limit is reached.

Steps to Reproduce

1. Enable SENSORLESS_HOMING and QUICK_HOME on SKR 1.4 with TMC2209
2. Repeatedly do homing, at the best with some power off/on cycles in between

Version of Marlin Firmware

bugfix-2.1.x (20260427)

Printer model

LulzBot TAZ 6

Electronics

SKR 1.4 with TMC2209 in UART mode

LCD/Controller

REPRAP DISCOUNT FULL GRAPHIC SMART CONTROLLER

Other add-ons

Magnetic Z-probe

Bed Leveling

ABL Linear grid

Your Slicer

Prusa Slicer

Host Software

Pronterface

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

config.zip

[yarda]

I am not sure whether it's a HW or SW problem, but I rather reported it. It seems there are multiple people affected by it - there are several posts and videos with the same problem and the working workaround is to disable the QUICK_HOME.

[narno2202]

The velocity is higher with QUICK_HOME than with standard homing. As sensorless homing is sensitive to velocity, the higher speed can cause the issue. Try X and Y homing feedrate equals 33*60 (QUICK_HOME speed is near 3000).

[yarda]

It could be it, because during the print it moves diagonally and so far no problem spotted during the print. I will try it during the next week when I get to the printer (it's office printer).

[yarda]

The velocity is higher with QUICK_HOME than with standard homing. As sensorless homing is sensitive to velocity, the higher speed can cause the issue. Try X and Y homing feedrate equals 33*60 (QUICK_HOME speed is near 3000).

It seems it's better, at least it seems it's going the right direction now. But the endstops misbahave. I.e. when the one stop triggers it thinks that both stops triggered, which means that the (0, 0) point is totally random on the bed :)

[narno2202]

Sensorless homing is tricky as it's a mix of speed, acceleration, and current to find the good sensitivity threshold. On my printer to have a fully working sensorless homing with standard motion, FT_MOTION and quick_home, the only thing that does the trick is lowering the homing current.

[yarda]

Thanks for the info, I will play with it.

So probably there is nothing to fix in the Marlin code, but IMHO these problems and possible solutions could be mentioned in the Marlin configuration comments.