[BUG] Harsh X axis sensorless homing on TMC2209

[drewzh]

Description

Setup: Ender 3 Pro with SKR 1.3 and Bigtree TMC22209 in UART
Configs:
https://github.com/drewzh/Marlin/blob/bugfix-2.0.x/Marlin/Configuration.h
https://github.com/drewzh/Marlin/blob/bugfix-2.0.x/Marlin/Configuration_adv.h

When using SENSORLESS_HOMING with TMC2209 drivers. The X axis hits the endstop abruptly, whilst the Y endstop is very soft. This is only apparent when homing the X and Y axis at the same time, but when homing individually the issue disappears. I found that enabling CODEPENDENT_XY_HOMING and as a side effect, disabling QUICK_HOME, forces the axis to be homed in sequence rather at the same time, resulting in a perfectly quiet homing sequence.

On first glance (disregarding the sequential behaviour noted above) you'd assume this would be a sensitivity issue, but I've run through the entire range to try and narrow down a particular sensitivity setting that would resolve the issue... I didn't find that changing the sensitivity affected this behaviour.

Steps to Reproduce

1. Configure printer for sensorless homing
2. Issue a full auto home of X and Y axis with either G28 or G28 X Y
3. Note that Y axis homes softly as expected and X axis takes too long to register, resulting in a rough home.

Expected behavior: [What you expect to happen]

X axis should hit the endstop softly and register the stop immediately.

Actual behavior: [What actually happens]

X axis seems to not register the endstop immediately and results in a split second of grinding sound.

Additional Information

This is reported by not only myself, but another member of the "BIQU SKR Owners Group" over on Facebook:

https://www.facebook.com/groups/247860246136776/permalink/331864144403052/?comment_id=332138477708952&reply_comment_id=333026657620134&comment_tracking=%7B%22tn%22%3A%22R%22%7D

https://www.facebook.com/groups/247860246136776/permalink/331864144403052/?comment_id=332138477708952&reply_comment_id=333041497618650&comment_tracking=%7B%22tn%22%3A%22R%22%7D

[drewzh]

Here's a clearer video of the behaviour: https://photos.app.goo.gl/LBgrf79Hmc3Cm9Js7
Homing individually seems to stop the behaviour, i.e I can issue constant G28 X commands and not have a single instance of the grinding behaviour. As soon as I home X and Y together (for e.g, with G28 XY), I get the grinding issue (about 90% of the time).

[thinkyhead]

For the E3D Toolchanger (beta) we have —running RepRapFirmware— we had the same problem, and finally just gave up on combined homing of XY.

[drewzh]

With my latest compile I re-enabled quick homing to see if I could narrow it down using different configs, but no luck so far.

When I disabled quick home, there were still instances of the behaviour at other times (sorry I can't be more specific), so the issue isn't solved by homing in sequence, but it is masked in the usual pre-print G28.

I just hope someone be cleverer than myself can pin this down.

[TheNitek]

Does the behaviour change after powering the printer off and on again? Maybe this is related to #14464 ?
What is your endstop status after homing?

[drewzh]

@TheNitek the end stops are reporting fine and homing is otherwise running as expected. No change with powering the printer on and off. No other symptoms other than a harsh X home.

[TheNitek]

But what's the output of M119 after a "G28 XY"?

[boelle]

@drewzh is the issue still there?

[drewzh]

@boelle Yes, unfortunately so - I update to the latest bugfix branch almost every week in hopes that it's somehow magically solves, but alas... still the same :(

Just yesterday I gave up all hope and reinstalled my endstops.

The sensorless homing works - but it's rough as hell. The only way to really make it semi-work is to force the homing of X and Y one at a time. Even then, it still happens randomly. I also noticed that homing a single axis, also makes the opposite axis 'twitch' after being homed - not sure if this is expected or a previously seen behaviour?

[boelle]

i will let it stay here then, i dont use sensorless homing so i cant confirm it

[coreflake1]

i'm having the same issue with TMC 2209.
with CODEPENDENT_XY_HOMING enabled and QUICK_HOME disabled it has improved but the harsh homing on X-axis is still there.

[drewzh]

i'm having the same issue with TMC 2209.
with CODEPENDENT_XY_HOMING enabled and QUICK_HOME disabled it has improved but the harsh homing on X-axis is still there.

I'll keep the screwdriver at the ready for removing my endstops whenever someone clever fixes this. I'm really surprised given how popular the TMC2209's are, that nobody with domain knowledge has tackled this.

[boelle]

@drewzh still the same ? :-(

[drewzh]

@drewzh still the same ? :-(

No update from me. I don't plan to switch back to sensorless until I see any sort of update.

[boelle]

well there are many updates applied every day/week and you will need to watch the commits to figure out if any update might have fixed the problem

marlin is not a company and we all work for free

[drewzh]

well there are many updates applied every day/week and you will need to watch the commits to figure out if any update might have fixed the problem

marlin is not a company and we all work for free

I never said or assumed you're a company and work for profit? But I won't be testing sensorless homing on the 2209's again unless someone hints that it's actually been fixed. I've personally given up on them for now - I've already burnt many hours testing new dev builds over the course of a few months and I just don't have the time anymore. This will have to be championed by someone else.

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.

[damienmg]

I don't think this has lacked activity. More like request to look at that.

I'll update Marlin to head tonight and retry but for now I am running with quick_home disabled. This is not a big deal for me as it won't save that much time.

[boelle]

oki, if you have the same issue we can reopen and even slam the confirmed label on it

[damienmg]

Sorry took me longer to test as the rebase wasn't as smooth as I expected. Anyway this is still happening so I would like to see this issue reopened.

If you'd like me to diagnose further, just tell me what I can test, I have no idea where to start.

[AlexanderAmelkin]

@bthome, @CSHoffie, can you guys check with an oscilloscope or multimeter that the DIAG pin of your TMC2209 on the griding axis is not asserted when the caret hits the limit? That's the case for me.

[sadiwali]

I'm running the SKR1.4 Turbo + TMC2209 V1.2 on the latest Marlin bugfix 2.0.x, and having the same issue. If X homes before Y, then X grinds, and vice versa. Individually homing the axes solves this at the cost of homing speed.

I haven't had a chance to do enough troubleshooting but I wonder if increasing the "recheck distance" (the distance the bed/extruder moves away from the extruder then towards it to check the end stop the second time) would help.

[sadiwali]

I seem to have solved the issue by increasing the HOMING_BUMP_MM and enabling SENSORLESS_BACKOFF_MM as follows:

#define SENSORLESS_BACKOFF_MM  { 5, 5 }
#define HOMING_BUMP_MM      { 15, 15, 2 }

EDIT:

I've lowered these values, and they seem to be working fine.

#define SENSORLESS_BACKOFF_MM  { 2, 2 }
#define HOMING_BUMP_MM      { 10, 10, 2 }

[joeb15]

The main culprit for me was making sure that
#define IMPROVE_HOMING_RELIABILITY was commented out.
The combination of IMPROVE_HOMING_RELIABILITYwith the TMC2209s seems to have been what results in harsh homing. When paired with the solution proposed by @sadiwali, homing is as silent and soft as it has ever been.

[occ]

I hit this issue while setting up my new SKR 1.4 Turbo with TMC2209s using the bugfix branch at 10601a9.

In short - the root cause seems to be IMPROVE_HOMING_RELIABILITY. As long as I have the option disabled, it seems to work fine.

A few notes from my tests:

• Enabling/disabling QUICK_HOME doesn't seem to matter.
• Homing Y before X doesn't seem to matter.
• Reducing SENSORLESS_BACKOFF_MM from { 5, 5 } to { 2, 2 } doesn't break homing.
• HOMING_BUMP_MM at { 10, 10, 2 } is quieter than { 5, 5, 2 }. With 5mm, it sounds like hotend hits the frame faster. Overall, it doesn't seem to matter to homing.

What's interesting is that, when I enable IMPROVE_HOMING_RELIABILITY, the thresholds seem to change. Without the feature, M914 X100 Y128 seems to work really well. With the feature enabled, same settings make homing too sensitive. Hotend moves a mm or so and stops. It also seems like the threshold becomes impossible to get right. M914 X55 stops without reaching the end of the rail, whereas M914 X54 hits and grinds at the end of the rail for ~4 seconds.

I'll try to debug the IMPROVE_HOMING_RELIABILITY feature later and post updates.

[boelle]

@drewzh
Please test the bugfix-2.0.x branch to see where it stands.

[drewzh]

@boelle Will check this out today 👍

[drewzh]

A few things got in the way :) I've just re-flashed with latest bugfix-2.0.x today and checked that IMPROVE_HOMING_RELIABILITY is switched off. Things seem to be much smoother now - though I haven't checked whether IMPROVE_HOMING_RELIABILITY actually changed the behaviour, but after this current print is finished I'll re-enable and give it another check.

[drewzh]

Just testing again today and IMPROVE_HOMING_RELIABILITY doesn't seem to make much difference (except for slowing the bump process down slightly - assuming to make it more accurate). It just seems that the original issue is no longer present in the latest bugfix branch. Completely off topic (kind of), but the X axis now homes 3 times, twice as normal and then after the second home, a bigger back off and a 3rd home is performed. Y axis still homes twice as expected - is that normal?

[sjasonsmith]

I do not know if this is related, but it is possible that sensorless homing issues may be caused by TMCStepper 0.7.0. If your builds are using this version, please update them to 0.7.1 and re-test.
#18563

[drewzh]

Interesting - I just checked my platformio libdeps and TMCStepper is at 0.7.1...I wonder if the update to bugfix was just a red herring and it's actually this library that's fixed it? I'd have to go back and test again, but I'm currently running a very long print.

[teemuatlut]

The bugged release was live for about a week and affected only the SW Serial use.

[drewzh]

Ah, that wouldn't be the issue here then, this has been an issue for over a year.

[AnHardt]

I guess this problem is related to
The impossibility of safe automatic sensorless homing.
Especially the 'Additional difficulties with Quick- and DELTA- Homing.' chapter.

[AnHardt]

I guess what is happening here is - in short:
Before STALGUARD can detect an axes end reliably, without grinding, it has to move SOME_WAY before.
QuickHome begins with a diagonal move to where the endstops are. If that diagonal hits the corner nearly perfect always one endstop hits first and the move stops. Now homing the individual axes begins. The already hit axis can't move forward and backs up to make the second try - what works. For the other axis, where the endstop was not already triggered a first move is initialized, what will grind because the possible way to move was smaller then SOME_WAY.
After homing both axes are backed up a bit, by the same amount, to avoid grinding. So the end position is warranted to be near the diagonal to the corner. Subsequent quick homing is warranted to grind.

A way to fix could be, to back up both axes (that with the not hit endstop could de enough (if easy detectable)) at least SOME_WAY after the diagonal move and before the homing of the individual axes.

The workaround is to disable QuickHome.

---

If the above is true, DELTAs have the same problem when the start-position is with all carriages at the same (+-SOME_WAY) height.

[AnHardt]

A quick test for the theory would be to configure HOMING_BUMP_MM asymmetric for x and y by + SENSORLESS_BACKOFF_MM of that axis. (For example { 5, 7, 2 }) Then try quick homing several times.
Is that still grinding on a system what does not grind when the axes are homed individually?

[whitewytch]

Disabling QUICK_HOME is definitely a solution... but this problem has been around for a while and not necessarily associated with TMC and sensorless homing.
I encountered it on my hypercube running Marlin 1.1.8 on a MKR Gen L v1.0 with DRV8825 drivers... the X axis endstop appeared to be disabled and the print head attempted to bury itself in the Y axis carriage, where it juddered until it timed out.
If the head was in a position after a print such that Y endstop was encountered first there was no problem.
Disabling QUICK_HOME solved the problem and it mattered not, which Axis homed first.
I have this sneaky feeling that there is something nasty lurking in the endstops.cpp code that is disabling the X endstop, when QUICK_HOME is in effect, and whilst I took a look through the code it quickly exceeded my capabilities in C++ and my will to live.

[sjasonsmith]

@fungustoe if QUICK_HOME were that fundamentally broken more of us would be crashing our printers all the time. Bugs that may have existed in 1.1.8 aren't really relevant anymore.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[AlexanderAmelkin]

I don't currently use my delta, and my current printer has A4988 steppers, so I can't check. There's been a number of commits, it seems, that tried to address this problem. Could anyone check and report?

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[jatson]

I was facing the same exact issue on SKR Mini E3 V2.0
Actually tried all the things here, but not helped. But I think I found the solution, at least for my case.

Since the board equipped with EEPROM, Marlin has stored the sensitivity data (in my case 0) and whenever I was uploading a new software, used the EEPROM stored value. I did not recognize it badly so I had a few hours in this.

If you wanna get rid of this problem, give out the following commands:
M502 --> resetting the values to the hardcoded params
M500 --> store it

[drewzh]

I was facing the same exact issue on SKR Mini E3 V2.0
Actually tried all the things here, but not helped. But I think I found the solution, at least for my case.

Since the board equipped with EEPROM, Marlin has stored the sensitivity data (in my case 0) and whenever I was uploading a new software, used the EEPROM stored value. I did not recognize it badly so I had a few hours in this.

If you wanna get rid of this problem, give out the following commands:
M502 --> resetting the values to the hardcoded params
M500 --> store it

Thanks for your suggestion but this isn't related. Resetting EEPROM should be standard practise after flashing a new firmware. This issue as far as I'm aware has been resolved already.

[tjburbridge]

So, I just read through this, as I updated the code a couple days back, and first day it was working. Second day, with no changes, it started doing the "grinding" sound on X axis when homing X and Y together. Separately they were fine. Even increased the sensitivity on the X until it was false triggering.

I remember looking at the changes in Git from my previous code to current, and seeing a line change in 'configuration.h':
// Homing speeds (mm/min)
#define HOMING_FEEDRATE_XY (20 * 60)
Changed to:
#define HOMING_FEEDRATE_XY (50 * 60)

I remember thinking, cool, faster XY homing. Well I just replaced the speed back to 20 * 60, and not only did it fix the problem, but I was also able to significantly drop the TMC Bump Sensitivity value (X & Y from 65 back to 25). Was wondering why the last code made me increase this value so much.

So my guess is that with true endstops, the faster speed is okay, however with Sensorless, it causes either noise that blocks the bump, or less power at the faster speed, so the bump doesn't register? Not familiar enough with the code and electronics to say for certain.

Hope this can help someone else.

[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.