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!

[mitry1974]

Nume 1977,

Did you try?

[gryteklut1]

I did that to mine when i got them. Using the software Nume1977 mentioned.

just connect it to your computer with at TTL to USB adapter and use the software.

It will force the default bits to be Spreadcycle instead of stealtchop2. So when you enable the driver it's allways in Spreadcycle mode.

[mitry1974]

Ok, thank you. Will do!

[KevinOConnor]

FYI, Klipper doesn't have any TMC2208 specific code. It just toggles the step pin and direction pin according to the desired velocity/acceleration of the requested moves.

Given Klipper works well with all other common stepper drivers, I'm inclined to believe this is something specific to the TMC2208. It would be great if someone can narrow down what state the driver gets into when it fails. At this point, I don't think this is a defect in Klipper.

Separately, at some point, it would be great to get TMC2208 UART support added to Klipper (as would TMC2130 support).

[melvinisken]

Just to make (some of) you aware: if you program the TMC2208 via the UART configurator, you are only able to program them ONCE. The settings are stored permanently. No chance of changing them afterwards. So use with caution. Quite some people broke their chips by programming wrong configurations. I also use 2208 and I will try to do some tests soon.

[mitry1974]

Really? So, if want to use UART to setup current I can do it only once a time?

[melvinisken]

Yes and no :-) There are two UART modes. Normal UART and UART-OTP. The normal UART programming isn't permanent but you have to set all parameters every power cycle. So if you change the stepper current for example, you need to do that every restart of the firmware. So the firmware needs to support the 2208 explicitly to communicate via UART continously (like new Marlin Versions do). If you don't have permanent UART communication you can use the UART connection for OTP (one time programming). You can use the configuration tool from Watterott which was mentioned above to configure the chips. But this can only be done once. This time, the settings are stored and available after each restart so the firmware doesn't need to support anything. I read a lot of posts from people that tried OTP but couldn't get the 2208 to work afterwards. So you should use this mode only if you know what you're doing and are sure that the selected settings will work.

[Nume1977]

As a side note, I was able to reproduce this same problem in Marlin firmware! During print, if i use babysteps fast and <> 0.7mm it will disable one of the drivers! This is a hardware problem, more noticeable in klipper because of it's raw power and the way it plans and moves, marlin is slower but the problem is there too :)

[dragonnn]

Hmmm so maybe we should contact Trinamic? Maybe the can help or would be interested in this if it is a hardware bug.

[Nume1977]

Dragonnn, I will report to them! Maybe it can be addressed for existing drivers or corrected in future versions.

I suspect it is due to the dynamic way the driver changes from stealthChop2 to spreadCycle. It could either be because the move information hits the threshold of changing the mode but it keeps floating too fast between stealthChop2/spreadCycle or because it hits the sweet spot of the threshold where the driver doesn't know what to do. Either way it will make the driver fail miserably ...

[melvinisken]

So the UART thing is not a hardware problem. It is designed that way. I never had problems using 2208 with Marlin (I use UART communication to control them).

Do you use the original boards (from Watterott) or chinese clones like FYSETC? If you don't use the Watterott boards, I highly suspect that's the fault of FYSETC and the like, not Trinamic.

[Nume1977]

I have emailed Trinamic, they are the makers of the driver and they have the ability ot shed some light if it is a driver chip problem or other hardware. I do use FYSETC clones, but i do not connect them via UART, so the tmc driver runs by itself! I will report back if Trinamic replies :)

[melvinisken]

Ok, but I think it will be a FYSETC problem, not a Trinamic one. FYSETC et al. use very cheap components beside the actual chip so I guess those might not stand the higher currents etc. Maybe someone can give a step by step guide to produce this error? If I find some time I can try to reproduce it with the original boards.

[Nume1977]

melvinisken, what are they saving at?? The board only has 7 capacitors + 5 resistors + 1 trimpot + the 2208...

These are the steps to make the error:

1. Have a delta printer, in my case Anycubic Pulley with trigorilla board + RPi 3B
2. Install TMC2208 drivers out of the box
3. Slice a calibration cube (20x20x20)
4. Print via octoprint @ 250000 speed
5. Wait a few layers and watch one of the drivers stop (printing the same GCode will always make the same driver x/y/z stop at the same place, changing model/ gcode options will make another fail on another layer)

[melvinisken]

That's only what I read about the quality of the chinese clones compared to the original boards. They also seem to have problems with worse cooling. But I cannot prove anything since I never had one of them (but it fits in my general experience with chinese quality control :-) . So they might be perfect as well.

Ok, I don't own a delta printer, so unfortunately I cannot rebuild the situation. As far as I know, delta printers do need more power (in terms of electricity as well as computing power), so that might be the reason why me (and the other guys of the CR-10 community I know of) never experienced such problems..

But if the failiure is always exact at the same position, I suggest that's no hardware fault, because that's too precise. If for example overheating etc. would cause the failure, that would not be the case. Maybe it something with too high acceleration or the like, where the driver is kicked out?

[KevinOConnor]

On Mon, Mar 12, 2018 at 03:22:21AM -0700, Nume1977 wrote:

melvinisken, what are they saving at?? The board only has 7 capacitors + 5 resistors + 1 trimpot + the 2208...

These are the steps to make the error:

1. Have a delta printer, in my case Anycubic Pulley with trigorilla board + RPi 3B
2. Install TMC2208 drivers out of the box
3. Slice a calibration cube (20x20x20)
4. Print via octoprint @ 250000 speed
5. Wait a few layers and watch one of the drivers stop (printing the same GCode will always make the same driver x/y/z stop at the same place, changing model/ gcode options will make another fail on another layer)

Interesting.

What would help is if someone could narrow down the offending g-code. For example, configure the printer to run without extruding (remove the extruder stepper enable line from printer.cfg, set the min_extrude_temp to zero) and modify the offending g-code file to not enable the heaters. See if the print (now in dry run mode) still causes the failure. Try to identify the layers that the failure occurs on, and prune the g-code so it just prints (in dry run mode) those layers. Continue to prune the g-code down until you find a small section of g-code that causes the failure (or causes it with high probability).

Klipper is very precise - if one can identify the offending sequence of g-code, then we should be able to identify the timing of step/dir pin signals that the tmc2208 doesn't like.

-Kevin

[dragonnn]

I have found something interesting. RepRapFirmware for Duet are getting TMC2208 support as external drivers and I spotted something interesting. The last firmware has a change called:

When using external stepper drivers the DIR signal is no longer changed before the step pulse has ended

As I can see this change is implemented in this file: https://github.com/dc42/RepRapFirmware/blob/fa55cdada75c00cac180e26a31e151ed18093abd/src/Movement/DDA.cpp Before that change they was a comment:

We assume that meeting the direction pin hold is not a problem for any driver type. This is not necessarily true.

Maybe this causes problems with TMC2208?

[Artem-B]

I believe I've ran into this issue with TMC2224. I'm using Marlin, but this thread seems to be most informative, so I'll add my observations here. Alas, my board is based on LPC1769, so klipper does not run on it yet (I think there's support in some forked repo. I'll need to check).

I have two cases where I run into this problem:

• If G28 X is the first command after power up, X moves to the end stop and the driver locks up. There's no bounce-and-go-to-the-endstop-slowly. After that X no longer responds to any movement commands. Disabling steppers appears to recover the driver. After that I can no longer reproduce the lockup. If there are any other X-axis movement commands, homing X does not lock up the driver.
• Quickly changing direction of extruder movement. In my case it's triggered by enabling LIN_ADVANCE in Marlin. Extruder driver locks after few seconds of printing, which involves rapidly cycling extrusion/retraction. I can see extruder moving back and forth and then abruptly stopping. I can see with the scope the step pulses and dir pin changing, but the motor is not moving. AFAICT, there's always few microseconds delay between DIR change and the step pulse.

I don't think that guaranteeing DIR not changing during STEP pulse alone will solve this issue. At the very least it didn't in my experiments. I've tinkered with the code and added additional delays before/after direction change. The results are rather perplexing. Adding 4us delay before/after DIR change didn't seem to change lockup pattern at all (checking with the scope, there was already ~2us delay around it before I've added more). However, when I bumped the delay to 50us, X axis started to lock up every time I homed it.

[Artem-B]

I've confirmed that the driver shuts down -- /EN signal is low, but the motor is freewheeling. I don't have UART hooked up to the driver, but looking at the datasheet, there are not that many possible reasons for the shutdown. One of them is a short detection. It's not quite clear what's considered to be a short, but reducing VREF to 0.45V (from 0.6) eliminated the problem for X-axis homing. I didn't test Extruder yet.

The manual for TMC2208 shows an interesting diagram on page 38. If I understand it correctly, StealthChop2 settings are not optimized until following things are done:

• driver is enabled + at least one step
• 130ms of stand-still
• move motor at medium velocity for ~100 full steps.

Those things will occur eventually, but apparently there are some corner cases that may cause problems until param optimization has finished. My guess is that in my case too-high current setting and lack of proper Stealthchop2 init resulted in tripping short circuit protection.

[Nume1977]

Artem-B thank you for your detailed information!

So from what I have understood the 2208 require a "Konami Code" for StealthChop2 to properly work on each power up. If that is true, then the firmwares must be told they have 2208 and must execute it, let's say, during the G28 command.

You also noticed reducing the VREF to 0.45 eliminated your X-axis lockup, wonder if it will make the 2208 print without failing too, i will have to test theory. Maybe the short detection monitors the power consumption of the driver, and if there is a quick spike it disables the driver, so reducing the current will avoid that problem too.

[Artem-B]

As far as I can tell, the tuning algorithm will often be satisfied via usual XYZ movement as you're likely to eventually have some standstill time and some linear movement time on each axis. That would depend on specifics, though. In my case the story ended as soon as X was homed during the print. It can be worked around by a start-up script which would intentionally enable motors, wait a bit, home and then do some movement on each axis. It's more problematic for extruder, which can't be moved until hotend is hot. Linear advance complicates things a bit further as there may be little continuous movement at medium velocity during normal print. That may explain my current problems with linear advance enabled. I'll try to disable stealthchop today and see if it indeed fixes the problem.

[KenshiHH]

just got the same issue, one stepper just shut down. installed the 2208 a few days ago and some times one driver shuts down, used the 2100 before that for weeks with klipper without any problems. i try to test the same gcode files again to see if its always happen on the same spot. board: mks gen 1.4 fysetc tmc2208 v1.0 corexy