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 seems broken for TMC2130 SPI #16855

Closed OldCurmudgeon3DP closed 4 years ago

OldCurmudgeon3DP commented 4 years ago

MKS Gen L board w/ TMC2130 drivers in SPI w/ diag pins of X and Y wired to the respective min endstops. Had to enable software SPI to keep the single ribbon to the Ender 3 LCD. I've adjusted M914 for X and Y to the point that +/-1 step will cause the axis to either not move or ram the home position requiring a power off. The Z axis is working as expected w/ a BLTouch v2.x. Stepper motions when moved via terminal are correct.

When I tried compiling the 2.0.3 release a week ago it would crash both X and Y when issued G28. When issued G28 X or G28 Y the steppers would just 'twitch' and the coordinate would be set to 0. No value of M914 would change this behavior; with the 2.0.3-bugfix at least M914 has an effect. G28 Z behaves as expected.

Everything works fine on 1.1.9-bugfix from mid last year (not sure the exact build date).

I had the 1.1.9 files open beside the 2.0.3 files so I could change the setting values to match. Everything is being compiled with VSCode. These are the files I modified in both 1.1.9 and 2.0.3 bugfixes; 2.0.3 versions.

Configuration_adv.txt Configuration.txt pins_MKS_GEN_L.txt pins_RAMPS.txt

Balzac40 commented 4 years ago

I use sensorless homing, but no STEALTHCHOP, X_STALL_SENSITIVITY = 8 and also X_CURRENT_HOME at value equal to X_CURRENT / 2 (half).

OldCurmudgeon3DP commented 4 years ago

I use sensorless homing, but no STEALTHCHOP, X_STALL_SENSITIVITY = 8 and also X_CURRENT_HOME at value equal to X_CURRENT / 2 (half).

I'll see if that helps, but I thought I saw a comment in the config saying homing always uses spreadcycle.

Edit: No luck. Tried values from 60 to -60 and just the same squeak from the motors even with the current halved.

Send: M122
Recv:       X   Y   Z   E
Recv: Enabled       true    true    true    false
Recv: Set current   750 660 660 600
Recv: RMS current   734 642 642 581
Recv: MAX current   1035    905 905 819
Recv: Run current   23/31   20/31   20/31   18/31
Recv: Hold current  11/31   10/31   10/31   9/31
Recv: CS actual 11/31   10/31   10/31   9/31
Recv: PWM scale 42  38  39  0
Recv: vsense        1=.18   1=.18   1=.18   1=.18
Recv: stealthChop   true    true    true    true
Recv: msteps        16  16  16  16
Recv: tstep     max max max max
Recv: pwm
Recv: threshold 49  49  9   9
Recv: [mm/s]        201 201 219 218
Recv: OT prewarn    false   false   false   false
Recv: OT prewarn has
Recv: been triggered    false   false   false   false
Recv: off time  4   4   4   4
Recv: blank time    24  24  24  24
Recv: hysteresis
Recv: -end      2   2   2   2
Recv: -start        1   1   1   1
Recv: Stallguard thrs   60  8   0   0
Recv: DRVSTATUS X   Y   Z   E
Recv: stallguard        *   *
Recv: sg_result 456 471 0   0
Recv: fsactive
Recv: stst      *   *   *   *
Recv: olb
Recv: ola
Recv: s2gb
Recv: s2ga
Recv: otpw
Recv: ot
Recv: Driver registers:
Recv:       X   0x81:0B:01:C8
Recv:       Y   0x81:0A:01:D7
Recv:       Z   0x80:0A:00:00
Recv:       E   0x80:09:00:00
Recv: 
Recv: 
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing E connection... OK
Recv: ok
Balzac40 commented 4 years ago

I told you as you have allowed stealthchop in your config files!

OldCurmudgeon3DP commented 4 years ago

So this paragraph in configuration_adv.h doesn't matter? Next time I'll try disabling it anyway since the notes say SPI sensing is "beta."

   * Use StallGuard2 to home / probe X, Y, Z.
   *
   * TMC2130, TMC2160, TMC2209, TMC2660, TMC5130, and TMC5160 only
   * Connect the stepper driver's DIAG1 pin to the X/Y endstop pin.
   * X, Y, and Z homing will always be done in spreadCycle mode.
thinkyhead commented 4 years ago

You're correct that Marlin now sets TMC drivers to spreadCycle during homing.

It can never hurt to issue M502, M500 and do a reboot to make sure your settings are fresh.

Beyond that, AFAIK there are no super serious issues with TMC drivers at this time, but we're keeping an eye on how to best troubleshoot them when things like this crop up.

fab4fun commented 4 years ago

I can confirm the issue (also TMC2130). If I set: #define X_STALL_SENSITIVITY 3 it will detect the end, but rather harshly. Setting to 2 just bounces off the end stops endlessly. Setting to 4 won't let it even get moving.

default I'm using is 

#if AXIS_IS_TMC(X)
   #define X_CURRENT       800        // (mA) RMS current. Multiply by 1.414 for peak current.
   #define X_CURRENT_HOME  X_CURRENT  // (mA) RMS current for sensorless homing

I will try X_CURRENT/2 when I get home

seandop commented 4 years ago

I can also confirm the issue (TMC2130 and sensorless homing for X-Y, as well). Sometimes (but not always) when calling G28 X, G28 Y, or simply G28, the drivers will "twitch" for the X and/or Y motor and the coordinate will be set to 0, regardless of where the nozzle actually is on the buildplate. Other times, homing works as expected. Z-axis homing (which is not sensorless -- I use a BLtouch) works fine. I'd never seen this strange behavior on the 1.x builds, and I didn't have it on the early 2.0-bugfix builds (around 5/2019). However, it did start appearing after I upgraded from a 5/2019 build to a newer (2/2020) 2.0-bugfix a few weeks ago.

Interestingly, I've found that if the "twitch" does occur, calling G28 X, G28 Y, or G28 a second time always results in correct homing behavior. This problem is so random, that I've actually modified my start G code in my slicer to manually home X twice, followed by Y twice, and then Z always works just fine (not setup for sensorless homing). The firmware really seems to be working well, so I'm content to use this as a bandaid fix for now...

EDIT: I used to use *#define _STALL_SENSITIVITY 8, per the default, but I've also been able to decrease it to 0 (supposedly the range is -64 to 63 for the TMC2130, so I decided to mess around with it a bit). When I had set it to 0, I immediately thought that that must have been the cause of the issue. However, it still appears when set at 8.

Camaro1 commented 4 years ago

I'm having the same issue, as well as some others here: #16420

amaschas commented 4 years ago

I think I'm having a similar problem. I have stallguard activated, but the motors never actually stall. I connected a meter to the diag pins and the voltage never changes, which indicates to me that stallguard isn't triggering on a hardware level.

LuSEllDen commented 4 years ago

Hello. I have exact the same problem with latest build of Marlin 2.0.5.3. It works great on 1.1.9. Now I must be always ready to press reset button. I tried many settings with current and bump sensitivity but this behavior seems very random :-(

boelle commented 4 years ago

@ProfEngr still an issue?

LuSEllDen commented 4 years ago

Yes, it is still an issue. I don't find a working solution yet. Printer still damaging a belt due to this issue. Sensorless homing works successfully only about 25% of attempts.

thinkyhead commented 4 years ago

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.

OldCurmudgeon3DP commented 4 years ago

I'm haven't been running Marlin on my printer since March.

@ProfEngr still an issue?

I can't easily say at this point. I haven't had Marlin on my printer since March.

fab4fun commented 4 years ago

I suspect the issue lies somewhere in the translation of the 'sensitivity' calibration to a driver current threshold in the trinamic drivers. It seems to be off by an order of magnitude, such that a single integer value change is either too sensitive and false triggers all the time, or not sensitive enough and will only occasionally trigger (and bang against the end). The 'real' robust value is somewhere in-between.

seandop commented 4 years ago

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

After seeking help from the community, if the consensus points to a bug in Marlin, then you should post a bug report.

At least four of us have confined the issue. Kinda seems like a slap in the face to just close it out and tell us to seek support for "questions" elsewhere...

amaschas commented 4 years ago

I can confirm this is still happening. I went several rounds with people in the Discord trying to solve it and no dice. I've since reverted to mechanical end stops.

macasero commented 4 years ago

I hava had the same problem this evening on a friends CoreXY printer.

I figured it out the homing with at lower current solved it, so I left it like this (X a Y with the same value since it´s a coreXY and uses both steppers to move either X and Y)

`#define X_CURRENT 1000

define X_CURRENT_HOME X_CURRENT/2 `

seandop commented 4 years ago

@macasero Interesting. I've never needed to adjust that before... any idea why that would fix it?

C4ptAwesome commented 4 years ago

@macasero this also fixed it for me. I'm also using a CoreXY.

Edit: There is an older german thread on rerap of 2019 regarding this issues. It seems that low homing speeds and high current interfere with stalldetection. So the best way is to reduce the current as decribed by @macasero before.

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.