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

[coreflake1]

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.

Same behavior is still happening to me as well with TMC2209 and quick home enabled.
I also have the same comment as damienmg : If you'd like me to diagnose further, just tell me what I can test, I have no idea where to start.

[ghost]

Similiar behaviour regarding the grinding against the frame with TMC2130 as described in #15822. Main differences are:

• with QUICK_HOME no homing at all, grinding continues until printer is killed or decides to kill itself due to non succesfull homing

• with it disabled homing works perfectly

I'm not sure, could this be related to the same underlying issue?

[boelle]

@drewzh since 2.0 was just released a few days ago has this changed this issue at all?

[drewzh]

@drewzh since 2.0 was just released a few days ago has this changed this issue at all?

I'm going to test one more time with the latest 2.0 release. I'll also hardwire the DIAG pin to the endstop on the axis that's causing issues - maybe it's an SKR trace issue on the board.

[drewzh]

So here we go again... latest everything, still exact same issue. Swapped endstops around, no change in behaviour. Also tried bridging the drivers directly to the endstops without the internal SKR wiring. Both axis are able to sensorless home individually no problem. As soon as you home both together, Y hits first, no issue, X then hits... no issue and then for some reason the Y axis lets out a final grinding sound. It's consistent and the sensorless threshold values have been thoroughly checked and are very sane (i.e, I've gone from too sensitive slowly down to 'just enough'.

https://photos.app.goo.gl/nYX2G47CGEHTsWgz5

[boelle]

yeah, the very last bit is not right

@teemuatlut @sjasonsmith @shitcreek

thoughts?

[drewzh]

Actually the following video shows what's going on somewhat more clearly as when both axis are at the same offset and everything fires off at once, it's difficult to figure out what the culprit is...

In the video it shows me issuing a G28 Y command to home the Y axis individually (which works as expected)

THEN I issue a G28 command to home all axis. You'll hear the Y endstop trigger immediately as it's already at the endstop (It took me a second to turn the camera so you miss that visually), the X axis then continues to home, which again works fine... THEN once the X axis has homed successfully, the Y axis then lets out a final movement which results in grinding.

I think It's more apparent when the Y axis is already at the end. It seems the Y axis homes, followed by the X and then for some reason, the Y does this strange unexpected behaviour.

I noticed this Y movement before as well, when I did independent homing to work around the issue. The Y axis would always let out a final subtle movement, even though it had already homed.

Hope this helps.

https://photos.app.goo.gl/tneLguWYVej4HDSw7

[drewzh]

Another close up of the Y axis trying to move after both axis have homed: https://photos.app.goo.gl/vBmpvVUt511nXLFk8

[boelle]

and nothing is stuck?
and with none of the endstops activated they show as open when sending M119?

and when you touch them with finger (one at a time) M119 says triggered?

it looks VERY odd

[Grogyan]

Try increasing the back off distance, as the video shows that it is doing a double home, for some reason.

[drewzh]

My axis are perfectly aligned and clear of obstructions - the printer is otherwise perfectly setup. Like I said, homing each axis individually works perfectly fine

[drewzh]

I'll have to continue testing again tomorrow. I'll try increasing the back off distance. What do you think would be a conservative value?

[Grogyan]

But your video shows it is doing a second home, or move below the 0,0

Backing off of about 2-3mm should be fine, to enable the TMC2209 to properly detect on stall guard. But it shouldn't be necessary

[drewzh]

I convinced my other half to let me pause the movie and go check again after adding a backoff value. Will report back soon.

[drewzh]

So, no change. The only difference now is that after homing, the axis moves back and forth twice. I.e, it hits, moves back, then moves forward again.

https://photos.app.goo.gl/JWux1Za2FSi5cqtXA

For reference, here's my entire Marlin configuration. Based against latest master 2.0.x.

https://github.com/drewzh/Marlin

[boelle]

just a wild shot, but could it be related to the stealthchop not being enabled at homing issue?

https://github.com/MarlinFirmware/Marlin/issues/16091
https://github.com/MarlinFirmware/Marlin/pull/16153

[drewzh]

I'll either wait for that PR to get merged in, or I'll maybe just create an ad-hoc build based on it.

Either way, now that I have the endstops removed again - I'll keep testing suggested fixes. In the meantime, the homing results are correct enough that I can continue printing with sensorless homing enabled.

[SBachman]

I would like to add that I have this same issue on my Ender 3 Pro with the SKR mini 1.2. It's good to know that I can just home x and y individually for the time being.

On my FW I have hybrid turned off so it only uses Stealthchop. My issue is the exact same. It's worse when it's already homed (double home) but I haven't been able to disable double home.

[drewzh]

I've tried recently:

• turning hybrid threshold on and off
• adding and removing bump
• adding and removing back off
• lowering homing speeds

no difference.

The only significant change It seems is disabling quick_home so that each exis homes individually. This is where I'll leave it for the time being. Open to suggestions though.

I'm not going to merge https://github.com/MarlinFirmware/Marlin/pull/16153 because this only enables stealthchop before homing - I currently have stealthchop permenantly enabled anyway.

[drewzh]

No update to give again. I have quick home disabled currently and this works around the issue about 75% of the time. It still proves to be an issue when both axis are already very close to the endstops (and thus they home rapidly in quick succession).

[eschmidt12]

Same problem for me on an Ender 5 Pro, SKR 1.4 Turbo and TMC2209s. It homes perfectly when homing each axis independently. It does seem like it grinds after it has done the initial home and goes to verify the home.

[boelle]

and doing M502 then M500 after flashing does not change anything?

remember settings are also stored in eeprom and those setting come before those in firmware

[eschmidt12]

No it doesn’t unfortunately. I’ve tried setting the sensitivity both in the firmware and through M914 commands, and still the same behavior. I know the M914 commands work, as I can get the steppers to stall during normal travel with a very low sensitivity values, and to continuously grind against the end stops with very high sensitivity values. Once I get it dialed in to where it more or less acts as I’d expect (especially when homing x and y independently), it still grinds briefly when it verifies home.

[drewzh]

@boelle Definitely not an EEPROM thing, nor is it a sensitivity setting issues. This has been checked and proven many times by myself. Re #16153 - I'll give this a test today 👍

[drewzh]

Tested latest bugfix-2.0.x branch and updated all deps - still same issue.

[drewzh]

I even purchased 5x TMC2209 1.2 revisions, just to see if the issue was stepper hardware related. To my dismay, I re-enabled quick homing and again, the issue still remains :(

[drewzh]

I think I'm going to try and install Klipper and see if they're able to home correctly. I don't know what else to try.

[boelle]

:-( and i'm not a coder or maintainer, just the janitor sweeping the floor

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?
btw remember that sensorless homing has about 0.3m deviation
its far from mature enough compared to a normal endstop

[drewzh]

I stay up to date usually, updating my firmware mostly every week. Now that I have the endstops removed, I'm monitoring all the time. No update to give with the latest Marlin 2.0.x. Issue still remains.

[crm552]

I can also confirm that this issue remains. After 2 failed SKR 1.4 Turbo trials (due to a dead board on one, marlin install issues on the other) I moved to a SKR 1.3 with BTT 2209s. This issue presents just as previously described, grinding at the end of homing as it appears to try and move an extra inch past the point it starts skipping. If axis is already homed, it will still make grinding noises for a few seconds as it still seems like it tries to move an inch as the minimum distance when homing.

[stantond]

Also seeing this issue with SKR 1.4 + 2209, G28 X works as expected, G28 gives the behaviour described in this issue,

[eschmidt12]

Also seeing this issue with SKR 1.4 + 2209, G28 X works as expected, G28 gives the behaviour described in this issue,

That’s exactly what I see. Homing each axis independently works fine but G28 does not

[thinkyhead]

There are some pause and backoff settings that make sensorless homing work better. Let me dig around in the configs and see what they are called………

[drewzh]

I've tried pretty much every homing related bump and backoff setting already. This seems like a logic or hardware issue.

[thinkyhead]

disabling quick_home so that each exis homes individually

That is the recommended workaround at this time. But a long pause in the right place could do the trick, or an extra back-off before re-homing, or both. The only problem with backing off is that if you start with one axis already homed and the other at the end, then the back-off on the first quick-home will cause the axis at end to grind against the frame. So the back-off needs to be pretty small.

Try #16872 and see if it helps. If not, try tuning the back-off and the delay in the added lines.

[AlexanderAmelkin]

I'm observing a very similar behavior on SKR Pro v1.1 with TMC2209 on a DELTA setup. I've been having some DIAG pin connection issues on tower Z stepper, but even with that fixed, tower Z homing is a lot more harsh than that of X and Y towers, tower X being the softest.

As you understand, disabling quick homing is not a suitable workaround for a delta, as all towers must home simultaneously or the whole setup will just get stuck or broken.

So far I ended up with re-adding endstop swtiches, but that was a big disappointment.

One thing I observed thanks to endstop leds on SKR Pro v1.1 is that when that harsh homing happens, the endstop led for the tower doesn't light up. When it finally lights up, the tower stops grinding. Looks like there is something wrong with the TMC2209 setup.

[CSHoffie]

Confirming this is an issue for me as well. G28 and X grinds (Y does not), G28 X = No grind. In either case, Y does not grind for me.

Ender 3 Pro SKR 1.4 Turbo w/ TMC2209
Latest bug fix Marlin 2.0

[bthome]

I may have something similar. Using auto home, X homes using sensorless homing, Y homes using sensorless homing, as it proceeds to the bed center to home Z it grinds and never makes it to center.

If I manually move to each 0 via gcode it is fine so nothing mechanical seems to be a problem.

Recommendations?

Hictop prusa clone
SKR 1.4 Turbo + TMC2209

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

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.
https://github.com/MarlinFirmware/Marlin/issues/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[bot]]

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[bot]]

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.