[BUG] Sensorless homing not working in SKR1.3

[jabss]

Configuration_files.zip

Description

Sensorless homing not working in SKR1.3 with TMC2130. It seems the diag pins either aren't activated or are ignored. When reaching the endpoint, the homing routine keeps stressing the steppers for a few seconds until there is a marlin fatal error and stops. In normal movement, blocking the movement with the hand has no effect. For instance, blocking X movement, makes the Y axis to move (CoreXY printer). Sensorless homing was successful in this printer with these TMC2130's and ramps1.4 with Marlin 1.1.x Bugfix. Tried several sensitivities with M914 command. If below 0, it seems the printer auto-homes exactly where it is (fake positive). Any figure above that, it seems all the sensitivity is lost and the axes crashes against the endpoints.

Steps to Reproduce

1. Hardware CoreXY printer (hypercube like). SKR1.3 board powered with 24V with TMC2130 for both X and Y steppers. TMC2130 v1.1 from bigtreetech configured as SPI and tested OK with M122 command. No external wires for the SPI neither sensorless homing, the SKR1.3 have the required connectivity in the PCB. Continuity test OK from each DIAG pin up to the Xmin and Ymin pins (corresponding jumpers connected).

Send: M122Recv:         X   Y   Z   Z2  E
Recv: Enabled       false   false   false   false   false
Recv: Set current   800 800 800 800 800
Recv: RMS current   795 795 795 795 795
Recv: MAX current   1121    1121    1121    1121    1121
Recv: Run current   25/31   25/31   25/31   25/31   25/31
Recv: Hold current  12/31   12/31   12/31   12/31   12/31
Recv: CS actual 12/31   12/31   12/31   12/31   12/31
Recv: PWM scale 0   0   0   0   14
Recv: vsense        1=.18   1=.18   1=.18   1=.18   1=.18
Recv: stealthChop   true    true    true    true    true
Recv: msteps        16  16  16  16  16
Recv: tstep     max max max max maxRecv: pwm
Recv: threshold 49  49  329 329 52
Recv: [mm/s]        100 100 3   3   30
Recv: OT prewarn    false   false   false   false   false
Recv: OT prewarn has
Recv: been triggered    false   false   false   false   false
Recv: off time  4   4   4   4   4
Recv: blank time    24  24  24  24  24
Recv: hysteresisRecv: -end      2   2   2   2   2
Recv: -start        1   1   1   1   1
Recv: Stallguard thrs   8   8   0   0
Recv: DRVSTATUS X   Y   Z   Z2  E
Recv: stallguard
Recv: sg_result 0   0   0   0
Recv: fsactiveRecv: stst        *   *   *   *   *
Recv: olb
Recv: ola
Recv: s2gb
Recv: s2ga
Recv: otpw
Recv: ot
Recv: 157C
Recv: 150C
Recv: 143C
Recv: 120C
Recv: s2vsa
Recv: s2vsb
Recv: Driver registers:
Recv:       X   0x80:0C:00:00
Recv:       Y   0x80:0C:00:00
Recv:       Z   0x80:0C:00:00
Recv:       Z2  0x80:0C:00:00
Recv:       E   0xC0:0C:00:00
Recv: 
Recv: 
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing Z2 connection... OK
Recv: Testing E connection... OK
Recv: ok

2. Software Latest Marlin 2.0.x bugfix (from 21/9/2019) with the required TMC2130 options in configuration.h and configuration_adv.h

3. Load the FW to the printer and try a normal homing routine. The printer will "crash" against the endpoint for a few seconds before it stops with a fatal error. Before the test the M119 output is:

Send: M119
Recv: Reporting endstop status
Recv: x_min: open
Recv: y_min: open
Recv: z_min: open

Expected behavior: a) When reaching the endpoint, the printer detects it and acts like an endstop switch was pressed. b) When moving in any X/Y axis, blocking the movement with the hand makes the printer to believe it reached an endstop.

Actual behavior: a) The printer will "crash" against the endpoint for a few seconds before it stops with a fatal error. b) The printer will continue stressing the stepper and the other axis will move until the ordered movement is finished.

[ktgrach]

did you do a m502 command followed by a m500 after programming

[Seri-]

My SKR 1.3 need really low threshhold settings for my 5160 and the 2130s before that. What happens if you set it to the lowest setting possible, flash, do M502 and M500 then? In therory it should not move at all because the endstops are instantly triggered. Does this happen?

I should also mention that i did not get the endstop feature on my Bigtreetechs 5160s to work, those bought from watterott work without fail. So it might be a Bigtreetech issue.

[ktgrach]

Marlin gets the settings from eeprom on startup, Not from the firmware. After flashing the firmware you need to do m502 to load the firmware defaults into memory. The m500 now saves the settings in memory to eeprom so marlin would use them on the next boot. I only suggested that because its a common mistake. Also there are different versions of the 5160s not every version is wired the same. For starter some don't have the diag pins you are looking to use attached. Others have issues with the clock pin not being grounded. blue circle diag pins and red circle is the clk pin that gives trouble depending on the version, and just needs to be cut or bent. But if you don't have the blue pins there's your answer.

[jabss]

Hi,

In fact I didn't have the eeprom enabled in my firmware, so I re-compiled with it and reflashed it. Doing the M502 and M500 commands didn't help. The erratic behaviour remained.

I was looking to the voltage in the diag pin hoping to see it changing when reaching the endpoint, but it remained steadily at 2.78v no matter what.

Although I was using the bigtreetech 2130's V1.1 in both X and Y axis, I replaced the X driver for a bigtreetech 2130 V2.0 I was using for the Z axis. The erratic behaviour remained.

I knew for sure that the 1.1 version's didn't have the NC pin, but as per @ktgrach recommendation I double-checked in the V2.0 and in fact it was there. I de-soldered it and tried the homing for 4 times in a row and it worked. The homing of X seems much more smooth (TMC2130 V2.0) than the Y (TMC2130 1.1).

Short video of the homing routine where we can see the smooth X axis homing (TMC2130 V2.0) and not so smooth Y axis homing (TMC2130 1.1).

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

I just ordered another TMC2130 2.0 from Bigtreetech and will continue with the tests and report here.

Thanks

[Balzac40]

Trinamic documentation tells that sensorless homing (using stallguard feature) is not compatible with stealthchop : use spreadcycle for X and Y axis… No ?

[jabss]

Just a status, more than one thing was going wrong:

• I was not issuing the M502 / M500 command after reflashing the HW. I'm now issuing it every time.
• Initially the TMC modes were in Stealthchop mode (and that doesn't support stallguard), I've changed the mode to spreadcycle mode.
• The TMC2130 drivers I was using were TMC2130 1.1 from bigtreetech and these seem to not be working so well with sensorless homing as other versions. I've ordered another 2.0 driver.
• The TMC2130 2.0 driver from bigtree tech I was using to troubleshooting had the NC pin and this seems to have impact on the expected behaviour. I've removed the pin.

As in the previous video link, the X homing (using the TMC2130 2.0) is smooth. However, the experience I've been having with it in the last days is that it has one fake positive every 10 homings. The sensitivity is set at 2, and if I set it at 3 it fails all tries (initial behavior - it crashes against the endpoint).

Since the sensitivity is somewhat broad (-64 to +63, if I understood correctly) should I assume there is some bug (or work still in progress) regarding this? Should I close this issue or... ?

[jabss]

Hi,

Another update. As I mentioned in the previous post, the X/Y sensorless homings (X with TMC2130 2.0 and Y with TMC2130 1.1) are not reliable at all. If I set the sensitivity to 2 I have a considerable amount of fake positives (>10%) and if I set it to 3, it fails all the time (initial behavior - it crashes against the endpoint and marlin crashes - asks for a reset).

I was investigating if this would have anything related with the steppers I'm using. The steppers specs are:

• Model: LongsMotor 17HM0423
• Angle/step: 0.9º
• Current/phase: 2.3A
• Holding torque: 4200g.cm

My default current defined in for the X/Y TMCs is 800ma (marlins default). Should I increase it? My point is that if I have too many fake positives, maybe I need to induce more current in the steppers rather than changing the sensorless homing sensitivity.

Since the max current from the specs is 2.3A, dividing it by 1.4 (RMS) results in 1642mA. Should I set it to, say, 1500mA or would it be too much? (it's almost the double of what I have today)

Thanks

[jabss]

Trinamic documentation tells that sensorless homing (using stallguard feature) is not compatible with stealthchop : use spreadcycle for X and Y axis… No ?

Yes, I didn't know it by the time of the initial post. Now I'm thinking if it wouldn't be worth to include that validation within the compilation. Should I create a Change Request?

[boelle]

@jabss yes if there is not an issue as such then click close and open a [FR] so its made a feature request instead

[boelle]

closing this one as its more a feature request @jabss please create the feature request

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