[BUG] Sensorless homing on a COREXY with SKR1.3/TMC2130 failed

[wolfgangmauer]

G28 moves X to X-Home position, Y only moves about ~1 mm and then stops at wrong position
Even with lower/higher values on _STALL_SENSITIVITY and _HOME_BUMP_MM=0 don't work

Workaround:
G28 X
G28 Y
G28 Z

Works fine, but cannot be executed with the LCD
Marlin.zip

PS.
On enable QUICK_HOME G28 works like expected!

[AnHardt]

#define INDIVIDUAL_AXIS_HOMING_MENU

[boelle]

@wolfgangmauer is this still an issue?

[wolfgangmauer]

Yes, there are „Workarounds“ but the normal G28 don’t work. (EDIT: removed email headers)

[boelle]

@wolfgangmauer and the tip from @AnHardt did not help either?

do you use 2.0.1 or bugfix 2.0.x ?

[wolfgangmauer]

I use 2.0.1, but was the same behavior with bugfix-2.0.x… (edit: email headers removed)

[boelle]

I use 2.0.1,

that one is not updated as much as 2.0.x, in fact 2.0.1 is just an frozen copy of 2.0.x

[wolfgangmauer]

THX,
updated to git 2.0.x. Updated configuration, same result :-(
Now y moves more (~1 cm) and than stops at wrong position. Even with higher Y_STALL_SENSITIVITY value.
Maybe problem with my NEMA17 running 0.9° ?!

But if separated G28 X/G28 Y/G28 Z works, must be a firmware problem ?!

[wolfgangmauer]

I just tried the TMC2209/UART with sensorless homing, it works as expected!

[boelle]

@wolfgangmauer so we can close this one?

[wolfgangmauer]

I found a workaround, but it's still a issue! EDIT: removed email headers

[wolfgangmauer]

Getting more and more strange 👎
If i cancel a print, restart same, homing on X don't work

[boelle]

btw... even prusa printers with sensorless homing have a deviation of about 0.3mm
so i cant recomment it, its just a gimmick

[Lino77]

Have exactly the same problem with SkrPro and tmc2209. G28 X works and at Y it only moves a few mm and stops at the wrong position G28 X G28 Y G28 Z works perfectly.
Marlin bugfix-2.0.x was 1.3.2020
Marlin.zip

[Camaro1]

I seem to have exactly the same problem. I'm also using the SKR 1.3 board but my dirver boards are TMC5160. My Printer is a CoreXY and I am homing in positive X and Y direction.
I described the issue here in a little more detail: https://reprap.org/forum/read.php?415,867991,868390#msg-868390
I updated to the latest bugfix about 5 days ago. That was when the problem started. I also tried the 2.0.x branch (guess the current one is 2.0.4.4) but it had the same problem. Before that sensorless homing worked perfectly.
I also tried the IMPROVE_HOMING_RELIABILITY setting but this caused X and Y to barely move at all. Setting the X/Y_HOME_BUMP_MM values to 0 did also nothing.
If you need any additional information, I will kindly provide it.
I appreciate any help.

[Camaro1]

Today I retried enabling the IMPROVE_HOMING_RELIABILITY feature and with it increased the stall sensitivity to get the carriage moving again. But I cannot tune it correctly. With a sensitivity value of 1 the stall guard is triggered immediately without moving to the end and with a value of 2 it does not trigger at all.
Am I doing something wrong here? Is there a special setup necessary for this feature?

Thank you for your help.

[Camaro1]

The issue feels like the stall guard signal is not returning fast enough to its default state. Could this be an issue with the pullup resistors not being active, leaving the pins in a floating state. This could explain the inconsistent behaviour other people described as well. (e.g. G28 X only working on the second time, etc.)
Or might the fault be in the TMC library?
I would gladly test this hypothesis if someone could advise on how to do this.

[Camaro1]

Ok I did a few tests now and it seems that sensorless homing works, if I disable HOMING_BACKOFF_MM. This however makes the Y homing very harsh, which could be specific to my setup (e.g. tolerances or minimal misalignments in my system, which are noticed if the X axis is restricted during the Y homing).
I added the X and Y_HOME_BUMP_MM 5 in again, which creates the the distance to the end of the axis instead (due to the stallguard feature triggering already when accelerating for the second bump) This leaves me with a very inconsistent result. This however does not really matter as the printer homes for every new print. At the moment I do not depend on the repeatability of the homing process. The following config is a functional workaround for me.

// Homing hits each endstop, retracts by these distances, then does a slower bump.
#define X_HOME_BUMP_MM 5
#define Y_HOME_BUMP_MM 5
#define Z_HOME_BUMP_MM 2
#define HOMING_BUMP_DIVISOR { 2, 2, 4 }  // Re-Bump Speed Divisor (Divides the Homing Feedrate)
//#define QUICK_HOME                     // If homing includes X and Y, do a diagonal move initially
//#define HOMING_BACKOFF_MM { 2, 2, 2 }  // (mm) Move away from the endstops after homing

#16872: Here @thinkyhead talks about an added time delay and backoff for the QUICK_HOME feature. Maybe these could be necessary for independent homing of the axis as well as a more robust fix. But I haven't looked into this commit in more detail yet.

[aguindehi]

I see the same happen here on a CoreXY machine doing sensorless homing with SKR1.3/TMC2209. I started doing Home XY and Home Z by hand using octoprint to make sure the carrage will not crash on a G28; G29. I always wondered why this happens on a G28 in my start gcode but not using octoprint. Now it makes sense, octoprint does G29 X0 Y0 and G29 Z0 separately, I do a G28 without arguments in my start gcode.

[boelle]

@wolfgangmauer still an issue?

[wolfgangmauer]

Funny question, someone fix the problem?

[boelle]

you should test at interval, and marlin is updated almost daily

see it like being an active part of your own bug report

[wolfgangmauer]

Ok, i will update and test

[boelle]

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

[sawaguna]

I see the same happen here on a CoreXY machine doing sensorless homing with SKR1.3/TMC2209. I started doing Home XY and Home Z by hand using octoprint to make sure the carrage will not crash on a G28; G29. I always wondered why this happens on a G28 in my start gcode but not using octoprint. Now it makes sense, octoprint does G29 X0 Y0 and G29 Z0 separately, I do a G28 without arguments in my start gcode.

I have a similar issue with sensorless homing.

If I do :

• Auto Home (G28)
• Z-Align (G34)
• Auto Home (G28)

Then the X axis is moving only about 1mm during the 2nd auto home. While the Y and Z axis are fine.

But if I do like you said, then it's fine :

• Auto Home (G28)
• Z-Align (G34)
• Home X
• Home Y
• Home Z

The X axis (and the others too), are homing correctly with this solution

Need to check the bugfix branch, to see if it's fixed

[sjasonsmith]

Others have reported similar (or identical) issues an an SKR Pro, so this is likely related to CoreXY with sensorless homing rather than being specific to particular boards or HALs.

[Minims]

@sjasonsmith i confirm I have this issue before my current problem (Y homing). I was used to start with a G34 to avoid this homing problem on SKR PRO 1.1

[sjasonsmith]

@fuganater reported the same issue in #18472, which I have closed as a duplicate.

You can find their configurations for an SKR 1.3 with TMC2209 drivers attached to that issue.

I will mark this issue confirmed, given the number of people reporting the same problem.

[sjasonsmith]

I believe this issue is described in the following Issue/Feature Request: #17213

There is some information in there that can probably explain why this is happening.

[Minims]

@fuganater reported the same issue in #18472, which I have closed as a duplicate.

You can find their configurations for an SKR 1.3 with TMC2209 drivers attached to that issue.

I will mark this issue confirmed, given the number of people reporting the same problem.

It's exactly the issue I have with sensorless homing on SKR PRO 1.1 (stm32) with TMC2209. Details here : #18212 #18391

[fuganater]

So today I updated from 2.0.5 to 2.0.5.3 using Auto Home works but now my ABL is broken :/ I'll check to see if there is a bug.

[wolfgangmauer]

After 2 broken BLTouch pins, i'm back to endstop switches....

[sjasonsmith]

For the purposes of reproducing and fixing this issue, testing should be performed on the bugfix-2.0.x branch.

@Minims, if this describes the behavior you are seeing, I would appreciate it if you move further work on your homing issue here. That will allow the other issue to be closed, since it has already been fixed for non-sensorless users.

[Minims]

So here my latest tests with the same configuration on SKR_PRO:

2.0.5.3

M502
M500
M119
> all is in open state
G28 X
> x_min is TRIGGERED

Latest Bugfix-2.0.x

M502
M500
M119
> all is in open state
G28 X
> y_min is TRIGGERED

So from my point of view, this can explain why after homing X, Y doesn't move as y_min is already TRIGGERED.
Can someone else can try this on some other SKR board such as 1.3 ?

[Minims]

Hello, i have dig a bit more my issue, and it seems that if I use 128 microsteps instead of the default 16 it fails en homing. I am using TMC2209 with UART. if someone can help to see where is the issue.

[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

[Minims]

Homing is back with 0.7.1. I can have some false positive but i need to update my stallguard value now. Thanks !

[sjasonsmith]

Thanks for trying it out @Minims! I believe @wolfgangmauer is no longer using sensorless homing, and won't be able to try it out. I'm hoping some of the other users who have commented on this thread will report back.

This original issue was opened long before TMCStepper 0.7.0 introduced the problem you saw, so other users may or may not see improvement with 0.7.1.

[wolfgangmauer]

With my last test (0.7.1) I must hit the “Home X” button(pronterface) multiple times to get X moving ☹ For all my tests i power of the printer, move the x-carriage by hand to the middle of the bed and the power on again. If the x-carriage already at X_MIN_POS/Y_MIN_POS everything works fine(of course). Sometimes the x-carriage moves ~1cm in Y before moving in X (strange) Von: Jason Smith <[email protected]> Gesendet: Montag, 6. Juli 2020 23:55 An: MarlinFirmware/Marlin <[email protected]> Cc: Wolfgang Mauer <[email protected]>; Mention <[email protected]> Betreff: Re: [MarlinFirmware/Marlin] [BUG] Sensorless homing on a COREXY with SKR1.3/TMC2130 failed (#16420) Thanks for trying it out @Minims <https://github.com/Minims> ! I believe @wolfgangmauer <https://github.com/wolfgangmauer> is no longer using sensorless homing, and won't be able to try it out. I'm hoping some of the other users who have commented on this thread will report back. This original issue was opened long before TMCStepper 0.7.0 introduced the problem you saw, so other users may or may not see improvement with 0.7.1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16420 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGVIUPFHLT7PQWU33LB55GTR2JB4PANCNFSM4KB5U6IQ> . <https://github.com/notifications/beacon/AGVIUPFI4U5PAMQZIYBU33DR2JB4PA5CNFSM4KB5U6I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE4BKM3Q.gif>

[wolfgangmauer]

Now that I'm back to switches, I've noticed something strange.
It looks like homing on a corexy(i have a BLV mgn cube) generally causes problems.

X and Y home correct, but with Z it makes no movement to the middle of the bed, stay @X_MIN, @Y_MAX :-(

I tried homing on Y_MAX:
#define X_HOME_DIR -1
#define Y_HOME_DIR 1
#define Z_HOME_DIR -1

// @section machine

// The size of the print bed
#define X_BED_SIZE 235
#define Y_BED_SIZE 235

// Travel limits (mm) after homing, corresponding to endstop positions.
#define X_MIN_POS -43
#define Y_MIN_POS -80
#define Z_MIN_POS 0
#define X_MAX_POS 275
#define Y_MAX_POS 300
...
#define Z_SAFE_HOMING

#if ENABLED(Z_SAFE_HOMING)
#define Z_SAFE_HOMING_X_POINT ((X_BED_SIZE) / 2) // X point for Z homing when homing all axes (G28).
#define Z_SAFE_HOMING_Y_POINT ((Y_BED_SIZE) / 2) // Y point for Z homing when homing all axes (G28).
#endif

see also #18604

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

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