[FR] TMC5161 stepper driver support

[LT1010]

I have encountered a problem, I use the latest marlin firmware and 5160 is OK on my motherboard. The configuration is not changed, only the drive is changed to 5161, and the information displayed using M122 is normal, but when I move the XYZ axis, there is only a little movement and then it cannot move. I used M122 to see the information changed. move_before: move_x_asis:

[LT1010]

Please tell me where the problem is(TMC5160 is OK on my motherboard).

[sjasonsmith]

Can you add your configuration files, including your pins file if you have modified it.

[sjasonsmith]

I would also like to know if you see the same results every time you run M122, or if the results are somewhat random.

[LT1010]

我还想知道每次运行M122时是否看到相同的结果，或者结果是否有些随机。

Hi,this is my configuration file, the pin file has not been moved configuration.zip. Every time I move any axis, the mstep of the corresponding axis will become 256, and then the motor will not move.

[sjasonsmith]

This might be related to https://github.com/MarlinFirmware/Marlin/issues/16311.

That issue was closed since the fix belongs to TMCStepper, but there is a workaround described that you could try.

[LT1010]

This might be related to #16311.

That issue was closed since the fix belongs to TMCStepper, but there is a workaround described that you could try.

Hello, is there any other solution besides this, I will try one by one.

[LT1010]

I used a logic analyzer and here is the result：

[LT1010]

My problem has not been solved, this seems to have nothing to do with TMCStepper, I try to reduce the speed of SW_SPI, and the result of M122 is not random, it only changes after I move the axis, and each time after the change, M122 The results are also fixed. I also want to know if there are other ways to get my 5161 working properly.

[LT1010]

My problem has not been solved, this seems to have nothing to do with TMCStepper, I try to reduce the speed of SW_SPI, and the result of M122 is not random, it only changes after I move the axis, and each time after the change, M122 The results are also fixed. I also want to know if there are other ways to get my 5161 working properly.

[boelle]

@sjasonsmith does the info from @lijinlin19970813 make any bells ring?

[sjasonsmith]

@sjasonsmith does the info from @lijinlin19970813 make any bells ring?

@boelle These are SPI-connected drivers. Everything I have been has been for UART-connected drivers. I've never used either of these.

[Bob-the-Kuhn]

The behavior you're describing could be due to too little power being used for the speed, acceleration, jerk, and microstep settings.

One possibility is the RSENSE settings specified in the Configuration_adv.h file are wrong. The current settings are 0.11 Ohms. A picture I saw that showed both the 5160 & 5161 pololu driver modules showed 0.075 Ohm resistors on the 5160 and 0.062 Ohm resistors on the 5161. You'll need to physically examine your modules to see what resistors are actually used.

I doubt that this is your problem. If my numbers are accurate you are actually sending more current to the steppers than specified in Configuration_adv.h.

I suggest you try some RIDICULOUSLY conservative settings to see if that is the problem. Try setting microsteps to 4, cut steps per unit by 4, cut acceration max by 10, cut max speed by 10 and decrease jerk by 10. Then manually issue really slow movement commands (G0 X20 F200).

[LT1010]

The behavior you're describing could be due to too little power being used for the speed, acceleration, jerk, and microstep settings.

One possibility is the RSENSE settings specified in the Configuration_adv.h file are wrong. The current settings are 0.11 Ohms. A picture I saw that showed both the 5160 & 5161 pololu driver modules showed 0.075 Ohm resistors on the 5160 and 0.062 Ohm resistors on the 5161. You'll need to physically examine your modules to see what resistors are actually used.

I doubt that this is your problem. If my numbers are accurate you are actually sending more current to the steppers than specified in Configuration_adv.h.

I suggest you try some RIDICULOUSLY conservative settings to see if that is the problem. Try setting microsteps to 4, cut steps per unit by 4, cut acceration max by 10, cut max speed by 10 and decrease jerk by 10. Then manually issue really slow movement commands (G0 X20 F200).

I changed the RSENSE to over 0.062, it is still invalid, but I will try what you said to change other parameters to try the effect.

[Bob-the-Kuhn]

Also double the current settings in configuration_adv.h

[boelle]

@lijinlin19970813 did the last suggestion from @Bob-the-Kuhn help?

do we have a bug or does it more look like a config error?

[XBrav]

It still happens, at least for me. With the latest TMCStepper library (0.6.1 as of posting), I can get up and down movement by jogging manually. Homing seems to work fine too, however, around the first few probes, the Z simply stops moving.

Whatever is happening, the stepper entirely seems to shut off. I can freely move the rod the moment the failure occurs. Unfortunately, I'm using a BTT E3 board, and I don't have enough memory for TMC_DEBUG currently.

[XBrav]

Ok, I stripped down the code enough to get M122 on the machine. It's an E3 DIP, with 2208s in UART on the X, Y, and E0. Z is the 5161.

SENDING:M122
        X   Y   Z   E
Enabled     false   false   false   false
Set current 650 800 1000    700
RMS current 642 795 990 673
MAX current 905 1121    1396    949
Run current 20/31   25/31   19/31   21/31
Hold current    18/31   22/31   17/31   18/31
Global scaler           133/256
CS actual   18/31   22/31   17/31   18/31
PWM scale   21  25  16  21
vsense      1=.18   1=.18       1=.18
stealthChop true    true    true    true
msteps      16  16  16  16
tstep       max max max max
pwm
threshold
[mm/s]
OT prewarn  false   false   false   false
OT prewarn has
been triggered  false   false   false   false
off time    3   3   3   3
blank time  24  24  24  24
hysteresis
-end        -1  -1  -1  -1
-start      1   1   1   1
Stallguard thrs         0
DRVSTATUS   X   Y   Z   E
stallguard
sg_result           0
fsactive
stst        *   *   *   *
olb
ola
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
        X   0xC0:12:00:00
        Y   0xC0:16:00:00
        Z   0x80:11:40:00
        E   0xC0:12:00:00
Testing X connection... OK
Testing Y connection... OK
Testing Z connection... OK
Testing E connection... OK`

I then perform a move (up is fine, it's the direction change too that causes the issue), the microsteps changes to 256 and the address changes as well:

G1 Z10
SENDING:G1 Z10
G1 Z0
SENDING:G1 Z0
M122
SENDING:M122
        X   Y   Z   E
Enabled     false   false   false   false
Set current 650 800 1000    700
RMS current 642 795 990 673
MAX current 905 1121    1396    949
Run current 20/31   25/31   19/31   21/31
Hold current    18/31   22/31   17/31   18/31
Global scaler           133/256
CS actual   18/31   22/31   8/31    18/31
PWM scale   21  25  8   21
vsense      1=.18   1=.18       1=.18
stealthChop true    true    false   true
msteps      16  16  256 16
tstep       max max max max
pwm
threshold
[mm/s]
OT prewarn  false   false   false   false
OT prewarn has
been triggered  false   false   false   false
off time    3   3   0   3
blank time  24  24  36  24
hysteresis
-end        -1  -1  -1  -1
-start      1   1   6   1
Stallguard thrs         0
DRVSTATUS   X   Y   Z   E
stallguard
sg_result           0
fsactive
stst        *   *   *   *
olb
ola
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
        X   0xC0:12:00:00
        Y   0xC0:16:00:00
        Z   0x80:08:00:00
        E   0xC0:12:00:00
Testing X connection... OK
Testing Y connection... OK
Testing Z connection... OK
Testing E connection... OK

At this point, the stepper no longer responds, and requires a reboot of the firmware to regain control. Depending on the motion, the Z address will change each time the failure occurs. I've seen 0x80:08:40:00 as well as 0x80:0D:40:00.

Marlin.zip

I have attached my config files for reference.

[RonnyOs]

Hi,

I‘ve got the same problem with my TMC5161 drivers. I tried the decrease of sw spi clock with no succes. If i force the drivers to use chop mode, the Steppers are working. Current Must be in a small Range window to prevent it from stop. If I try to use faster movements the Steppers stop working at Point of Switch to spread Cycle.

[boelle]

a lot of updates and fixing has happend in the last week, is the problem still there?

[XBrav]

@boelle I'll try and set up a test rig tonight. https://github.com/teemuatlut/TMCStepper/blob/master/src/source/TMC_platforms.h has not been modified for the stm32 platform, only for the LPC176x family.

Luckily, I have one E3 DIP machine standing by.

[XBrav]

Just compiled 2.0.3.

Environment: BIGTREETECH E3 DIP 1.0 (STM32F103RC, 256k, NOUSB) Steppers: X: BIGTREETECH TMC2208 V3.0 UART Y: BIGTREETECH TMC2208 V3.0 UART Z: BIGTREETECH TM5161 V1.1 SPI (Configured as TMC5160 with TMC_USE_SW_SPI) E: BIGTREETECH TMC2208 V3.0 UART

All steppers detected. Issuing a home command, Z engages but does not move. X and Y homing continues, but Z is seemingly disengaged. Unable to enable M122 due to lack of memory. But likely previous issues noted above.

Without recompiling the firmware, I replaced the problematic stepper with a BIGTREETECH TMC5160 V1.2. As expected, the stepper engages and moves in both forward and reverse directions without issue.

It appears as though there were further changes to the 5161 series than simply integrating the MOSFETs into the die. Adding to the concerns, the product page notes product changes are currently underway: https://www.trinamic.com/products/integrated-circuits/details/tmc5161/

I will reach out to Trinamic for comment. For the time being, I would recommend users stick with the refined 5160s, as they are operating as expected.

[boelle]

is it the same with bugfix 2.0.x ?

[sjasonsmith]

is it the same with bugfix 2.0.x ?

bf2 is only one commit ahead of 2.0.3. Testing with it would be a waste of time.

[einencool]

I still got the same issue, I posted it on the BTT Github, but nobody responsed to it in the last 5 weeks...

I also cut the CLK-Pin from the 5160 and the 5161. The 5160 are working fine, but the 5161 make a little move and stop after that without any failure. I changed the "RSense" from 0.075 (5160) to 0.060 (5161)

I tried it on the SKR Pro V1.1 and today with a completly new setup on the SKR V1.4 Turbo The 5160 work well and the 5161 are stopping immediatly.

Can someone tell me if it is normal, that the drivers are very loud with 0.9° Steppers? I'm using them in a CoreXY and need around 1.5V to get the Steppers warm up to 40°C . If I use only 1.2V the Steppers are not so noisy, but the Steppers are cold as ice and I'm loosing steps like hell...

[Malaquitte]

These drivers are really crappy. I tried everything on a SKR 1.1 Pro, I couldn't get them to work. I don't understand how Bigtreetech makes them work on this video https://www.youtube.com/watch?v=UW_JtHcgcd4, support never answered my questions!

[Werebear93]

I can't seem to get my TMC5160 working, either. Connected one as a test to E0 and M122 does the following:

I've snipped the CLK pin, tried with and without connecting CLK to ground, adjusted RSENSE to 0.075 Ohm and nothing seems to work. Here's my current configuration (nightly bugfix build, 02/04/2020): Configuration.zip

Maybe someone has an idea of what I could have missed. I haven't tried limiting the SPI speed and honestly I don't really know how to do that, either.

[thinkyhead]

Well, for one thing, we don't formally support the 5161. As for the 5160 not working, well I'm not sure how well supported it is now in TMCStepper either. It is all very new, so we may have to wait on @teemuatlut to find some free time to troubleshoot them generally. We have a set of them here, but at the moment my custodial duties are taking up too much time to dive into testing. But perhaps @shitcreek and I will find some time to play around with 5160's later this week.

[Malaquitte]

If it's only a matter of weeks, I'm still hopeful. With my knowledge of steppers drivers I can unfortunately not help. Thanks for everything else.

[2kingsrock]

@Werebear93 I dont know what physical driver slots are configured on your board, but this looks off to me. Z/Z2 if you are using dual Z motors this would be strange.

  #if AXIS_IS_TMC(Z)
    #define Z_CURRENT       800
    #define Z_CURRENT_HOME  Z_CURRENT
    #define Z_MICROSTEPS     16
    #define Z_RSENSE          0.11
    #define Z_CHAIN_POS      -1
  #endif

  #if AXIS_IS_TMC(Z2)
    #define Z2_CURRENT      800
    #define Z2_CURRENT_HOME Z2_CURRENT
    #define Z2_MICROSTEPS    16
    #define Z2_RSENSE         0.075
    #define Z2_CHAIN_POS     -1
  #endif

Also checking your voltage, are you running a 24v or 12v system?

#define CHOPPER_TIMING CHOPPER_DEFAULT_12V

[GeminiServer]

Have exactly the same issue. After disabling SOFTWARE_DRIVER_ENABLE and STEALTHCHOP_X _Y _Z _E, the TMC5161 runs. But no features then... TMC5161 on SKR_1.4_Pro with SPI and recent Marlin Bugfix branch.

RSENSE - Nothing helped... here are the Informations:

// | --------------------------------------------------------------------------|
// | RSENSE [Ω]  | RMS current [A](CS=31) | Sine wave peak current [A] (CS=31) |
// | 0.22        | 1.1                    | 1.5                                |
// | 0.15        | 1.6                    | 2.2                                |
// | 0.12        | 2.0                    | 2.8                                |
// | 0.10        | 2.3                    | 3.3                                |
// | 0.075       | 3.1                    | 4.4                                |
// | 0.066       | 3.5                    | 5.0                                |
// | 0.060       | 3.8                    | 5.4                                | <-- 
// | --------------------------------------------------------------------------|
// Documentation --> 9 Selecting Sense Resistors List - 

https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC5161-datasheet_Rev1.02.pdf

[thinkyhead]

@GeminiServer — Is there any recent or old Marlin version where the driver works ok?

[GeminiServer]

@GeminiServer — Is there any recent or old Marlin version where the driver works ok?

Nope! I gone stepply back to till 2.0.1 and no luck.

I spend to much time on this drivers. I'll send these crappy drivers back and order the TMC5160, which seems to working and supported better than the 5161! The only difference in 5161, that they have the embedded mosfets... so don't really makes it attractive. And the support of BTT is ZERO, so i suggest all to do the same... throw them away and change to the 5160!

[GeminiServer]

But just fyi - The RSENSE on the modules seems to be different then the sheets: This is TMC5161 v1.1 with RSENSE of 0.062! Which seems Initial to work, but stops after a while, like also described above from other users.

[thinkyhead]

Thanks for the very useful info. Hopefully this will be sorted in the hardware. If there's any special initialization needed for these drivers, we'd have to wait for TMCStepper to bring that in. I'll have a peek at the datasheet soon and see if anything stands out in contrast to the 5160.

[viktoschi]

tested the driver yesterday with arduino mega and the examples in TMCStepper Repo. Stepper drivers worked fine.

[GeminiServer]

Update: I was now able to get the TMC5161 run with recent Marlin Bugfix 2.0.x. After checking latest changes at the TMCStepper-Library, i think that i found the reason and i did a test run for a couple of hours now. Till now, the driver and stepper runs without any issues.

Hardware setup:: BTT TMC5161 v1.1 and SKR 1.4 Turbo (LPC1769) Marlin version:: Branch - bugfix-2.0.x @ 12b3807a7f443470c290ec8b6fb6eefdc5b39280

My configuration: For BTT TMC5161 v1.1 with R=0.062

// RSENSE is "0.062f" is float. TMCStepper library v0.6.2 changed it to float! Therefore the float define! https://github.com/teemuatlut/TMCStepper/commit/4016500179171cba0614e116843d77229138af84

Be sure you use the TMCStepper-Lib v0.6.2 in your platformio.ini lib_debs:

TMCStepper@>=0.6.2,<1.0.0

The configuration_adv.h:

define TMC5161_RSENSE 0.062f // For X, Y, Z end E

define HOLD_MULTIPLIER 0.5

define INTERPOLATE false

define XYZE_CURRENT 800

define XYZE_MICROSTEPS 16

define STEALTHCHOP_XY

define STEALTHCHOP_Z

define STEALTHCHOP_E

//#define SOFTWARE_DRIVER_ENABLE // --> is disabled!

Give it a try and let us know if this also work for others then me.

Cheers.

[XBrav]

@GeminiServer, can you confirm if it works with 2.0.3? I will need to test this later on the STM32 platform. Previously, it was apparently resolved on the LPC176x family due to the 240ns delay imposed on the commands.

[Malaquitte]

I did a quick test yesterday on Marlin 2.0.3, motors aren't running.

[GeminiServer]

@Malaquitte did you also set the #define INTERPOLATE to false?

[Malaquitte]

@GeminiServer I've done everything you said above, taking care to delete the .pio folder to make sure I inherit the right version of TMCStepper. Did you declare TMC5161 in #define X(Y)(Z)(E)_DRIVER_TYPE ?

[GeminiServer]

@Malaquitte yes, i set the driver tpye for xyze to TMC5160.

The TMC5161 driver works only if INTERPOLATE is set to false. If you go higher with the current they do crazy things. Unfortunately i switched now to TMC5160, which works like it should be and i will send the TMC5161 back to BTT (they also have no idea why the TMC5161 not work with Marlin - got mail from their dev support). As i said before, the only difference that i see are the embedded mosfets in 5161.

[einencool]

Today I tried to get my 5161 V1.1 to work, but they still move a little bit and then they stop. I downloaded a fresh Marlin 2.0.x Bugfix and changed the TMC lib to 0.6.2

This is the following Config:

#define X_DRIVER_TYPE  TMC5160
#define Y_DRIVER_TYPE  TMC5160
#define Z_DRIVER_TYPE  TMC2209
#define E0_DRIVER_TYPE TMC2209

  #define HOLD_MULTIPLIER    0.5  // Scales down the holding current from run current
  #define INTERPOLATE       false  // Interpolate X/Y/Z_MICROSTEPS to 256

  #if AXIS_IS_TMC(X)
    #define X_CURRENT       1400        // (mA) RMS current. Multiply by 1.414 for peak current.
    #define X_CURRENT_HOME  X_CURRENT  // (mA) RMS current for sensorless homing
    #define X_MICROSTEPS     16    // 0..256
    #define X_RSENSE          0.062f
    #define X_CHAIN_POS      -1    // <=0 : Not chained. 1 : MCU MOSI connected. 2 : Next in chain, ...
  #endif

  #define TMC_USE_SW_SPI
  //#define SOFTWARE_DRIVER_ENABLE
  #define STEALTHCHOP_XY
  #define CHOPPER_TIMING CHOPPER_DEFAULT_24V
  #define HYBRID_THRESHOLD
  #define TMC_DEBUG

So I don't know, what to do next... I've cut the "CLK Pin" like on the 5160 V1.2 mentioned from the BTT support. Well, I think I've wasted 65 € with this pieces...

[viktoschi]

i had success with lower currents. but still have problems with the current on dual z motors with one stepper driver

[einencool]

When I lower the current, I've a lot of skipping steps, so that's no good idea for me. In my case the motors are cold (around 35°C) until I raise the voltage to 1.400V With 1.600V the motors are absolutely fine with the TMC5160 V1.2, but they are very loud, like the old A4988. If I lower the voltage they are much quieter, but with 1.200 V I'm only skipping steps and with 0.8V I even can't home the machine. It's a big CoreXY Printer with 0.9° Motors

[viktoschi]

got all axis working. had wrong accelerations and axis steps. its also working with #define INTERPOLATE true. but then you need one driver per motor. other settings in conf_adv

#define X_CURRENT       800  

config:

#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 400, 445 }
#define DEFAULT_MAX_FEEDRATE          { 300, 300, 50, 40 }
#define DEFAULT_MAX_ACCELERATION      { 2000, 2000, 100, 10000 }
#define DEFAULT_ACCELERATION          800    // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  10000    // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   2000    // X, Y, Z acceleration for travel (non printing) 

https://github.com/LadyViktoria/Marlin/tree/WIP_TMC5161

[RonnyOs]

I am not able to compile since i get an errot in function "restore_trinamic_drivers" something with "stepperZ" "stepperY" "stepperX" first defined here. Anyone knows this problem? with older bugfix2.0 the configuration files were working...

[viktoschi]

delete .pio folder and maybe /users/.platformio too make sure you have TMCStepper@>=0.6.2,<1.0.0 in platformio.ini

[Malaquitte]

\o/ It's starting to work for me with the following values:

#define X_DRIVER_TYPE  TMC5160

#define X_CURRENT       580 
#define X_CURRENT_HOME  X_CURRENT  
#define X_MICROSTEPS     16    
#define X_RSENSE          0.062
#define X_CHAIN_POS      -1    

I'm sure I can make it even better by playing with X_RENSE.

[viktoschi]

i have notice its better to wait a few seconds until the flash drive comes up in windows before connect with pronterface

[Malaquitte]

On .1mm steps it works 2 or 3 times and then nothing...