TMC 2208 drivers are disabled while printing

[Nume1977]

I have just installed klipper branch 20180220a on my Anycubic kossel delta with trigorilla board + RPi3b and a few lines after the print has started one of the stepper motors turns off (i can move it by hand)!
I have had this problem on X axis or Y axis (Z has not yet shown this situation).

Here is the log (from start to emergency stop)
klippy.zip

[michaelshiel]

I have the same printer with basically exactly the same config (except step_distance: .01041666666 for the extruder, mine is the mini with 96 steps per mm) with no problems. I can't see any issues in the log, are the stepper drivers overheating perhaps? They will disable themselves if they get too hot.

I also noticed there is a space between the ! and pin for your extruder direction, wouldn't cause this issue but the config parser might not like it.

[Nume1977]

I also have a kossel mini pulley version.
The stepper drivers have a graphic card cooler blowing air on them :)
How did you calculate the step distance? I cannot find any information on how to do that !
Also, can anyone share the pin configuration for a 12864 full graphic display?

[michaelshiel]

In the Anycubic version of the Marlin firmware the E steps was set to 96 per mm (steps/mm), and since Klipper wants it in mm/step you just divide 1 by the Marlin value, i.e. 1/96 = 0.01041666667.

I'm guessing you used to run Marlin on it and that didn't have any problems with the steppers stopping?

[grantp69]

Anycubic Delta Linear Plus running Klipper and the display config. No issues either. Does sound like a mechanical or driver issue. Sounds like a loose connection to me. The 12864 full graphics display isnt the standard display on the Anycubic Delta, not sure Klipper has support for it yet or even if it's being worked on. Sure someone will correct me if I am wrong.

[Nume1977]

Just did extensive testing, using several baud rates, different configs, always the same result, a little bit after the print has started one of the X or Y axis drivers is disabled and the print fails (only 2 axis move).
If i revert back to Marlin or MKDUO everything works fine and the same gcode prints for start to end.
I am suspecting that it a software bug when using the TMC2208 has they have dynamic stealthChop (maybe some internal safety is triggered?), i will test now by installing the original drivers and see if the problem continues.
I have also disabled the 12864 display, just in case it was conflicting and reverted back to the master branch...

[mitry1974]

I have the same problems with 2208 drivers - they stop to work with Klipper software and works well with Marlin. I have 2 versions with drivers - from Lerge and from Fysstec and have problems with both.
The drivers have active cooling, heatsinks are installed using thermal paste. So, that is problem for me.

[Nume1977]

Confirmed it is a software / firmware issue.
Any TMC2208 driver that is used with klipper will randomly get disabled mid print, resulting in failed print.

[dragonnn]

Maybe Klipper runs the driver 'faster' and they are overheating?

[Nume1977]

No, TMC drivers have forced ventilation, heat sinks and are cold to touch.
mitry1974 also reports having the same problem.
Are there any users that have TMC2208 drivers working?

[dragonnn]

Hmmm can you disable dynamic stealthChop via UART accessible on the drivers? Worth trying if this fixes it. And maybe the driver dump something over UART when the got power off.

[grantp69]

It is important to say how you have these drivers configured and how you are configuring them as there are quite a few options with these drivers and right now there so many variables at play here.

[mitry1974]

I use drivers with RAMPS 1.4+ Arduino Mega and Raspberry Pi 3. V ref is .8 volts.

[grantp69]

Are you using jumpers to configure the drivers or have you programmed them via UART? What mode are you using, spreadcycle or stealthchop 2?

[mitry1974]

I'm using jumpers, don't connect them via UART yet.

[Nume1977]

I have nothing configured or connected. Just plugged the drivers in as they come, i think the default mode is stealthchop 2.

[grantp69]

You should be able to work out what mode they are in by how the solder links are set-up on the drivers, this also includes the solder to enable or disable uart programming, you can not assume they are in one mode or another. If they are in Stealthchop 2 that might be the issue with Klipper. Are you able to configure them as Spreadcycle to see if you get the same issue?

[mitry1974]

Will try!

[mitry1974]

Does Klipper support tmc2208 drivers like Marlin?
Or I need to write some additional code to initialize and set up drivers via UART?

[grantp69]

Programming via UART is not possible at the moment via Klipper. Was you using Marlin to program them before you setup Klipper?

[mitry1974]

I don't try to progam that drivers yet. I use them "as is". I think - they works in "Stealthchop" mode. But I will try to connect them via UART in Marlin.

But anyway, I don't know how to fing that issue on Marlin - they works fine without UART "from the box".

[grantp69]

Please set your driver's to run spreadcycle with Klipper and report back on if this makes a difference.

[mitry1974]

Hi,

If Klipper can't set up drivers via UART, how can I do it?
It looks I can switch drivers in spreadcycle via UART only.

[grantp69]

You can use a standalone programmer, but that's not straight forward if you don't have one or use the solder links on the steppers. How depends on the type of TMC2208 you bought. Solder link configuration is something the supplier of of the drivers should be able to help with.

[dragonnn]

You can use separate arduino

[gryteklut1]

I was told that i should write here.
I run the TMC2208 without issue on my Trigorilla board.
Printing great without problemes using klipper.
Mine is forced into allways staying in Spreadcycle mode using UART and changing the default bits.
they also have active cooling.

[mitry1974]

I have drivers from FYSETC - https://ru.aliexpress.com/item/5pcs-TMC2208-Stepping-Motor-Mute-Driver-Stepstick-Power-Tube-Built-in-Driver-Current-1-4A-Peak/32817968874.html?spm=a2g0s.9042311.0.0.IC8XSU

I have another arduino, but, as I understand, to check that issue I need to write initialization code in Klipper. If I set up drivers via UART that settings will be undone after power off. So, I need to do them every time I start to print.

[Nume1977]

Here, some information on how to do it:
http://learn.watterott.com/silentstepstick/configurator/

mitry1974, the changes you make are saved inside the TMC2208 they will not disappear on power off!

I will also try this, once i receive the new TMC2208, because one got burned when the arduino due pins touched the metal frame of the printer :(

[mitry1974]

Thank you, will check!

[KevinOConnor]

@mattthebaker - if one has the uart hooked up, my theory is that the problem goes away as long as one sets a reasonable stealthchop_threshold parameter as described in #196 (comment) . Specifically, with a reasonable stealthchop_threshold, my theory is that these quick steps on a direction change would result in an instantaneous switch to spreadcycle mode and then back, which should be harmless.

So, I agree that step interpolation may influence the main problem, but once one has uart I think it's possible to avoid the issue without having to change that setting.

-Kevin

[Yannik]

@Artem-B Would you care to make a quick guide how to determine the correct PWM_GRAD with an oscilloscope? I'm currently not sure how to wire this up and what to look for.

[Artem-B]

It's pretty straightforward. I've bought a current sensor, wired IP+/IP- points in a break in the wire going towards one of the coils and connected oscilloscope between GND and VOUT.

Then you can observe the current through the coil during axis movement commands. The absolute value does not matter much. We mostly care about relative current amplitude throughout movement. There are three distinct phases -- acceleration, steady speed, deceleration. Acceleration/deceleration phases are affected by PWM_GRAD. If it's too low, you will see that the current amplitude is noticeably lower than that during constant speed phase. You need to adjust PWM_GRAD so that the current amplitude during acceleration is similar (or, maybe a bit higher) than that during the constant velocity phase. Or you can reduce acceleration which would allow the driver to deliver higher current throughout the acceleration phase.

[lekv]

@mattthebaker - if one has the uart hooked up, my theory is that the problem goes away as long as one sets a reasonable stealthchop_threshold parameter as described in #196 (comment) . Specifically, with a reasonable stealthchop_threshold, my theory is that these quick steps on a direction change would result in an instantaneous switch to spreadcycle mode and then back, which should be harmless.

So, I agree that step interpolation may influence the main problem, but once one has uart I think it's possible to avoid the issue without having to change that setting.

-Kevin

Today I found this not to be the case. After enabling and tuning pressure pdvance and a handful of successful prints, I had the extruder driver shut itself off during a print. I don't have stealthchop_threshold configured for the extruder at all, effectively running it in spreadcycle mode.

[extruder]
max_extrude_only_distance: 100.0
step_pin: ar26
dir_pin: !ar28
enable_pin: !ar24
# Calibrated 97 steps / mm
step_distance: 0.01030927835
nozzle_diameter: 0.400
filament_diameter: 1.75
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog13
control: pid
pid_Kp: 21.527
pid_Ki: 1.063
pid_Kd: 108.982
min_temp: 0
max_temp: 250
pressure_advance: 0.5
pressure_advance_lookahead_time: 0.010

[tmc2208 extruder]
uart_pin: ar65
microsteps: 16
# RMS at 100%
run_current: 0.709

I was surprised by this and I haven't had any issues with drivers disabling prior to turning on pressure advance. Skimming through the logfile I didn't see any error message. I'll try disabling interpolation as I'm otherwise out of ideas.

[KevinOConnor]

@lekv - there are a number of reasons that a trinamic driver may turn itself off. If you weren't using "stealthchop" then it's not due to this issue. If you see the failure again, you should run DUMP_TMC on the stepper to see if it is reporting an error (such as an over heating event). If you need further assistance, open a separate issue.

-Kevin

[lekv]

Thanks for the feedback @KevinOConnor. I configured the driver to use StealthChop mode and set stealthchop_threshold: 41. After a handful of successful prints, it shut itself off again. It also reports an error:

Send: dump_tmc stepper=extruder
Recv: // ========== Write-only registers ==========
Recv: // IHOLD_IRUN: 00081616 IHOLD=22 IRUN=22 IHOLDDELAY=8
Recv: // TPWMTHRS:   000000bd TPWMTHRS=189
Recv: // TPOWERDOWN: 00000014 TPOWERDOWN=20
Recv: // ========== Queried registers ==========
Recv: // GCONF:      00000101 I_scale_analog=1(ExtVREF) multistep_filt=1
Recv: // GSTAT:      00000003 reset=1 drv_err=1(ErrorShutdown!)
Recv: // IFCNT:      00000000
Recv: // OTP_READ:   00000010 OTP_FCLKTRIM=16
Recv: // IOIN@TMC220x: 2000034d ENN=1 MS1=1 MS2=1 PDN_UART=1 SEL_A=1(TMC220x) DIR=1 VERSION=0x20
Recv: // FACTORY_CONF: 00000010 FCLKTRIM=16
Recv: // TSTEP:      000fffff TSTEP=1048575
Recv: // MSCNT:      00000138 MSCNT=312
Recv: // MSCURACT:   01ac00e8 CUR_A=232 CUR_B=-84
Recv: // CHOPCONF:   14010053 toff=3 hstrt=5 TBL=2 MRES=4(16usteps) intpol=1
Recv: // DRV_STATUS: c01f0000 CS_ACTUAL=31 stealth=1 stst=1
Recv: // PWMCONF:    c80d0e24 PWM_OFS=36 PWM_GRAD=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=8 PWM_LIM=12
Recv: // PWM_SCALE:  00000022 PWM_SCALE_SUM=34
Recv: // PWM_AUTO:   001a0022 PWM_OFS_AUTO=34 PWM_GRAD_AUTO=26
Recv: ok

Based on the explanation from Bernhard from Trinamic, I imagine this could happen if the extruder changes velocity to quickly when using Pressure Advance (I didn't see this without PA configured):

I think, the reason for disabling of the TMC2208 driver could be

• a hard stop of the motor in stealthChop (Step frequency goes from a higher value, e.g. > 0.5 RPS to 0)
• an abrupt change of motor velocity (Step frequency goes from a higher value to a low value within a single step).

When using stealthChop, please always make sure, that you use velocity ramping. A hard stop will cut away motor back-EMF at once. As stealthChop is a voltage based chopper, it cannot respond to this at once, like spreadCycle. The result is an overcurrent, and the motor driver goes to overcurrent switch off, until it becomes disabled / enabled again.

To resolve the problem, please use at least a tiny velocity ramping, when hard stopping the motor, e.g. within a few / a few ten microsteps.

A subsequent print of the same .gcode file without any changes succeeded. Does that indicate that my issue is different from this one, e.g. overheating?

[KevinOConnor]

@lekv - we'd need the Klipper log file to assist. Please open a separate issue, as it does not appear related to this one.

-Kevin

[Vorchak]

I am experiencing a similar issue intermittently. I am using Klipper on a Geeetech A20M (GT2560) with TMC2208. When it occurs, the Y stepper stops responding while X and Z continue moving as expected. Moreover, I believe the Y stepper is no longer energized as I am able to push the bed back and forth. The behavior continues until I cancel the print which will issue an M84 disabling the steppers. After this G28 homing works again on all axis. At first I thought it was due to excessive speed or anything else causing the TMC2208 to overheat. However, that cannot be as there is forced cooling and I see that the driver is not hot. After further experimentation, I have found out that simple actions that as rotating the printed object 90 degrees will cause the problem to go away. Please let me know if you need logs and tell me how to get them. I will make sure to collect them the next time it happens. Additional info: the TMC2208 is in legacy mode with 1/16 steps. I believe that uses stealthchop 2 mode. Another evidence that this is not due to overheating is because it does not always happen and it can even print successfully at much higher speeds and over even longer periods of time. When it happens, it is the middle or early stages of the print, after about 20-50 layers. I have also confirmed the driver is not bad by switching it with other axis. The problem seems to be related to the motion or signals on the Y axis.

[jakep82]

Additional info: the TMC2208 is in legacy mode with 1/16 steps. I believe that uses stealthchop 2 mode.

This is a known issue with no solution, and it's been documented. You will continue to have print failures as long as you use these drivers in standalone mode.

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

[lunohod]

Do you know if the new TMC2209 is also affected by this issue?

[Vorchak]

I am not sure if the TMC2209 has the same issue; however, the odd thing is that I have tested the same print models with both klipper and marlin 2 and I only see this issue with klipper. I would much rather use klipper as it solves all of my other issues with marlin but this particular issue is a blocker. I am using the same parameters with both as far as I know. Also, why only Y axis? It does not seem to happen with X axis.

[Matou25]

Hi,

i use TMC2130 and during delta calibration motors disable randomly, sometime it's ok, sometimes not
klippy.zip
....
i try do to disable stealthChop, interpolation , but it was the same
update 12 oct 19
i had fan near tmc stepper, print and delta calibration work , it's strange because on marlin i can print same gcode file without fan and without issue....

[KevinOConnor]

With the merge of PR #2565 it is thought that Klipper will no longer have an issue with the tmc2208, even if the tmc2208 is in standalone mode.

-Kevin

[KevinOConnor]

Alas, it appears that PR #2565 was defective. I've reverted that PR (as of commit e872290). I hope to have a replacement in a week or so.

-Kevin

[KevinOConnor]

FYI, the updated work around in PR #2597 was merged a week ago. So hopefully this issue is now resolved.

-Kevin