Marlin: [FR] TMC2130 StallGuard as Endstop for CoreXY

[Freddrup]

---

Feature Request

Is it possible to add a Sensorless endstop option to use the TMC2130's Stallguard feature with CoreXY setups ?
After looking a bit closer at the configuration files, I haven't seen any option for that; only for standard Cartesian setups, where you just place a wire from the driver's DIAG1 pin to the X/Y endstop pin (and, I may be wrong, but I think this wouldn't work with a CoreXY setup).

P.S.: Or maybe I haven't looked deeply enough at the config' files ^^

[teemuatlut]

I don't think there's anything currently that would stop you from compiling it that way but I don't know how it would behave because movement in X or Y is always executed by both motors and the stallGuard would trigger both X and Y endstops. I've got a CoreXY frame that I'm designing so I'll look into it at some point.

[Freddrup]

Compiling Marlin with CoreXY, TMC2130 and StallGuard as endstop options defined works without reporting any errors, but, as stated by teemualtut :

I don't know how it would behave because movement in X or Y is always executed by both motors and the stallGuard would trigger both X and Y endstops.

I plan to build a custom 3D printer, and I considered using a CoreXY setup (because of the "design simplicity"), so having it behaving correctly would be nice ^^

[bjarchi]

It seems like it will probably take some code to get this working properly on core machines (assuming it doesn't now), but it should be pretty simple. FAST_HOME would have to be disabled (whatever that option is that initially homes x and y together), then I think you would just OR the stallguard signals from each motor as the 'endstop' proxy signal.

[teemuatlut]

It might be as simple as adding some "debounce" in there. Or it might not even need that.
What I think would happen is when homing let's say in the X direction, the carriage would move and collide with the frame, as it's supposed to, and you'd then have pulses on both X and Y endstop. Now, Marlin doesn't actually need to care that the Y endstop was triggered. All it needs to look for is that the X endstop signal went active. Then we do the same with Y direction and not care about X endstop signal. What I don't know is that when the X endstop is triggered, how long a pause do we need so that Marlin doesn't immediately see the pulse on Y as well.

[bjarchi]

Well on core, since both motors are involved in moving both axes, you don't have distinct 'x endstop' and 'y endstop' signals. This is why you have to disable fast homing - when homing either axis, you expect to see StallGuard signals from either or both motors.

Thus, I think the program logic would be something like this (obviously simplified pseudocode):

home_x {
  while (!stallguard_a && !stallguard_b) {
    x_pos = move_x_toward_home(delta_x)
  }
  save_home_position_x(x_pos)
}

And of course similar logic for Y.

[campy]

Hi, today I test tmc2130 in corexy for x and y axis works ok, you don't need change anything for home, only you need down sensibility of tmc2130 homming features to 5 or 3 value (default it's 19).
This way homming it's very soft

[Freddrup]

That's an excellent thing to know !!

[ismangil]

@campy where did you purchase the drivers, Waterott or elsewhere?

What is the proper configuration of the pins/soldered pads?

Thanks!

[campy]

Hi, @ismangil purchase in waterott, and follow toms3d tutorial for configure it

https://toms3d.org/2017/12/09/tmc2130-guide/

Now only i need know how to change pins for work with LCD, because AUX3 its busy with tmc2130

[lonelymyp]

It is possible to connect one driver to both endstop input
In the CoreXY, it does not matter which driver will give the signal, the signal will be from both driver during parking on each axis.

[larsleukert]

@campy
You only need to change the pins for CS in you pins_RAMPS.h that are on AUX3
I used the one for E0/E1 as i wont use a TMC2130 to extrude.

define X_CS_PIN 53 -> 42

define Y_CS_PIN 49 -> 44

The other pins vom AUX3 (SPI) can be used together with the display. I replaced the 8pin female header on the smartdisplay with a stackable one and connected the 3 SPI pins on top

@lonelymyp
tried that yesterday, but had no success so far. Need to get deeper into this - maybe i will retry with a blank fw config instead of my patched hypercube config

[thinkyhead]

On a CoreXY there's no way for the steppers to distinguish whether it was the X axis or the Y axis that was interrupted. So when homing with CoreXY the XY endstops must be combined. Then, if only the X axis is moving when the "XY endstop" gets triggered, it can assume it's the X axis.

[larsleukert]

Imho just combining won't solve it.
Currently there is only the diag1 pin of the driver for the homing axis enabled (together with switching to spreadCycle)

  #if ENABLED(SENSORLESS_HOMING)
    #if ENABLED(X_IS_TMC2130)
      if (axis == X_AXIS) tmc2130_sensorless_homing(stepperX);
    #endif
    #if ENABLED(Y_IS_TMC2130)
      if (axis == Y_AXIS) tmc2130_sensorless_homing(stepperY);
    #endif
  #endif

[larsleukert]

So far:
Homing in STEALTHCHOP works kind of (with (X/Y)_HOMING_SENSITIVITY set to 7)
But printing in STEALTHCHOP is not an option on my hypercube: hat to reduce X/Y _CURRENT to 650, acceleration to<1000 and slow down printing not to lose steps.
So i switched to spreadCycle - and homing did not work anymore. M43 E showed that the x endstop was triggered immediately. With much higher (X/Y)_HOMING_SENSITIVITY ~25 homing starts, but x endstop is triggerd to late (y stalls before - missing combination of endstops in code). Reduced (X/Y)_HOMING_SENSITIVITY step by step to 20 -> same problem x endstop was triggered immediately .
I didn't expected that cause the TMC2130s are always switched to spreadCycle while homing even when configured to stealthChop.
Don't understand whats going on, maybe there is a difference in the initialization of the TMCs which leads to this behavior.
Any ideas?

[larsleukert]

@campy Do you use stealthChop or spreadCycle?

[campy]

@larsleukert i use stealthChop and selected diferent sensitiviy for X and Y in my case i try with a Sparkcube coreXY

X_HOMING_SENSITIVITY 3
Y_HOMING_SENSITIVITY 4

Never test spreardcycle

[vtuan10]

When I use G28 to home, my coreXY first homes in x-direction, but after bumping at the end of X-axis, instead of going straight to Y, the hotend goes diagonally to the middle while moving Y0.
It seems like the X motor is stopped after homing X (if only one motor rotates in coreXY kinematics, the hotend goes diagonally).

[vtuan10]

I have this issue only when using tmc2130 stallguard as endstops, With normal endstop switches everything works.

[KrX3D]

hello,

i also got the tmc2130 from china, they are running (only problem when the current is first set to 0 "M906 X0" than i get after moving the axis an PRINTER HALTED error, but setting it to 800 works)

my problem is that moving into the direction to 0 gives me always an "Endstop hit" even setting the sensetivity to 100 and more.

i have STEALTHCHOP enabled and at the moment im trying

#define X_HOMING_SENSITIVITY  250
#define Y_HOMING_SENSITIVITY  250

tried it with values from 3 to 100 many times

i have got an hypercube.

EDIT: what i also noticed is that my drivers reg are simetimes the same i.e. 0x80:0C:00:00 but sometimes after flashing a new moded version of marlin they show up like this

READ: Driver registers:
READ: X = 0x80:0C:00:00
READ: Y = 0xC0:0C:00:00

[Seri-]

I had great success with sensor sensitivity set to 3 on x and y and a slow homing speed of "40x60" with "quick home" disabled on latest Bugfix build.
I also connected both steppers to both endstop pins so it won't matter which one is triggered.

I have done about 50 test homings and non of them failed.

[KrX3D]

hi,

where can i config the homing speed/disable quick home?

and what exactly do you mean with

I also connected both steppers to both endstop pins so it won't matter which one is triggered.

you have connected the pin of both steppers together and connected that to both endstop pins?

EDIT: ok i found the Quick homing and it was disabled. but i cant see the homing speed option

[alfredanil]

@Seri-
Do you think stallguard homming could work on CoreXZ setup as well? I mean would it be possible to do sensorless bed levelling apart from homming with Core XZ?

[thinkyhead]

Do you think stallguard homming could work on CoreXZ setup as well?

If it's implemented for one core, it is implemented for all.

sensorless bed levelling apart from homming with Core XZ?

Please test #9582 and give some feedback there.

[jcphlux]

So I see this issue is still open and wanted to know if this issue is close to a resolution. I am design a new CoreXY printer and was leaning towards using tmc2130 and would love to use sensor less homing.

[campy]

So I see this issue is still open and wanted to know if this issue is close to a resolution. I am design a new CoreXY printer and was leaning towards using tmc2130 and would love to use sensor less homing.

Yes, this problem its solved, and works perfect for corexy, only need use low sensitivity like this:

X_HOMING_SENSITIVITY 3
Y_HOMING_SENSITIVITY 4

[dchosking]

I have an issue using the sensorless homing on a corexy, in stealthchop it works 100% but when I print I miss steps, so I want to run in spreadcycle but then sensorless homing stops working even if I set the sensitivity all the way up to 63

[thinkyhead]

I want to run in spreadcycle but then sensorless homing stops working

Maybe something @teemuatlut can answer…?

[teemuatlut]

Configuration_adv.h

   * X/Y/Z_HOMING_SENSITIVITY is used for tuning the trigger sensitivity.
   * Higher values make the system LESS sensitive.
   * Lower value make the system MORE sensitive.

However this isn't the first time I hear about this so I'll take a look as soon as I have the time.

[dchoskingsage]

Yeah that is how i have it, what i initially thought was happening was that changing for stealthchop to spreadcycle causes the motors to stall at a different level of torque which makes sense to me that it would change the homing sensitivity, however no matter what i set it to it seems to not make a difference.
Also the other thing that i noticed that was weird (but could totally be my setup) is that the sensitivity setting for X_HOMING_SENSITIVITY seems to set the sensitivity for Y and Y_HOMING_SENSITIVITY sets it for X.

[thinkyhead]

Also the other thing that i noticed that was weird (but could totally be my setup) is that the sensitivity setting for X_HOMING_SENSITIVITY seems to set the sensitivity for Y and Y_HOMING_SENSITIVITY sets it for X.

Everything looks okay in Marlin. Check your SPI EN pin connections.

[dchosking]

Everything looks okay in Marlin. Check your SPI EN pin connections.

When you say SPI EN pins, is that the pin from the driver to the endstop or the pins that select the driver to write settings to?

[thinkyhead]

the pins that select the driver to write settings to?

Yes, this. The SPI ENable pins.

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