Klipper: TMC5160 w/SKR v1.3 using 24v causes driver shutdown during print - timing issues?

[Nandox7]

Hey,

So I was running the TMC5160 over SPI on a SKR v1.3 for quite some time without any issue.
Due to a heatbed upgrade I moved to a 24v PSU and problems started.

Using the exact same klipper settings and same exact gcode that printed well before.
Few minutes into the print (1 or 2) one of the axis drivers shutdown in error, either Y or X.

Example from the DUMP_TMC command for the Y driver example.
[After ERROR]
11:55:47.966: // ========== Write-only registers ==========
11:55:47.966: // COOLCONF: 00020000 sgt=2
11:55:47.966: // IHOLD_IRUN: 00060303 IHOLD=3 IRUN=3 IHOLDDELAY=6
11:55:47.967: // PWMCONF: c40d001e PWM_OFS=30 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=4 PWM_LIM=12
11:55:47.967: // TPOWERDOWN: 0000000a TPOWERDOWN=10
11:55:47.967: // ========== Queried registers ==========
11:55:47.971: // GCONF: 00000004 en_pwm_mode=1
11:55:47.974: // CHOPCONF: 14410153 toff=3 hstrt=5 hend=2 tbl=2 tpfd=4 MRES=4(16usteps) intpol=1
11:55:47.980: // GSTAT: 00000007 reset=1(reset) drv_err=1(ErrorShutdown!) uv_cp=1(Undervoltage!)
11:55:47.986: // DRV_STATUS: 81036000 s2vsb=1 stealth=1 CSACTUAL=3 stallGuard=1 stst=1
11:55:47.991: // FACTORY_CONF: 0000000c FACTORY_CONF=12
11:55:47.995: // IOIN: 300000c0 SD_MODE=1 SWCOMP_IN=1 VERSION=0x30
11:55:47.999: // LOST_STEPS: 00000000
11:55:48.003: // MSCNT: 000000e8 MSCNT=232
11:55:48.007: // MSCURACT: 002300f4 CUR_A=244 CUR_B=35
11:55:48.011: // OTP_READ: 0000000c OTP_FCLKTRIM=12
11:55:48.015: // PWM_SCALE: 00000014 PWM_SCALE_SUM=20
11:55:48.019: // PWM_AUTO: 000d009f PWM_OFS_AUTO=159 PWM_GRAD_AUTO=13
11:55:48.023: // TSTEP: 000fffff TSTEP=1048575
11:55:48.023: ok

GSTAT: 00000007 reset=1(reset) drv_err=1(ErrorShutdown!) uv_cp=1(Undervoltage!)

I could assume it would be some hardware issue but after testing many things ended up installing marlin and it works fine with it. So it has to be a software (or driver configuration - more about it bellow).

I did noticed when setting Marlin that it includes settings for trinamic depending on the voltage so it leads me to conclude that either the drivers or the controller will work differently depending on the supply voltage. I'd expect that for the currents but check briefly scanning the code it also change other parameters.

/**

• Optimize spreadCycle chopper parameters by using predefined parameter sets
• or with the help of an example included in the library.
• Provided parameter sets are
• CHOPPER_DEFAULT_12V
• CHOPPER_DEFAULT_19V
• CHOPPER_DEFAULT_24V
• CHOPPER_DEFAULT_36V
• CHOPPER_PRUSAMK3_24V // Imported parameters from the official Prusa firmware for MK3 (24V)
• CHOPPER_MARLIN_119 // Old defaults from Marlin v1.1.9
  *
• Define you own with
• { */
  #define CHOPPER_TIMING CHOPPER_DEFAULT_24V

So it seems there are some timing issues that should be accounted for when using higher voltage supply, so far I did not find such settings in klipper.

[klipper-gitissuebot]

Hi @Nandox7,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Arksine]

The timing configuration is available in Klipper. In marlin it appears that CHOPPER_TIMING is referring to the TOFF, HEND, and HSTRT registers,

#define CHOPPER_DEFAULT_12V  { 3, -1, 1 }
#define CHOPPER_DEFAULT_19V  { 4,  1, 1 }
#define CHOPPER_DEFAULT_24V  { 4,  2, 1 }
#define CHOPPER_DEFAULT_36V  { 5,  2, 4 }
#define CHOPPER_PRUSAMK3_24V { 3, -2, 6 }
#define CHOPPER_MARLIN_119   { 5,  2, 3 }

```c
typedef struct {
uint8_t toff;
int8_t hend;
uint8_t hstrt;
} chopper_timing_t;

static constexpr chopper_timing_t chopper_timing = CHOPPER_TIMING;

But be careful, because it appears that Marlin is offsetting the hstrt and hend values before applying:
```c
#if HAS_DRIVER(TMC5160)
  template<char AXIS_LETTER, char DRIVER_ID, AxisEnum AXIS_ID>
  void tmc_init(TMCMarlin<TMC5160Stepper, AXIS_LETTER, DRIVER_ID, AXIS_ID> &st, const uint16_t mA, const uint16_t microsteps, const uint32_t thrs, const bool stealth) {
    st.begin();

    CHOPCONF_t chopconf{0};
    chopconf.tbl = 1;
    chopconf.toff = chopper_timing.toff;
    chopconf.intpol = INTERPOLATE;
    chopconf.hend = chopper_timing.hend + 3;
    chopconf.hstrt = chopper_timing.hstrt - 1;

Best I can tell, their settings at 24V for the TMC5160 are:
driver_TOFF: 4
driver_HEND: 5
driver_HSTRT: 0

[wesk-ms]

That GSTAT error is present at all times on my SKR 1.1 Pro with TMC5160s all around. Doesn't matter if it is before homing, after homing, while printing, or immediately after turning on the printer. That error is always present...on each driver.

From what I can tell, the GSTAT register never gets initialized correctly, so it always returns a bogus status.

I'm seeing a similar issue where my Z axis stops advancing randomly during a print. In my case, the build plate stops lowering away from the nozzle. I have a coreXY printer with two nema 23 Z axis steppers driven with independent TMC5160 drivers. When the Z steppers stop working, Klipper doesn't detect any kind of error condition, so the printer still continues to print. Sometimes the Z steppers will start working 10-15 layers later, but at that point the nozzle has already knocked the print loose and has buried itself in a ton of melted filament that's still being extruded. Frustrating!!

I'm also using 24V for the steppers. The TOFF, HEND, and HSTRT registers only pertain to Spreadcycle mode and not Stealthchop. I have stealthchop_threshold set to 200 and only print at 100mm/s, so I'm always printing in Stealthchop mode (assuming Klipper is setting the TMC5160 registers correctly).

This weirdness has been reported several times now and there was a pull request that wasn't ever committed that should have fixed the GSTAT issue. Apparently, the author disengaged since the pull request was never committed and recently closed.

1952

1797

2243

Some common workarounds in these issues have been to reduce the microsteps, which makes me think there might be a data throughput issue. But I would there would be plenty of headroom using Klipper on the newer 32bit boards.

[schnello]

@Nandox7

Same problem here but not exacly the same config.
TMC2208 via UART
SKR Pro 1.1
Motor V: 24V

DUMP_TMC stepper_z
========== Write-only registers ==========
IHOLD_IRUN: 00081814 IHOLD=20 IRUN=24 IHOLDDELAY=8
TPOWERDOWN: 00000014 TPOWERDOWN=20
TPWMTHRS:   00000177 TPWMTHRS=375
========== Queried registers ==========
GCONF:      000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
GSTAT:      00000003 reset=1 drv_err=1(ErrorShutdown!)
IFCNT:      00000005 IFCNT=5
OTP_READ:   0000000c OTP_FCLKTRIM=12
IOIN@TMC220x: 20000150 DIAG=1 PDN_UART=1 SEL_A=1(TMC220x) VERSION=0x20
FACTORY_CONF: 0000000c FCLKTRIM=12
TSTEP:      000fffff TSTEP=1048575
MSCNT:      00000144 MSCNT=324
MSCURACT:   019b00e1 CUR_A=225 CUR_B=-101
CHOPCONF:   03030053 toff=3 hstrt=5 TBL=2 vsense=1 MRES=3(32usteps)
DRV_STATUS: c0140010 s2vsa=1(LowSideShort_A!) CS_ACTUAL=20 stealth=1 stst=1
PWMCONF:    c80d0e24 PWM_OFS=36 PWM_GRAD=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=8 PWM_LIM=12
PWM_SCALE:  0000001e PWM_SCALE_SUM=30
PWM_AUTO:   000f002f PWM_OFS_AUTO=47 PWM_GRAD_AUTO=15

But in my case i have this issue the first time after the upgrade to the latest version. ATM i checked out a 2 weeks old state and perform some test prints (c36fe76d692754d0244059a729e147c688c96062)

Edit:
Testprint 1 OK
Testprint 2 OK
Testprint 3 OK
Back to the latest Version
Testprint failed...

[Nandox7]

@Arksine yep that was my first approach. Try and calculate the values from the code and I did notice that offset applied to the TMC5160. Still no luck or I just got the rest of the values wrong.
So I moved ahead and installed Marlin just to get them right and to test.

Got this:

23:57:26.756: Y
23:57:26.757: GCONF 0x00:00:00:04
23:57:26.757: IHOLD_IRUN 0x00:0A:10:08
23:57:26.757: GSTAT 0x00:00:00:05
23:57:26.757: IOIN 0x30:00:00:D2
23:57:26.757: TPOWERDOWN 0x00:00:00:80
23:57:26.758: TSTEP 0x00:0F:FF:FF
23:57:26.758: TPWMTHRS 0x00:00:00:00
23:57:26.758: TCOOLTHRS 0x00:00:00:00
23:57:26.759: THIGH 0x00:00:00:00
23:57:26.759: CHOPCONF 0x14:00:82:84
23:57:26.759: COOLCONF 0x00:03:00:00
23:57:26.759: PWMCONF 0xC8:0D:0E:24
23:57:26.759: PWM_SCALE 0x00:00:00:08
23:57:26.760: DRV_STATUS 0x80:08:40:00
23:57:26.760: Testing Y connection... OK

23:59:00.359: Y
23:59:00.359: Enabled false
23:59:00.359: Set current 580
23:59:00.360: RMS current 572
23:59:00.360: MAX current 807
23:59:00.361: Run current 16/31
23:59:00.361: Hold current 8/31
23:59:00.361: Global scaler 133/256
23:59:00.361: CS actual 8/31
23:59:00.361: PWM scale 8
23:59:00.362: stealthChop true
23:59:00.362: msteps 16
23:59:00.362: tstep max
23:59:00.362: pwm
23:59:00.362: threshold
23:59:00.362: [mm/s]
23:59:00.362: OT prewarn false
23:59:00.363: off time 4
23:59:00.363: blank time 24
23:59:00.363: hysteresis
23:59:00.363: -end 2
23:59:00.363: -start 1
23:59:00.363: Stallguard thrs 3
23:59:00.364: DRVSTATUS Y
23:59:00.364: stallguard
23:59:00.364: sg_result 0
23:59:00.364: fsactive
23:59:00.364: stst *
23:59:00.364: olb
23:59:00.365: ola
23:59:00.365: s2gb
23:59:00.365: s2ga
23:59:00.365: otpw
23:59:00.365: ot
23:59:00.365: Driver registers:
23:59:00.366: Y 0x80:08:40:00
23:59:00.366: Testing Y connection... OK

In terms of timing you say Klipper has that option?

@wesk-ms the error I mention is: drv_err=1(ErrorShutdown!) the other two yes are always there.

TMC5160 datasheetstate that when there is a error to look into the DRV_STATUS register.

DRV_STATUS: 81036000 s2vsb=1 stealth=1 CSACTUAL=3 stallGuard=1 stst=1
In this case I see s2vsb=1 that states "short to supply indicator phase B "

I'm assuming this is down to the timing settings of the driver or something with klipper timings when running on 24v as with 12v it does not happen.
I also have the Z loosing some steps in one side and I'm using single driver but that is over long time.
In this case is quite noticeable as you her this "click" noise and the stepper stops moving. The print continues as there is no error in Klipper but of course is all going bad as i does not move out of place on the Y or X axis. I after have to restart the firmware so the driver state gets reset.

About the Stealthshop settings check if you have the latest code version I notice in the changelog a recent commit to fix a problem setting Stealthchop hreshold setting.
https://github.com/KevinOConnor/klipper/commit/7d76067ff9efaf75808b05f768dfef4295251ede

[Arksine]

Marlin's "timing" settings reference the hysteresis and toff registers, so yes, you can configure those registers in Klipper. However @wesk-ms is correct, if you are running in Stealthchop mode those settings do not apply, they are used for Spreadcycle.

FWIW, its unlikely that this issue is related to throughput. Klipper pulses the step pin like it would any other driver, the SPI interface is only used during configuration and when the user initiates a query (such as DUMP_TMC). This issue sounds similar to the issue the TMC2208 has in stealthchop mode.

https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print

[Nandox7]

I tried to increase the stealthchop_threshold to a value quite high.

Initial:
stealthchop_threshold: 250
after
stealthchop_threshold: 5000

That I believe it will prevent stealthshop from get used, done this because reading other logged issue there was reports of steps skipped when the driver makes the transition between spreadcyle <> stealthchop.

[Nandox7]

Update:
Followed the same idea as @schnello and reverted to a old commit of Klipper.
Went a bit far back, Dec 1st: https://github.com/KevinOConnor/klipper/commit/41dd53f62ccd94e6ebb621b7de269887182ef433

And it printed well, first full print I can do at 24v as before all attempts failed 100% of the time.
Setting now to print a second time just to make sure I wasn't just lucky.

Update 2:
Second print went fine as well.
I'll move to a slightly newer commit to see if I can still get it printing. As well as diff the TMC and TMC5160 files to spot any big change.

[schnello]

@Nandox7
With stealthchop_threshold: 250?

[Nandox7]

Yes,
This is the settings I have now, pretty much all default and that wasn't working with the latest code.

[tmc5160 stepper_y]
cs_pin: P1.15
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
diag1_pin: !P1.27
driver_SGT: 4
microsteps: 16
interpolate: True
run_current: 0.800
hold_current: 0.500
stealthchop_threshold: 250

[wesk-ms]

The stealthchop_threshold setting controls the speed at which the driver switches FROM stealthchop TO spreadcycle. Not the other way around.

Setting stealthchop_threshold: 5 would keep you in spreadcycle 100% of the time, most likely.

[Nandox7]

But I think that was the way I understood it, setting it quite high stealthchop would never be used and it would remain always in spreadcycle.
I'll set to 5 in X and Y and give it a try.

Either way using last December Klipper code kept the printer printing well all day yesterday.
Today I'll try to advance a bit more and use early January code to see what happens.

[schnello]

@Nandox7
If you want disable the stealthchop mode... use stealthchop_threshold: 0

stealthchop_threshold: 0
  The velocity (in mm/s) to set the "stealthChop" threshold to. 
When set, "stealthChop" mode will be enabled if the stepper motor velocity is below this value.
The default is 0, which disables "stealthChop" mode.

[GarthSnyder]

@Nandox7, you might find git bisect helpful. It automates the process of hunting for a change in behavior. You still make the determination for each commit, but git keeps track of all the bookkeeping.

[Nandox7]

@schnello ok, so is the inverse. Thanks

@GarthSnyder that will be helpful thanks. I'll check that feature.
Better than my current method "visual binary search".

Quick check of tmc.py and tmc5160.py against the repo head ddin't show much.
For tmc5160.py the change is minimal and for tmc.py there was the introduction of code that I uses the GSTAT register as a homing sensor. (instead of the diag1 pin for stalguard).

[BoHoehne]

I can confirm this behavior for a SKR Pro v1.1 and TMC5160.
I have a titan extruder.
By placing my finger between the big gear and the filament string, i recognized that the extruder motor seems to "fall asleep" on parts with little or intermited extrusion.

Funny thing is, i can wake it (the extruder) up by pushing the gear slightly.

Unable get any print done successfully.

[wesk-ms]

@BoHoehne, That is interesting. What you're describing sounds like there's little to no holding current on your extruder stepper. Is that correct?

I've noticed that while printing, I can easily rotate my Z axis ballscrews between layer changes, which shouldn't be possible due to the holding current. I believe that Klipper's default IHold setting is equal to the IRun setting, unless you specify otherwise by setting hold_current: in the config. I think we all need to test a bit more to see if this issue is related or possibly a new issue.

[BoHoehne]

@wesk-ms
These are my settings:
run_current: 0.85
hold_current: 0.5
microstepps: 16

[Nandox7]

@BoHoehne, sounds like a different issue.
In my case the driver shuts down during print and does not move anymore.
Only way to make it work again is to reset Klipper so the TMC init() process runs again, usually I do it using FIRMWARE_RESTART.

Has reference I also have a Titan extruder with a 0.9deg/step stepper.
And I have it running with about the same settings.
run_current: 0.8
hold_current: 0.5

[BoHoehne]

I observed the very same behavior described.
The stepper driver on the extruder is also a 5160 @ 24v.

My only workaround to avoid it was to change the model to have less detail, rotate the z axis of the model and disable stealthchop entirely:

[tmc5160 stepper_x]
cs_pin: PA15
spi_bus: spi3a
diag1_pin: ^!PB10
microsteps: 16
run_current: 0.800
hold_current: 0.500
stealthchop_threshold: 0
sense_resistor = 0.075
driver_SGT: 2

After doing that, i ran into the problem i described earlier.
The extruder being:

[tmc5160 extruder]
cs_pin: PB3
spi_bus: spi3a
diag1_pin: PE15
microsteps: 16
interpolate: True
run_current: 0.850
hold_current: 0.500
stealthchop_threshold: 0
sense_resistor: 0.075

I event tested different microstep settings to see if the behavior changed.
Only to discover that the torque applied is getting weaker when reducing the microsteps to less than 16 microsteps (strange). I also tried disabling the interpolation, which did not change anything.

To my impression the extruder "falling asleep" is kind of the little sister of extruder shutdown.

[schnello]

I performed now "some" testprints.

My result is:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[67b285224952749583d7bb3af3eb6397f63b492e] tmc: Query the stepper step_distance from the stepper object

After the commit 67b285224952749583d7bb3af3eb6397f63b492e iam unable to print. Can anyone confirm that?

[KevinOConnor]

After the commit 67b2852 iam unable to print. Can anyone confirm that?

Can you provide a log file from a failed print, along with the log file of a successful print? Without log files, there's very little we can do.

FYI, there was an issue with commit 67b2852 that should have been fixed with commit 7d76067f.

-Kevin

[schnello]

Attached a error log.

Log with a successful print and a log with the latest version is in work.
klippy_bad.log

klippy_good.log

[schnello]

@KevinOConnor
Sorry for the delay: Here the log with the latest rev and failed.
Inter. point: The first print was ok but with the non default setting driver_TPOWERDOWN: 40. The second print with default driver_TPOWERDOWN was failed.

Note: all other logs are done with driver_TPOWERDOWN: 40
latestrev_bad.log

Edit:
A third try with the latest rev and driver_TPOWERDOWN: 40 are failed now

[KevinOConnor]

@schnello - your drivers are tmc2208 and not tmc5160. I'd guess you're hitting the issue described at https://www.klipper3d.org/FAQ.html#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print . I'm not sure what speed your print is at, but you may want to try reducing your maximum XY velocity to 100 and set the stealthchop_threshold to 110 (the stealthchop velocity needs to be larger than the [printer] max_velocity and it needs to be only slightly larger than it). You may also want to consider disabling stealthchop entirely.

-Kevin

[schnello]

@KevinOConnor
I fall back again to c36fe76d692754d0244059a729e147c688c96062 and it works fine.

If i remember right i disable already also the stealthchop. Didnt help.
The print himself is not a ultra fast speed. 30-60mm/s, the max is the travel speed with 90 mm/s.
So from my view... its a TMC problem in the code.

Edit:
Set to Vel to 100 and stealthchop_threshold to 110.. failed. Next try with stealthchop_threshold 0

[KevinOConnor]

@schnello - I've now fully reverted 67b2852 (with commit e03f75e7).

-Kevin

[schnello]

Thanks. Testprint startet and OK with the old settings.

[BoHoehne]

Ok here comes my result:

klippy.log.zip

The print was aborted after 5%, because it made no sense anymore.
The hotend was not blocked at any time.

[schnello]

@BoHoehne
Any reason why you use stealthchop_threshold = 30 for the first extruder and stealthchop_threshold = 0 for all others.

[BoHoehne]

Just testing whether it made a difference.
The result is the same if stealthchop_threshold is 0 for the first extruder.
I tested that last night.

[BoHoehne]

Just to summarize:
24v
SKR Pro 1.1
5x tmc5160
1x tmc2130 (z-axis)

Logfile and foto for stealthchop_threshold=0 comming soon.

[BoHoehne]

klippy.log.zip

This is the stealthchop_threshold: 0 version.
Btw i tested it with a bigtreetech 5160 v1.2 and a watterott 5160 on extruder with the same results.

[Nandox7]

Didn't had much time before but was able to test it now.
Checking the code with the latest commit e03f75e is working., so far did three prints (~2hrs each) without any axis driver stopping.
Before it would stop after 2/3min into the print (it would be during the same movement(s))

[BoHoehne]

Could you share your config file ?

[BoHoehne]

Unable to reproduce @Nandox7 pls share your config files.

[Nandox7]

Still convinced the problem you have is different.
This is what I have per driver:

[tmc5160 stepper_y]
cs_pin: P1.15
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
diag1_pin: !P1.27
driver_SGT: 3
microsteps: 16
interpolate: True
run_current: 0.600
hold_current: 0.500
stealthchop_threshold: 5

[BoHoehne]

@Nandox7 what i meant was the extruder configuration.

I just opened a new Issue #2551 for that problem.

[Nandox7]

@BoHoehne is the same, only stealthchop_threshold I kept at 250, I'll try later with 5.

[tmc5160 extruder]
cs_pin: P1.8
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
#diag1_pin: P1.28
microsteps: 16
interpolate: True
run_current: 0.600
hold_current: 0.500
stealthchop_threshold: 250

[klipper-gitissuebot]

It appears the Klipper log file was not provided.
I'm closing this now, sorry. Feel free to attach the log to this ticket sometime in the future, or create a new issue once you can provide the log file.

[Nandox7]

Dumb bot. :)
How does this get re-opened while further testing is done.

[Boffgithub]

@Nandox7 I think you tagged the wrong person :o)

[Mosher23]

so i have same issue.
i have skr 1.4 with 5 TMC5160
and 2 Drivers connected to 2 Z steppers turn off during printing. Both of them report "Error_shutdown"
klippy (1).log

[schnello]

@Mosher23
Should be solved with the latest version so update Klipper

[Mosher23]

@Mosher23
Should be solved with the latest version so update Klipper

i have installed my Klipper just yesterday

[schnello]

@Mosher23
Your log tells that the version is not up2date

Git version: 'v0.8.0-131-g00fd6223

[Nandox7]

Look into the FAQ: How to upgrade the code.
https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#how-do-i-upgrade-to-the-latest-software

You using the latest package that is from Oct'19.

[Mosher23]

just updated the Klipper and tried printing. same issue!
klippy-2.log

[wesk-ms]

Perhaps you should read the section in the FAQ about how to update Klipper to the latest software. Your most recent log still shows that you are running a build from last October.
Git version: 'v0.8.0-430-gfc627ec4' CPU: 4 core ARMv7 Processor rev 3 (v7l) Python: '2.7.16 (default, Oct 10 2019, 22:02:15) \n[GCC 8.3.0]

Follow these steps: How do I upgrade to the latest software?

When you see (default, Apr 24, xx:xx:xx) in your klippy log, then you're on the latest version.

[Mosher23]

So i did it like in that FAQ and now i have 'v0.8.0-433-g9730be8e'
What you are referring to is Python: '2.7.16 (default, Oct 10 2019, 22:02:15)

So perhaps you should not comment, if you have no idea

[alanbithell]

I'm having the same issue with my 24v Rumba board, TMC5160 (Bigtreetech v1.2) and I cannot put more than 1A of run current into the steppers before they cut out. When I initialize them at 1.0A or less they work, but DUMP_TMC reports this

Recv: // ========== Write-only registers ==========
Recv: // COOLCONF:   00000000
Recv: // GLOBALSCALER: 00000054 GLOBALSCALER=84
Recv: // IHOLD_IRUN: 00061f05 IHOLD=5 IRUN=31 IHOLDDELAY=6
Recv: // PWMCONF:    c40d001e PWM_OFS=30 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=4 PWM_LIM=12
Recv: // TPOWERDOWN: 0000000a TPOWERDOWN=10
Recv: // ========== Queried registers ==========
Recv: // GCONF:      00000000
Recv: // CHOPCONF:   14410153 toff=3 hstrt=5 hend=2 tbl=2 tpfd=4 MRES=4(16usteps) intpol=1
Recv: // GSTAT:      00000005 reset=1(reset) uv_cp=1(Undervoltage!)
Recv: // DRV_STATUS: 011f0000 CSACTUAL=31 stallGuard=1
Recv: // FACTORY_CONF: 0000000b FACTORY_CONF=11
Recv: // IOIN:       30000042 REFR_DIR=1 SD_MODE=1 VERSION=0x30
Recv: // LOST_STEPS: 00000000
Recv: // MSCNT:      000000fa MSCNT=250
Recv: // MSCURACT:   002100f5 CUR_A=245 CUR_B=33
Recv: // OTP_READ:   0000000b OTP_FCLKTRIM=11
Recv: // PWM_SCALE:  0000001d PWM_SCALE_SUM=29
Recv: // PWM_AUTO:   0000001d PWM_OFS_AUTO=29
Recv: // TSTEP:      00000832 TSTEP=2098

Why would Undervoltage be set?

After they stop moving I get

Recv: // ========== Write-only registers ==========
Recv: // COOLCONF:   00000000
Recv: // GLOBALSCALER: 00000054 GLOBALSCALER=84
Recv: // IHOLD_IRUN: 00061f05 IHOLD=5 IRUN=31 IHOLDDELAY=6
Recv: // PWMCONF:    c40d001e PWM_OFS=30 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=4 PWM_LIM=12
Recv: // TPOWERDOWN: 0000000a TPOWERDOWN=10
Recv: // ========== Queried registers ==========
Recv: // GCONF:      00000000
Recv: // CHOPCONF:   14410153 toff=3 hstrt=5 hend=2 tbl=2 tpfd=4 MRES=4(16usteps) intpol=1
Recv: // GSTAT:      00000005 reset=1(reset) uv_cp=1(Undervoltage!)
Recv: // DRV_STATUS: e0050000 CSACTUAL=5 ola=1(OpenLoad_A!) olb=1(OpenLoad_B!) stst=1
Recv: // FACTORY_CONF: 0000000b FACTORY_CONF=11
Recv: // IOIN:       30000052 REFR_DIR=1 DRV_ENN=1 SD_MODE=1 VERSION=0x30
Recv: // LOST_STEPS: 00000000
Recv: // MSCNT:      00000218 MSCNT=536
Recv: // MSCURACT:   010b01db CUR_A=-37 CUR_B=-245
Recv: // OTP_READ:   0000000b OTP_FCLKTRIM=11
Recv: // PWM_SCALE:  00000005 PWM_SCALE_SUM=5
Recv: // PWM_AUTO:   0000001d PWM_OFS_AUTO=29
Recv: // TSTEP:      000fffff TSTEP=1048575

[eehusky]

The UV gets tripped when the charge pump starts getting out of regulation and can be caused by any number of fun little layout issues that can pop up when larger AC currents get involved. There are some notes in the data sheet regarding the layout. It could also be caused by the VMOT supply fluctuating if there isnt enough bulk capacitance on the base board.

For what its worth I am having the same issue with the same setup (but using an SKR Pro). I just ordered some of the official trinamic step sticks off digikey and if they have the same problem Im going to ask them about it. The schematics look the same but I cant find the artwork for the bigtree version to see how they laid everything out. They also havent uploaded schematics for their 1.2 revision yet.

I've gone through their [Trinamic] spreadsheet to calculate the nominal chopper values and copied the register values Marlin uses but can't seem to get past this. Guessing I will need to bust out the old OScope before all is said and done.

Im curious....If after startup you clear the reset and uv_cp flags does the uv_cp show up again when your stepper stops working? (The registers is a W1C) Having a UV showup on startup isnt necessarily a problem.

SET_TMC_FIELD STEPPER=stepper_x FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=stepper_x FIELD=uvcp VALUE=1
SET_TMC_FIELD STEPPER=stepper_y FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=stepper_y FIELD=uvcp VALUE=1

Should now report no flags in the GSTAT field until it is tripped again.
DUMP_TMC STEPPER=stepper_x

[jffmichi]

Did anyone get the TMC5160s to work reliably? I'm currently trying to get the Bigthreetech v1.2 ones working on a small test board with an Arduino before I put them into anything more complicated and I'm starting to loose my mind.

For currents of up to about 1.0A or when in StealthChop mode they seem to work just fine during testing. I tested both a Nema 17 and a Nema 23 stepper motor. As soon as the driver switches into SpreadCycle (either due to not setting the en_pwm_mode bit or due to TPWMTHRS) when using more than 1.0A the problem described above starts to occur. Driver shuts down after a few seconds and uv_cp, ola and olb bits get set. When that happens I can't reset the driver in software. Neither setting ENN pin HIGH, TOFF=0 or trying to write clear the uv_cp flags work. I have to cut 24V power to the VM pin. I can however drop VM to 5V (schottky diode between VIO and VM) and then give back 24V to the driver and it starts working again for a short time. The problem does not seem to occur when running the motor at higher rpm, i.e. well above 120. When accelerating fast the driver mostly manages to reach that rpm region but not always. Also writing anything to DRV_CONF (even the default values) seems to make the problem worse and the driver doesn't even work with 1.0A or below any more. I double and triple checked that the values are correct.

I tried to figure out what's going on and did some measurements of the charge pump voltage during operation. As you can see in the screenshots the charge pump voltage drops a little when running at higher rpms and in SpreadCycle mode but this doesn't seem to be a problem for the driver. When running at lower rpm in SpreadCycle mode the charge pump voltage suddenly drops down to 24V and the described symptoms arise. However, I somehow doubt that the charge pump voltage dropping is the cause of the issue as the issue happens when the charge pump voltage seems to be at a reasonable value.

StealthChop (120rpm, working correctly):

SpreadCycle (120rpm, driver shuts down):

SpreadCycle (480rpm, accelerate and decelerate, driver shuts down):

SpreadCycle (480rpm, fast accelerate and hold for a while, working correctly but sometimes shuts down during acceleration/deceleration):

Also no other settings seem to really influence the described problem. I tested a lot of different values for the registers that seem to make sense, e.g. different chopper config timings from the Marlin firmware or default values from the datasheet. I also tried disabling the short-to-ground and short-to-vs detection and quite a few other things but nothing worked so far... I'm not sure if it's even a software or setting issue at this point or if the drivers from Bigtreetech are just bad in this case...

@eehusky: did you test the official step stick drivers and did it make a difference?

[langwadt]

might be obvious but, is the clock pin connect to ground?

[jffmichi]

@langwadt: unfortunately that doesn't seem to be the issue. I have it manually tied to ground and also it should be tied to ground through a resistor according to some text from Bigtreetech I remember to have read a few days ago. I measured 10kOhm to ground so seems to be correct. For me it didn't make a difference what I do with it anyway: I tried leaving it open or even pulling it to vio.

I also tried three TMC5160 v1.2 from Bigtreetech and all show the same symptoms so as far as I can tell it doesn't seem to be a single bad part.

[alanbithell]

To get around the issue I ended up setting run current to 1.0A in the config and then in my gcode start script I put
SET_TMC_CURRENT STEPPER=stepper_x CURRENT=2.0
for each axis. The only time the steppers have tripped since is when I left my board cooling fan off and they must have overheated.

[eehusky]

@jffmichi Thanks for the scope shots, give me something to compare too.
The drivers are sitting on my desk but haven't had an opportunity to swap them out yet. I should be able to do it this weekend though. I did read this the other day on the reprap wiki and it could be whats causing our problems. https://reprap.org/wiki/StepStick#Repair_Attempts

If they ran these through an oven profiled for a 4 layer PWB assembly you can definitely run into problems when ICs have exposed pads under the chip with a lead free process...you need to let them soak a bit longer. (It looks like they moved the 5160 step sticks to a six layer board)

@alanbithell One thing i did notice when poking around in the tmc5160.py file is that the SET_CURRENT gcode doesnt appear to be changing the global scalar so I'm not sure you are actually running at 2.0A? I think that is actually a bug in the klippy software but isnt related to this problem.

[alanbithell]

@eehusky I noticed the register wasn't changing too, but setting current to 0.2A definitely reduced the current because my Motors started skipping like crazy. So I'm not sure what's going on there, Ill have to dig around and see what its actually doing.

[eehusky]

@alanbithell Thats correct, you can decrease the current settings but you can't increase them. The 5160 has an extra layer of current control. Setting GS (Global Scalar) to some value, lets say 84, and IRUN to 31 and IHOLD to 15 will drive 1000ma when active and 500ma when idle.

With the above values if you call SET_CURRENT with a value larger than what was initially configured there should be zero change in register settings or behavior. But if you call SET_CURRENT with a smaller value than whats stored in the configuration it will decrease the IRUN and IHOLD values with the same GS value.

The gist is for any desired current settings you want to maximize the IRUN and GS values while staying within some other boundary conditions. Below is a sample of what I came up with when i was sorting the math out myself. (This still needs a loop to decrease the initial CS value until a valid GS and CS value are reached.) Note that CS (Current Select) refers to either IRUN or IHOLD depending on which state the IC is currently in.

import math
RSense = 0.075
Vfs = 0.325
CS=31
# Absolute maximum current supported (determined by RSense Value)
# Formula from page 74 of TMC5160/TMC5160A DATASHEET (Rev. 1.13 / 2019-NOV-19)
Imax = (256/256) * ((CS+1)/32) *(Vfs/RSense)*(1/math.sqrt(2))
#Imax = (Vfs/RSense)*(1/math.sqrt(2))

# Requested Running Current Value
IRun = 1.0
# Requested Holding Current Value
IHold = 0.5

# Register Value for IRUN
IRUN = CS

# Register Value for IHOLD
# This is the percentage of IHold to IRun scaled to 0-31.  If Ihold == IRun then the values are the same.  This is also referred to CS throughout the documentation.
IHOLD = int((IHold/IRun)*(IRUN+1)) - 1

# Register Value for GLOBALSCALE
GLOBALSCALE = int((IRun / Imax) * 256 +0.5)
if GLOBALSCALE == 256:
    GLOBALSCALE = 0
elif GLOBALSCALE <= 31:
    raise Exception("uhoh: "+GLOBALSCALE)

if GLOBALSCALE <= 128:
    print("Sub optimal, but valid, value selected for GlobalScaler...Greater than 128 recommended, although there are no remarks as to why its better")

if IRUN <= 16:
    print("Sub optimal, but valid, value selected for IRUN...Greater than 16 recommended")

print(GLOBALSCALE)
print(IRUN)
print(IHOLD)

Output:

Sub optimal, but valid, value selected for GlobalScaler...Greater than 128 recommended
84
31
15

Just trying to save you some time, I already banged my head against this particular wall :)

[jffmichi]

@eehusky reminds me of the old baking graphics card in the oven thing. Definitely sounds like a possibility and the described symptoms also match.

The diagnosis is, they simply don't move the stepper, only at very low currents or only a second after turning them on (while they're cold).

However, if the drivers are indeed bad, fortunately I can still return them and buy from watterott for a few Euros more. Please let us know as soon as you find the time to try the new ones. Thanks in advance :)

[alanbithell]

I found this and it seems to have fixed my issue, I can run flat out at 3A now, not that I need 3A but its good to know.

[Nandox7]

Interesting, May try those params, in overrall my X and Y run quite cool but the double Z leave the steppers super hot.
And I'm using 0.5 and 0.3 as run and hold current, in those params it has 1 and 2.

I imagine is down to the value of hold_current? I mean in a cartesian printer that is the main different the Z will keep the movement locked for much longer than any of the other axis.

[SK-StYleZ]

I had same issues with the TMC5160 (bigtreetech) & SKR v1.3 like @alanbithell.
I couldn't push the 5160's beyond 35W (24V 1.5A & 35V 1A) - the stepper just stopped after few mm of motion.

Before the test runs i've resetted the "reset" and "uv_cp" flags like @eehusky mentioned - thanks for this hint!

SET_TMC_FIELD STEPPER=stepper_x FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=stepper_x FIELD=uv_cp VALUE=1
SET_TMC_FIELD STEPPER=stepper_y FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=stepper_y FIELD=uv_cp VALUE=1
SET_TMC_FIELD STEPPER=stepper_z FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=stepper_z FIELD=uv_cp VALUE=1
SET_TMC_FIELD STEPPER=extruder FIELD=reset VALUE=1
SET_TMC_FIELD STEPPER=extruder FIELD=uv_cp VALUE=1

Finally my machine is running on 35V@3A, this settings did the trick:

# from reddit
spi_speed: 1000000
driver_IHOLDDELAY: 6
driver_TPOWERDOWN: 10
driver_TBL: 2
driver_tpfd: 0
driver_pwm_autoscale: True
driver_pwm_autograd: True
driver_pwm_freq: 2
driver_PWM_GRAD: 0
driver_PWM_OFS: 0
driver_PWM_REG: 0
driver_PWM_LIM: 0

# 36V settings for TMC5160 taken from marlin
driver_TOFF: 5
driver_HEND: 5
driver_HSTRT: 3

Thanks a lot @alanbithell for the reddit link !!!

[Nandox7]

What type of machine do you have?
I had to drop run_current and hold_current down to 0.300 (running on 12v) or else the Z steppers would be so hot I couldn't touch them.

[SK-StYleZ]

It's an custom corexy with nema 23 motors - they do get warm but @ 3A (still can touch them).
My smaller machine is running on TMC2130 24V @ 1.2A run_current & 0.75A hold_current (z axis) without issues - the two motors are wired in series (i don't remember why i wired them in series).

Previously the 5160's were mounted on the same small machine without problems - running on 24V
@ max 1A => small machine no high torque need.

Did you set RSense to 0.075 Ohm? => sense_resistor = 0.075

[komandrik]

Did you set RSense to 0.075 Ohm? => sense_resistor = 0.075

this value is set by default in the configuration. Why write it again?

[Nandox7]

Ok, thanks with NEMA23 makes more sense.
I believe sense_resistor = 0.075 is the default value still at some point I've set it as well.

This got me curious and did some testing.
Using the settings bellow:
run_current: 0.500
hold_current: 0.400

Before: 12vPSU (+24v PSU for bed) > 60deg
After: 24v PSU for all > 31deg Celsius

Later even raised the run_current to 0.600 without a problem.
So feeding the drivers less voltage was making them got much higher in temp.

[jffmichi]

@SK-StYleZ thank you. As far as I can tell, setting tpfd=0 solved all problems with SpreadCycle. Of course some fine-tuning of the remaining parameters is still necessary but the driver doesn't shut down with uv_cp=1 any more. Writing to DRV_CONF still causes the described issues when operating in StealthChop mode but not when in SpreadCycle mode. Still weird... But when I don't write to DRV_CONF and set tpfd=0, it seems the driver is usable...

[alanbithell]

I spent hours last night going through every setting difference and came to the same conclusion. TPFD is the culprit

[SK-StYleZ]

@jffmichi thanks for digging deeper!
I've tested StealthChop too and i do get driver error (not "uv_cp=1" or "ola/olb") while SpreadCycle does a great job.
Going to do some more testing.

Is there a guide how to fine-tune?

[robthide37]

i made another issue about the default timing being backwards. I think their is alot of misinterpretation if you lookup spreadcycle an001 on the trinamic website it has a basic spreadcycle tuning guideline and i believe the marlin deaults are not adding anything but simply letting us know what the driver does to the values internally. Also hstrt cannot exceed 3 and th hend can range from 1 to 15 but that means that we only apply 0 to 14 because of the offset. long story short default should be around 2 hstrt and 5 hend and then you check for low speed movement and keep increasing hend until no more improvement . toff you increase until you hear the buzz from the pwm and then reduce one or two below to increase switching frequency above 15khz but keep lower than 40khz. Lastly total blank time needs to be based off of clock speed so 16mhz should be 1 or 2 they state going to low will mess the sine wave up so i don't recommend 1 unless have a scope to check. Also if still improving and at 15 total hysterisis then you can reduce toff 1 to increase frequency and start over with hend. Best to read the guide cause i am sure i just made a confusing mess out of the instructions. I will post link later its in the issue i posted about default values being wrong for tmc steppers if anyone needs asap