Marlin: [BUG] TMC2209 Sensorless homing sensitivity is off

[uorbe001]

Description

I have just configured a TMC2209 for my X axis, with UART. It seems to work alright, but setting up the sensorless homing is being a pain (I had it working with an TMC2130 earlier).

If I set the sensitivity to anything above 105 (M914 X105) and try to home the axis, it moves for about 1mm and then immediately stops. I'm assuming this is the stallguard triggering, since I haven't been able to get a read with M119. As soon as I change the sensitivity to anything bellow that (M914 X104) it just tries to home forever until I kill the machine. I have tried setting up floats for the value but it won't accept them, and I also tried switching it with another TMC2209 with exactly the same result.

Steps to Reproduce

Config.zip

Using TMC2209 and these stepper motors, on the bugfix-2.0.x branch:

1. M914 X105

2. G1 X1

3. M914 X104

4. G1 X1

Expected behavior: Stallguard triggers when it hits something.

Actual behavior: Stallguard triggers too early (moving 1mm and hitting nothing) with the 105 sensitivity, and too late (dangerously so) with 104.

I'd appreciate any help debugging this, as I suspect it's something specific to my stepper motor/driver combination rather than a general issue.

[RMN9]

Then i tried activate Sensorless homing, my X and Y motor do motion in wrong way. Sensitive was set 150. TMC2209 v1.2. by BTT DIAG pin was removed how told in manual.

[hackebike]

@uorbe001 I have sensorless homing and probing working (after few weeks of testing) with BTT TMC 2209 v1.2 on a SKR Pro. You are right the sensitivity value is a pain to find. Here is a video and the configs files in the description. Also I found that 2209 have not the same sensitivity and my guess depends on the quality of the silicon. So I suggest you to test more to find the right value, mine are X/Y 60 and Z 94.

@407s for sensorless homing there is no need to remove the pin

[RMN9]

no need to remove the pin

But...... my board SKR 1.3

[hackebike]

on the skr pro manual it states that you cut it if you want to use endstop switches, you keep it if you using sensorless homing/probing.

Also you mention that your motor go to the wrong way, for that you need to invert the motor direction in configuration.h

[RMN9]

Also you mention that your motor go to the wrong way, for that you need to invert the motor direction in configuration.h

Direction in conf - ok. They go in correct direction from display menu. Wrong way only for G28 command.

If you put the head and bed manually in the initial coordinates, then after G28 the two axes move exactly 1/2 of the maximum coordinates, then the head is parked in Z.
If i repeat from this position else one more time, axis again go in same direction and.... printer not reacting on any command from display menu. Stuck at maximum coordinates.

It's problem only if i activated Sensorless homing

Maybe printer think, what axis already in initial position... and they triggered....

[hackebike]

just an info, you can't have sensorless homing and endstop switches on those boards at the same time, or one or the other.
For the rest, I have no idea why is doing that.

[RMN9]

same time

Yes, i know. Then i activated function, mechanical switches was unpluged from board and installed special jumper in XST and YST slots.
Now i think my problem can be only in always triggered sensor (internal in driver) after #define Sensorless homing

[dch1921]

Then i tried activate Sensorless homing, my X and Y motor do motion in wrong way. Sensitive was set 150. TMC2209 v1.2. by BTT DIAG pin was removed how told in manual.

Sensorless homing will not work with the pin removed unless you add a jumper from the top of the driver from the DIAG to x_min signal and Y_min signal

[uorbe001]

I'm using a RAMPS 1.4 board, sorry I didn't specify this earlier. The drivers are also TMC2209 v1.2 by BTT, and I didn't cut any legs (I don't think this is needed on the ramps at all). The DIAG pin (or what is labeled as such) is connected to my x-min.

I've been doing some tests, and commenting out the IMPROVE_HOMING_RELIABILITY option changes the values completely (the magic number seems to be somewhere 168/169 with the same driver).

The issue is also a tad more complicated than I thought. It feels like what is happening is that with the higher sensitivity number, it stallguard triggers with literally nothing connected to the stepper driver as soon as it starts, and the lower sensitivity numbers never trigger. The problem is that around the "magic numbers" stallguard triggers as soon as the homing starts (without anything connected to the stepper, again) and then occasionally it will never trigger. It just seems impossible to find the correct number.

I tried about 150 "homings":

50 homings - 0 "never triggered", 50 triggered as soon as it started @ X_STALL_SENSITIVITY 170
50 homings - 3 "never triggered", 47 triggered as soon as it started @ X_STALL_SENSITIVITY 169
50 homings - 5 "never triggered", 45 triggered as soon as it started @ X_STALL_SENSITIVITY 168

I have no idea how to get further with this. I don't know if this is stallguard actually triggering, or it's a different thing, is there a way to tell when it's triggered? I tried with M119 but it's always open (as expected, I guess) and M122 is not helping. I'm starting to consider it may be a hardware issue with the drivers themselves, but I have no idea how to test that either.

[uorbe001]

I just got (and tried) a couple of watterott TMC2209's, and I'm getting the exact same result as I was with the BTT drivers. Everything else seems to work perfectly fine, but sensorless homing is either too sensitive or too little sensitive (with 1 value in between). I really would appreciate some help 👼

[Danielstc91]

Just adding in i have this exact issue. Mine is between 59 and 60. 60 and it will stop movement during travel, 59 never triggers and runs untill printer halted.
latest build of marlin 2.0. all libraries up to date. SKR v1.3, and BTT 2209s. Only homing on X and Y for me.

something to note however. State never triggers in M119 command. But removing jumper onboard (XST or YST, which disconnects diag pin to endstop switch) will result in M119 saying "Triggered", Jumper engaged, and continuously says "open"
No sensativity setting seems to change Triggered State in M119

[uorbe001]

@teemuatlut sorry to mention you directly here, but you seem to be the expert in the subject. I have a suspicious playing with values such as off time, blank time or hysteresis values might be the answer to solve this. Any chance you can confirm or deny these may affect the stallguard sensitivity?

[teemuatlut]

The sensitivity is affected by many things and so needs to be determined by trial and error, but I don't think the datasheet says anything about those three affecting the readout.

[dch1921]

In G28.cpp I raised the acceleration rate from 100 to 500 for homing which after lots of testing allowed me to run a higher sensitivity without the steppers tripping the endstops right away when starting to move. The higher sensitivity also produces a much softer hit on the axises. My assumption was the lower acceleration was causing a false stallgaurd detect when the axis first starts to move and the faster speed allows it to overcome the initial load it sees when it is starting from a stationary position. I'm using TMC 2209s on an SKR Pro

planner.settings.max_acceleration_mm_per_s2[X_AXIS] = 500; planner.settings.max_acceleration_mm_per_s2[Y_AXIS] = 500;

[hackebike]

@dch1921 sounds interesting, what kind of sensitivity value did you use?

[dch1921]

@dch1921 sounds interesting, what kind of sensitivity value did you use?

@hackebike 120 on both x and y running on a corexy setup. Previously I would have to go down to 70 before I changed the homing acceleration values

[hackebike]

I have it at 60 and 94 for z-probing, I will test with those G28.cpp changes as soon as I can.
thx

[uorbe001]

In G28.cpp I raised the acceleration rate from 100 to 500 for homing which after lots of testing allowed me to run a higher sensitivity without the steppers tripping the endstops right away when starting to move. The higher sensitivity also produces a much softer hit on the axises. My assumption was the lower acceleration was causing a false stallguard detect when the axis first starts to move and the faster speed allows it to overcome the initial load it sees when it is starting from a stationary position. I'm using TMC 2209s on an SKR Pro

planner.settings.max_acceleration_mm_per_s2[X_AXIS] = 500; >planner.settings.max_acceleration_mm_per_s2[Y_AXIS] = 500;

I just tried dch1921's suggestion, it doesn't seem to change anything other than the values where the issue happens.

The sensitivity is affected by many things and so needs to be determined by trial and error, but I don't think the datasheet says anything about those three affecting the readout.

Thank you for clarifying that. I have gone through the datasheet and haven't seen anything that'd point to that anyway.

I have been doing plenty more testing and I can definitely confirm that in my case, stallguard is consistently triggering when at the start of the homing for an axis there's something bumping on the carriage (provided the sensitivity value is high enough). So basically, it works when it's already homed. Ironically, that's not the point of sensorless homing :joy:

When the carriage is not homed at the time the sensorless homing starts, it'll simply keeps going until the printer is killed, or it errors with a failed homing error. I'm going to keep playing with the sensitivity value, homing feedrates and driver current to see if I can get it to work correctly, but so far it's being a pain.

[boelle]

who can confirm @uorbe001's issue?

[boelle]

will close this one as its most likely down to tune and machine setup
if anything at all the documentaion is behind

[uorbe001]

@boelle I appreciate that you want to keep the issues down, and this may be hard to reproduce, but I've shared as much info as I can and so far I've had very few suggestions as to what I might be able to try configuration-wise.

I've had sensorless homing working fine with other TMC drivers as I said above, and the only value that seems to be related (according to the config and docs) to this is not making a difference (going from too sensitive to too insensitive). I don't think closing this issue with a comment saying this is a setup issue is helpful to anyone.

I can definitely rule out a hardware issue with the drivers themselves (because I've tried 2 different brands) or connections with my tests. All the options I'm left with are that this is a firmware issue, or that this is a hardware incompatibility issue (as in my stepper motors not being compatible with stallguard on the TMC2209).

If it is the later, I think someone should be able to point out something about it (datasheets etc, but I've been throught them and found nothing) and at the very least we should have some record for other people that this might be an issue.

If it is, however, a firmware issue, this issue has merit and shouldn't be simply closed. There's either some obscure parameter/combination of options to make this work (in which case having it on an issue would be helpful to others) or an actual bug in the implementation. Either way, I don't think simply closing this is helpful whatsoever.

[uorbe001]

@boelle Thank you for reopening it. I'm about to close it again, but I will update for the benefit of others. I spent the last couple of hours trying multiple things, and it looks like I managed to find a fix for the issue.

Apparently, lowering the homing speed to fairly low values fixes the issue. I set my HOMING_FEEDRATE_XY to (30*60) and with that, I can set my stallguard sensitivity values at 100 and it seems to work perfectly (I haven't had a single false positive or false negative so far). Setting it to (45*60) goes back to the behaviour I reported here, where it's either too sensitive or too insensitive without anything reasonable in-between.

So basically, @boelle was correct in saying this was a setup issue, but to my knowledge, the homing speed affecting the sensorless homing isn't documented anywhere. I'll try to add something to the docs about it.

[bjoernwedi]

Note: when using 40*60 for homing feedrate, make sure you are stil lrunning in stealthchop mode.
If stealthchop is disabled or disabled by hybrid settings, it will not work.

[3D-Lasers-Lab]

I think I might have figured out why people are having issues with this. Bump sensitivity might be dependent on motor current. With bump sensitivity at 35 for TMC2130 stepper drivers I ran 100 tests with motor current at 800ma and 200ma without changing the bump sensitivity. It failed 20 tests on 800ma and failed 0 on 200ma. You can use "M906 X200 Y200" to drop your motor current to 200ma on the X and Y axis and then home, I am curious to see if other people can test this.

[Danielstc91]

I think I might have figured out why people are having issues with this. Bump sensitivity might be dependent on motor current. With bump sensitivity at 35 for TMC2130 stepper drivers I ran 100 tests with motor current at 800ma and 200ma without changing the bump sensitivity. It failed 20 tests on 800ma and failed 0 on 200ma. You can use "M906 X200 Y200" to drop your motor current to 200ma on the X and Y axis and then home, I am curious to see if other people can test this.

I am testing now. Currents set to half of what they were(400 now) and it will home now. However now i have an issue with it homing, changing direction and running to the other side(both X and Y) and running till it skips belts, Then changing direction again and homing successfully.
i am going to try even lower motor current to test.

[thinkyhead]

Indeed, your TMC motor currents must be tuned appropriately to your stepper motors or they can't get good readings. This procedure is not optional. See various YouTube videos on how to get the current well tuned with a multimeter. If using stealthChop it's important to have a well tuned chopper frequency as well.

[Danielstc91]

Confirmed on my end.
Dropped motor current. Disabled Quick home. and have a 1mm move away after home. Everything working as intended.

[drelich]

Thanks so much for this thread! I was pulling my hair because in more than half cases homing failed, which sent the toolhead outside the print area to do bed probing. Irritating.

Lowering the current before homing works perfectly for me! I updated my start gcode to drop it to 200, home, and then bring it back to normal mA (800 in my case). I also created a custom homing button in OctoPrint. 100% success rate since I've done that!

[github-actions[bot]]

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.