search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.19k stars 19.22k forks source link

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

Closed wolfgangmauer closed 4 years ago

wolfgangmauer commented 4 years ago

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 commented 4 years ago

define INDIVIDUAL_AXIS_HOMING_MENU

boelle commented 4 years ago

@wolfgangmauer is this still an issue?

wolfgangmauer commented 4 years ago

Yes, there are „Workarounds“ but the normal G28 don’t work.

(EDIT: removed email headers)

boelle commented 4 years ago

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

do you use 2.0.1 or bugfix 2.0.x ?

wolfgangmauer commented 4 years ago

I use 2.0.1, but was the same behavior with bugfix-2.0.x…

(edit: email headers removed)

boelle commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

boelle commented 4 years ago

@wolfgangmauer so we can close this one?

wolfgangmauer commented 4 years ago

I found a workaround, but it's still a issue!

EDIT: removed email headers

wolfgangmauer commented 4 years ago

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

boelle commented 4 years ago

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

Lino77 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@wolfgangmauer still an issue?

wolfgangmauer commented 4 years ago

Funny question, someone fix the problem?

boelle commented 4 years ago

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

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

wolfgangmauer commented 4 years ago

Ok, i will update and test

boelle commented 4 years ago

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

sawaguna commented 4 years ago

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 :

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 :

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 : https://github.com/MarlinFirmware/Marlin/issues/18212 https://github.com/MarlinFirmware/Marlin/issues/18391

fuganater commented 4 years ago

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 commented 4 years ago

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

sjasonsmith commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Minims commented 4 years ago

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

sjasonsmith commented 4 years ago

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 commented 4 years ago

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 notifications@github.com Gesendet: Montag, 6. Juli 2020 23:55 An: MarlinFirmware/Marlin Marlin@noreply.github.com Cc: Wolfgang Mauer wolfgang.mauer@kabelmail.de; Mention mention@noreply.github.com 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 https://github.com/MarlinFirmware/Marlin/issues/16420#issuecomment-654485102 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AGVIUPFHLT7PQWU33LB55GTR2JB4PANCNFSM4KB5U6IQ . https://github.com/notifications/beacon/AGVIUPFI4U5PAMQZIYBU33DR2JB4PA5CNFSM4KB5U6I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE4BKM3Q.gif

wolfgangmauer commented 4 years ago

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[bot] commented 4 years ago

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[bot] commented 3 years ago

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.