[FR] SENSORLESS_HOMING needs delay for HOMING_BACKOFF on CoreXY

[rado79]

Description

HOMING_BACKOFF does not work with SENSORLESS_HOMING as expected on CoreXY. It makes sense for me to do a HOMING_BACKOFF to loosen the thightend belts after SENSORLESS_HOMING is done.

Current procedure:
Do a G28 with SENSORLESS_HOMING and HOMING_BACKOFF enabled.

1. X axis moves in home direction, get stopped by SENSORLESS_HOMING at end
2. Now there is the HOMING_BACKOFF X move. Meanwhile the Y axis starts to move in home direction wich triggers SENSORLESS_HOMING Y instantly.
3. does HOMING_BACKOFF Y move
4. Homing ends at wrong position (X at home + backoff, Y anywhere + backoff)

Not always:
Lowering HOMING_BACKOFF_MM to 1 - the default delay is enough to BACKOFF and after that start homing other axis. Every BACKOFF more than 1mm conflicts with other axis homing move.

Should have more (maybe customizable) delay between homing moves.

[ogsv]

Confirmed, I'm having the exact same issue on my CoreXY. Deactivating HOMING_BACKOFF restores homing. For now I have to home each axis separately in start gcode; G28 X, G28 Y, G28 Z.

[KAY3D]

does this only affecting when you set homing back off in X and Y? Was your set up working in 2.0.4.4?

[Geitde]

Same here on my CoreXY. It took a while to figure it out. I should have looked into the bugtracker a few days earlier.

The Y axis gets homed first and backs off 10mm. Then I home X and in 3 of 5 tries it instantly triggers the tmc sensor endstop and backs off. I could decrease x sensitivity quite alot, but that would just cause more bumpy and painful positioning with less accuracy. In my case it wasn´t a solution, as I need precision for the tool changer docking positions.

It does not matter if X or Y is homed first.

My printer is quite big in size 500x500x500 with SKR Pro V1.1/TMC2209s and I guess this happens to the rapid stop and/or the slack of the belts or even the whacky stand it is on during finishing state. The core xy design in general connects both steppers by the print head, so it is likely that it cause the false positive. The requirement of the options to back off and home x and y separately is just another example that sensorless homing needs more care in this department.

My solution: Adding a 500ms delay between X and Y homing and since then did over 100 homings without a single false positive! Just setting sensitivity to 100 for x and y, the homing is as soft as it could be.

So in the end I consider this as a prove that the sensor is picking up vibrations of the prior movement over the physical connection of x and y by the print head.

At the end I join the club of wanting this feature request to happen. It is such a small fix and a 500ms or even a complete second delay is nothing compared to the premise of breaking the tool changer or supervising every homing procedure.

PS. Keep up the great work. Thanks to all the developers involved.

[Skater2k2]

I have the exact same problem here with my corexy machine. There is a 50/50 chance G28 home x and then y.
Can you tell me please how to set up the delay?

[Geitde]

Sure.

Open up Marlin/src/gcode/calibrate/G28.cpp

If you have "#define HOME_Y_BEFORE_X" enabled in Configuration_adv.h go to the "// Home X" section. It should be around line 355 and add the safe_delay function call as shown below.

safe_delay(500); /* this delay line fixes homing */
// Home X

if you don´t have "#define HOME_Y_BEFORE_X" enabled go to the "// Home Y (after X)" section around line 383 and add the safe_delay function call as shown below.

safe_delay(500); /* this delay line fixes homing */
// Home Y (after X)

If you are unsure just add both delay calls before the mentioned "// Home..." comment lines. The only side effect will be that homing will take 500ms longer.

[Skater2k2]

This worked pretty well, thank you!

I had to set the delay to 1000ms to get it working flawless. Btw after x homing and backoff the printhead dont pause 1s, its much shorter.

[rado79]

solved, works since #17273

[Geitde]

The new option to enable IMPROVE_HOMING_RELIABILITY only works with 2130 drivers.

I just thought I give it a try, it compiled without an error but the firmware did not home at all. After a little research I noticed that SPI_ENDSTOPS need to be enabled, which is an 2130 only beta feature.

Would have been nice if the compile would fail to tell me that.

So with my TMC2209 I have stick with my solution above and add a delay by hand into the homing process.

[thisiskeithb]

The new option to enable IMPROVE_HOMING_RELIABILITY only works with 2130 drivers.

This feature works with drivers that use StallGuard and isn't exclusive to TMC2130s, nor SPI_ENDSTOPS.

I use it with TMC2209s & TMC5160s.

[Geitde]

But how? When I enable IMPROVE_HOMING_RELIABILITY homing fails, while without and with my delay calls applied it works every time. It is just off by a millimeter sometimes, which is the reason I wanted to try this option in the first place.

[thisiskeithb]

It may not work for your particular build, but it's not universally true that "IMPROVE_HOMING_RELIABILITY only works with 2130 drivers." since it can work with other TMC drivers as long as they are StallGuard capable.

For best results getting help with configuration and troubleshooting, please use the following resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

[Geitde]

I assumed the reason it did not work was the TMC2209, got triggered by the code. I searched for the IMPROVE_HOMING_RELIABILITY and the first IF was disarmed by a second IF that enforced SPI_ENSTOPS to be present. After searching for SPI_ENSTOPS I found the disabled define with a comment that this only works with TMC2130. So I stopped investigating.

I would rather polish my own tool changer implementation and hacking in my menus for that into marlin rather than wasting my time with that.

For now my added delay for backlash compensation works good enough.

But if I enable a function that should improve something, caused it to completely fail? I consider that a bug or at least a lack of code documentation to point out what else is needed to not ram the tool head into a wall.

I for sure need no help or basic tutorials on how to configure marlin. I sat for years head deep inside the spaghetti code marlin provides to fit into 8 bit stuff.

Update: It seems when enabling the improvement feature I have to half the sensitivity, which is about 50. The window between hit and miss is kind of small here, too. +/-6. The total accuracy enhancement is here next to nothing. It still is randomly off. I wonder if that is the stepper resolution settings fault.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.