TMC drivers will be full power when VIN is restored

General Discussion
1

Issue:
After powering the PSU off and on again with the board remaining powered via the RPi, when stepper movement is requested the extruder driver (at least) seems to be at full power and it becomes very hot does the stepper motor.
I’ve had driver thermal shutdowns on a non heatsink’ed driver and some stepper motors are rated well below the full power of a TMC2209 thus risking to be damaged.

The Duet 3 Mini 5+ is “different” from other boards as the enable pin is shared with all the drivers so when a X move is requested for example, the extruder driver is enabled.
Homing is not an issue to the other drivers because when asked to move, their settings are correct, only drivers that are not asked to move will wake up from the ENABLE pin and not be correct.

How to replicate:

  • Have RPi and PSU connected to board
  • Disconnect PSU
  • Connect PSU
  • Move X, home for ex
  • Extruder driver will go temperature sky high

A thermistor on a heatsink on top of the extruder driver:

Screenshot 2021-09-26 at 23.20.06
Screenshot 2021-09-26 at 23.20.06784×531 31.9 KB

The peak was stopped when i asked a move of the extruder driver (0.1mm was enough)

Setup:

  • Duet 3 Mini 5+ v0.9.1-759-gdcf8cb82
  • Raspberry Pi 3B v0.9.1-759-gdcf8cb82

I did some DUMP_TMC STEPPER=extruder

At boot:

// ========== Write-only registers ==========
// SLAVECONF: 00000200 senddelay=2
// IHOLD_IRUN: 00080a03 ihold=3 irun=10 iholddelay=8
// TPOWERDOWN: 00000014 tpowerdown=20
// SGTHRS: 00000000
// ========== Queried registers ==========
// GCONF: 000001c4 en_spreadcycle=1 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
// GSTAT: 00000001 reset=1(Reset)
// IFCNT: 00000007 ifcnt=7
// OTP_READ: 0000000c otp_fclktrim=12
// IOIN: 21000049 enn=1 ms2=1 pdn_uart=1 version=0x21
// FACTORY_CONF: 0000000c fclktrim=12
// TSTEP: 000fffff tstep=1048575
// MSCNT: 00000008 mscnt=8
// MSCURACT: 00f7000c cur_a=12 cur_b=247
// CHOPCONF: 14030050 hstrt=5 tbl=2 vsense=1 mres=4(16usteps) intpol=1
// DRV_STATUS: 80030000 cs_actual=3 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: 00000004 pwm_scale_sum=4
// PWM_AUTO: 000e0024 pwm_ofs_auto=36 pwm_grad_auto=14
// SG_RESULT: 00000000

When the driver is getting hot:

// ========== Write-only registers ==========
// SLAVECONF: 00000200 senddelay=2
// IHOLD_IRUN: 00080a03 ihold=3 irun=10 iholddelay=8
// TPOWERDOWN: 00000014 tpowerdown=20
// SGTHRS: 00000000
// ========== Queried registers ==========
// GCONF: 000001c4 en_spreadcycle=1 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
// GSTAT: 00000000
// IFCNT: 00000009 ifcnt=9
// OTP_READ: 0000000c otp_fclktrim=12
// IOIN: 21000248 ms2=1 pdn_uart=1 dir=1 version=0x21
// FACTORY_CONF: 0000000c fclktrim=12
// TSTEP: 000fffff tstep=1048575
// MSCNT: 00000007 mscnt=7
// MSCURACT: 00f7000a cur_a=10 cur_b=247
// CHOPCONF: 14030053 toff=3 hstrt=5 tbl=2 vsense=1 mres=4(16usteps) intpol=1
// DRV_STATUS: 801a01c1 otpw=1(OvertempWarning!) ola=1(OpenLoad_A!) olb=1(OpenLoad_B!) t120=1 cs_actual=26 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: 00000071 pwm_scale_sum=113
// PWM_AUTO: 000e0086 pwm_ofs_auto=134 pwm_grad_auto=14
// SG_RESULT: 00000000

Note CS_ACTUAL or actual motor current set to 26, when normally it is 3

After moving the extruder 0.1mm:

// ========== Write-only registers ==========
// SLAVECONF: 00000200 senddelay=2
// IHOLD_IRUN: 00080a03 ihold=3 irun=10 iholddelay=8
// TPOWERDOWN: 00000014 tpowerdown=20
// SGTHRS: 00000000
// ========== Queried registers ==========
// GCONF: 000001c4 en_spreadcycle=1 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
// GSTAT: 00000000
// IFCNT: 00000009 ifcnt=9
// OTP_READ: 0000000c otp_fclktrim=12
// IOIN: 21000048 ms2=1 pdn_uart=1 version=0x21
// FACTORY_CONF: 0000000c fclktrim=12
// TSTEP: 000fffff tstep=1048575
// MSCNT: 000001d8 mscnt=472
// MSCURACT: 010f003b cur_a=59 cur_b=-241
// CHOPCONF: 14030053 toff=3 hstrt=5 tbl=2 vsense=1 mres=4(16usteps) intpol=1
// DRV_STATUS: 80030000 cs_actual=3 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: 00000010 pwm_scale_sum=16
// PWM_AUTO: 000e0086 pwm_ofs_auto=134 pwm_grad_auto=14
// SG_RESULT: 00000002 sg_result=2

Attached klippy.log:
klippy (18).log (654.6 KB)

I asked on Discord for other boards with shared ENABLE Pin and was told the Duet 2. I have one around and might test to see if it happens also.

2

Alas, the TMC specs state that it is not valid to disable the motor power from the drivers while the IO power is still applied. In your case, this seems to be putting the drivers into an invalid state that is causing the above issue.

I’m not really sure there’s much the software can do here. You can manually issue an INIT_TMC command for all your drivers after you apply motor power again. It’s unclear if the software can actually fully reset the drivers if they get into an invalid state though.

-Kevin

3

I this case I recommend:

4

@koconnor we have been assured by Trinamic that providing IO power without VIN power is OK. However, without VIN power, Trinamic drivers lose their register settings.

All Duets can monitor VIN via an ADC channel. In RepRapFirmware, when VIN is too low, we force the /Enable line high. When VIN transitions from too low to sufficient, we reprogram all the registers of all Trinamic drivers, and only then set /Enable low. This ensures that we don’t try to apply current to the motors before they are programmed.

5

Interesting. What drivers was that? I’ve seen credible reports of the tmc2130s being damaged if VIO is provided while VIN is not and if the stepper is requested to move.

Right. Are they assured to reset their register settings when VIN is reapplied though? This is the critical part, because if the registers aren’t reset, there’s really no way to know what settings they are in. It’s unclear if the software can reset all the registers, because some are write-only and some internal registers may not be directly programmable.

Okay. It’s possible one could implement this type of board specific code in Klipper as well.

It may also be possible to “hack it” using Klipper macros (eg, by creating a “gcode_button” object using an analog input that calls INIT_TMC for all the steppers). That’d be super ugly though.

FWIW, if it was my hardware, I’d avoid “half-powerdowns” - as the alternative seems fragile to me. YMMV.

Cheers,
-Kevin

1 Like
6

I don’t recall which drivers we asked about, but I think at least the TMC2660 and TMC5160. I’ve never spotted anything in the datasheets of the TMC2660, TMC5160, TMC2208 or TMC2209 that says you can’t apply Vccio without Vmot. We’ve never had a problem with it. We’ve never used the TMC2130. Maybe the TMC2130 had that problem, and Trinamic designed their later drivers to avoid it.

We program all the registers that matter to us when the power comes up - that’s all the ones for which we don’t always use the default values.

Some users (especially those using an attached Raspberry Pi) wish to use separate 5V and 24V PSUs, and to turn off the 24V PSU when the printer is idle. So we support that.

7

The tmc2130 and tmc5130 docs both state in the “External Reset” section: Therefore VCC must not be switched off during operation of the chip. There is also wording about power sequencing of VCC earlier in the docs. It does look like the tmc2208 and tmc2209 wording is different (and indeed these chips do explicitly state that a Vs cycle will reset the chip).

To be clear, if you say this will work, then I accept it will work.

On the Klipper side, though, there isn’t a lot we can do if the tmc chip is reset and Klipper is not informed of it. We do perform a full tmc init on each tmc driver every time that driver is enabled.

The original poster here is reporting that Klipper failed to reinitialize drivers that are not enabled, not moving, and with no indication to Klipper that a reset occurred. I can’t think of any practical way for Klipper to do that unless someone writes board specific code (or possibly some board specific macros).

Cheers,
-Kevin

8

Just as a follow up, it occurred to me that Klipper could reinitialize (and actively monitor) all TMC drivers that have a shared enable line when any of those drivers is enabled. (In contrast, today Klipper only initializes and actively monitors a TMC driver when that driver is enabled.) A change like that would require some coding work, but may be more robust when shared enable lines are in use.

-Kevin

2 Likes