Klipper: 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

[FSP2692]

Did changing to spreadcycle help/solve it?

[velocityfactor]

I ran across this thread after buying some 2208's for my AnyCubic Kossel Plus with Klipper. So, I've been a little worried. Last night I installed 4 of the BlkBox BB-2208, and started printing. I've printed a calibration cube and the featured boat on Thingiverse. Currently printing a third item. No failures so far. Super quiet. I'm keeping my fingers crossed. If there's anything I can do to help debug this issue, please let me know.

[Nume1977]

Hi all!
I have a reply from Trinamic, that might help making a software/firmware related solution, here is their information:

Dear Rui,

sorry for the great delay in answering on this question - I just see this post unanswered after reading the question in the forum.

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.

Hope this helps!

Best regards / Viele Grüße,

Bernhard

Bernhard Dwersteg
CTO, Chip Design

TRINAMIC Motion Control GmbH & Co KG
www.trinamic.com

Registration Court / Amtsgericht: Hamburg, HRA 100972
Managing Directors / Geschäftsführer: Michael Randt, Bernhard Dwersteg, Dr. Lars Larsson, Dr. Tonio Barlage

[dragonnn]

Hmmm so this could be too high jerk value (junction_deviation)? Maybe the s-curve implementation could help with that too?

[KevinOConnor]

On Fri, Apr 20, 2018 at 07:54:46AM -0700, Nume1977 wrote:

I have a reply from Trinamic, that might shed some insight to this situation and help making a software related solution, here is their information:

[...]

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).

Thanks.

I can think of only two places in Klipper that would cause an abrupt
velocity change on a stepper - the motor stop after endstop homing and
the "junction deviation" cornering algorithm.

So, given the above, if you are seeing these freezes during a homing
operation then I'd reduce homing_speed. If you are seeing these
freezes during normal printing then I'd reduce junction_deviation.

On Fri, Apr 20, 2018 at 07:59:33AM -0700, Mateusz wrote:

Hmmm so this could be to high jerk value (junction_deviation)? Maybe the s-curve implementation could help with that too?

I doubt s-curves would help much. The s-curves don't impact homing
and they are applied after the junction deviation code.

-Kevin

[Nume1977]

Well, since the problem only seems to happen during printing, it points to junction_deviation. I never noticed this problem while homing my delta, because i use a reduced speed of 50mm/s, i don't like hitting the endstops at 100mm/s, they will break. (period).

[melvinisken]

I don't know if it helps, but I came across the TRAMS board from Trinamic, and the following document: "Application Note 046 - Adapting step/dir CNC firmware for ramp generators " https://www.trinamic.com/fileadmin/assets/Support/Appnotes/AN046-Adapting_step_dir_cnc_firmware_for_ramp_generators.pdf
Just remebered this thread talking about ramping for velocity control. But maybe this one is not applicable.

[Artem-B]

TRAMS board uses TMC5130 which has internal ramp generator. I.e. it can accelerate/run/decelerate all by itself without any microcontroller involvement beyond programming the ramp parameters and hitting "GO". It's sort of a klipper-on-the-stepper-driver. Alas, it's not directly related to this issue.

[KevinOConnor]

FYI, I've added an item to the FAQ (commit cd9e21e3).

[FromtonRouge]

Hello,

I have also some TMC2208 (in Legacy Mode with stealthChop) on my printer. I read the FAQ and I would like to mention that I had to definitively set square_corner_velocity: 0 in my printer.cfg to avoid my Y stepper motor to stop functioning. I don't know if it's normal to have an extreme setting like this. Did I lose something in print quality with this setting ?

At the beginning I just tried to print the famous benchy boat https://www.thingiverse.com/thing:763622 and I wasn't able to finish the print until I set a value of square_corner_velocity: 0.2 Note that the print stops always at the same layer on a specific location.

It worked for a week until I tried to print this thing : https://www.thingiverse.com/thing:2773536. Even with a value of square_corner_velocity: 0.07 I wasn't able to end the print. Setting it to 0 fix the problem.
And like before the print always end at the same location (layer 4 here).

I'm curious if someone can reproduce the stall with the same gcode. In the following zip you'll find the isolated layer that stalls my Y motor (TMC2208-easy-stall-no-extrusion.gcode) and also the entire process for reference (sliced with Simplify3D) :
TMC2208-stall.zip

If the fix to this is square_corner_velocity: 0 I can live with it ;)

[KevinOConnor]

Setting square_corner_velocity to zero will increase print times and it may result in some additional blobbing at corners (if not using pressure advance). Otherwise, it shouldn't adversely impact quality.

Just so I understand, the second picture above is from the file TMC2208-easy-stall.gcode, and you can reproduce driver stalls on the Y axis with it? If so, can you also provide the klipper log file from the event (as described at https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md ). Does the stall occur in the upper right hand corner (where the picture shows the horizontal extrusion)? What current did you set the tmc2208 driver to?

-Kevin

[FromtonRouge]

Setting square_corner_velocity to zero will increase print times and it may result in some additional blobbing at corners (if not using pressure advance). Otherwise, it shouldn't adversely impact quality.

Ok thanks, I'll try your pressure advance feature

Just so I understand, the second picture above is from the file TMC2208-easy-stall.gcode, and you can reproduce driver stalls on the Y axis with it?

Yes, exactly, I modified the gcode to isolate the problematic layer. Here is the log file after printing TMC2208-easy-stall.gcode (I canceled the print after the stall):
klippy.zip

Does the stall occur in the upper right hand corner (where the picture shows the horizontal extrusion)?

Yes, it's when the infill pattern touch the circle exactly

What current did you set the tmc2208 driver to?

The voltage is 0.8 V on the Y driver, I don't know the corresponding current for that voltage. I saw a formula in the TMC2208 datasheet but I don't know the Rsense value

[Artem-B]

You can figure out the value by looking at the resistors themselves. They will always be the largest resistors on the stepsticks and they will be placed next to the A1/A2/B1/B2 pins.
E.g. on this picture, those are R2 and R4 next to the top row of pins.

They are marked R110 which is 0.11 Ohm. Here's convenient decoder if you see some other marks. https://www.hobby-hour.com/electronics/smdcalc.php says it's

[FromtonRouge]

Thank you :) so from the formula given by https://www.trinamic.com/fileadmin/assets/Support/Appnotes/AN045-How_to_replace_Allegro_A4988_with_TMC2208_01.pdf I found a current of 566 mA for Vref=0.8V
I'll try a current of 800 mA (Vref=1.13V) and see if the stall occurs

[KevinOConnor]

@FromtonRouge - before making a current change, could you run a test for me?

I'm concerned there may be a bad interaction between Klipper's step rounding, the TMC's step interpolation, and the TMC's new speed adjusted power in StealthChop2.

Can you cut-and-paste this sequence into a gcode file and see if it fails:

G28
;SET_GCODE_OFFSET Y=0.005
G1 X8.0 Y10.0 F3000
G1 Z0.4 F3000
G1 X207.198 Y152.599
G1 X204.984 Y154.813
G1 X204.687 Y154.584
G1 X204.050 Y154.321
G1 X203.366 Y154.231
G1 X202.683 Y154.321
G1 X202.046 Y154.584
G1 X201.499 Y155.004
G1 X201.079 Y155.551

If it does fail, could you try uncommenting the SET_GCODE_OFFSET line and retry?

-Kevin

[Artem-B]

Also, check the mechanics. There were cases where people reported stalls that went away after they've adjusted mechanical movement. It appears particularly important to make sure that it's easy to get move from a standstill. Disconnect the motor and try moving the carriage/bed by hand. See if there are any perceived bumps or unexpected resistance.

Also, some users reported that things actually improved at lower current. My guess is that higher current would be hard to achieve at higher speeds (higher back-EMF counteracts supply voltage) and that may mess with TMC's ability to control motors. Lower current gives you less torque, but allows stable current control over higher range of speed. The sweet spot is specific to particular printer and needs some experiments to figure out where it is. I would start from the low current value, raise it until you see no apparent issues and then bump it up a little to give it some error margin.

[FromtonRouge]

@KevinOConnor Sure I'll do that but I'm in a 10 hours print now :D

@Artem-B Ok I'll check the mechanic on the Y axis and will try you current adjustment method, thx again

[FromtonRouge]

@KevinOConnor Just tried your sample gcode, here are my observations :

• Your gcode stalls my Y motor and it's 100% reproducible on my printer
• If I uncomment SET_GCODE_OFFSET Y=0.005 the driver doesn't stop anymore :+1:
• BUT every print I do after that successful print (with the same gcode and your line uncommented) the Y driver stops to function again

To always have a new successful print I have to restart the host or send the command SET_GCODE_OFFSET Y=-0.005 to compensate the previous offset. It looks like SET_GCODE_OFFSET is not reset between prints but it's certainly by design, am I right ?

[KevinOConnor]

@FromtonRouge - the reason SET_GCODE_OFFSET isn't "sticking" is because the probe:z_virtual_endstop effectively resets the position when Z homing. (I actually ran into that when putting together the demo code earlier.) You should be able to work around that by replacing the G28 with a "SET_GCODE_OFFSET Y=0 ; G28 ; SET_GCODE_OFFSET Y=0.005" sequence. Be aware the sequence is very specific to your printer and very specific to this particular gcode. It's not a general solution.

Alas, this is very bad news about the TMC2208. :-( If I'm interpreting this correctly, the 2208 has a naive mechanism for detecting speed in its stealthChop2 mode and is itself driving excessive amounts of current into the motor. I'll try to write up a more detailed explanation of my hypothesis tomorrow.

-Kevin

[Artem-B]

I can help capturing coil current vs step/dir signals on oscilloscope. Direct measurement may make checking your theory a bit easier.

[zerg32]

Are you guys running on 12v or 24v ?

[Artem-B]

I had motor stall on homing when I was running at 12V. Lowering the current helped at that time.
I haven't seen the driver shutting down after I've switched to 24V.

[KevinOConnor]

Here's some details on the test case I put together for @FromtonRouge .

It appears the critical g-code commands are:

G1 X204.050 Y154.321
G1 X203.366 Y154.231
G1 X202.683 Y154.321

This is the lower part of the circular movement needed for the screw hole in the upper right part of the pictures above. The Klipper host code translates this movement into the following Y stepper commands:

queue_step oid=2 interval=96115 count=2 add=8383
queue_step oid=2 interval=62108 count=2 add=-3305
queue_step oid=2 interval=58552 count=2 add=0
queue_step oid=2 interval=65290 count=1 add=0
queue_step oid=2 interval=152382 count=1 add=0
set_next_step_dir oid=2 dir=0
queue_step oid=2 interval=458 count=1 add=0
queue_step oid=2 interval=152269 count=1 add=0
queue_step oid=2 interval=64992 count=2 add=-6231
queue_step oid=2 interval=58510 count=2 add=0
queue_step oid=2 interval=62314 count=1 add=0
queue_step oid=2 interval=104173 count=1 add=0

Details on Klipper mcu commands can be found in docs/MCU_Commands.md. The key detail is that interval is the number of clock ticks between steps - the smaller the value the higher the velocity.

The interesting commands in the above sequence are:

set_next_step_dir oid=2 dir=0
queue_step oid=2 interval=458 count=1 add=0

The interval=458 translates to a step pulse ~29us after the previous step pulse. Although this may look odd, Klipper is emitting the correct timing. The g-code is extruding a circle, and as the movement proceeds it is necessary to transition from a negative y movement to a positive y movement. For example:

In this picture the red line is the path of the toolhead and the horizontal black lines represent the toolhead position that should result in a y axis step. The toolhead is traveling at a basically constant velocity. The reason for the small time between the last negative step and the first positive step is because the toolhead only crosses over the point that the Y axis should step for a very small duration. It is not representative of an actual high acceleration or high speed.

The TMC2208 uses a "stealthChop2" mode. It seems the big difference between this mode and "stealthChop1" (as found on the TMC2130) is the ability to adjust the "voltage" parameters based on observed speed changes.

My theory is that the TMC2208 is interpreting the above sequence as a dramatic increase in speed and is thus dramatically increasing the stepper motor "voltage" in preparation for that speed. There is, however, no notable speed change at all. If the driver does significantly increase the amount of current going through the motor when the motor is traveling slowly, it could lead to an "over current" exception within the driver.

-Kevin

[FromtonRouge]

@zerg32 It's 24 V for me
@Artem-B You were right I did several tests with different current values and for lower current I can pass the gcode test :

But at <= 300 mA there are lots of missed steps :(

@KevinOConnor Interresting maybe we can have a confirmation from Trinamic ?

For my part, as a temporary solution, if I set square_corner_velocity to 0 is there a small chance to have an "over current" exception from the driver? EDIT: I switched to LV8729 for X and Y, I am of course available to do any other tests on TMC2208 ;)

[Artem-B]

@FromtonRouge Yeah. It's a trade-off between being able to control current with PWM and the torque needed to accelerate. You can try tinkering with disabling interpolation (this may make it easier for the driver to deal with irregular pulse spacing). You can try switching to 4-microsteps. Anecdotal evidence (https://youtu.be/GVs2d-TOims?t=19m44s) suggests that 4x microstepping may give you higher torque, though the benefits mostly show up at higher speeds. And, of course, there's also spreadCycle mode which is noisier (it's manageable with some motor-specific tuning) but should handle situations like these much better.

@KevinOConnor Interesting. Can we just eliminate the tiny steps in situations like these? From what you've said the motor is moving relatively slowly at this point, so only a tiny fraction of the microstep movement actually happened by the time we need to reverse direction. Skipping the step may not be noticeable in practice. If it brings stability to 2208 w/ stealthschop, it may be worth it.

[KevinOConnor]

@FromtonRouge - The easiest thing you could do to reduce the chance of this failure would be to round your step size. By using a step size of .012540757, the coordinates in the g-code basically never align with step positions. In particular, if you could use a step size of .0125 then I suspect you likely would not hit this condition in practice. Out of curiosity, how was that step size derived?

If I understand the issue correctly, reducing driver current and reducing square_corner_velocity only make the high current less likely to trigger the driver's over-current check.

I suspect the issue could be solved by wiring up the driver's UART interface to Klipper. With the runtime configuration, there's a good chance disabling the driver's stealthChop2 "speed adjusted" mode would fix this. It's also possible disabling step interpolation might fix it.

I don't have any contacts at Trinamic, but I agree it would be good to here what they say about these findings.

-Kevin

[KevinOConnor]

@Artem-B - I don't believe there would be a problem in "skipping these steps" if they can be identified in advance. Unfortunately, I suspect it would be quite difficult to do that for all cases. (The end of a move may place the head just past the stepping point, and it can be difficult to know if the next move is going forward (where we must take that last step) or going backwards (where we then must go backwards if we did take the step).) I can think of several heuristics that would catch most of these cases - but given the drastic response from the stepper, I fear "mostly works" isn't of particular value.

-Kevin

[FromtonRouge]

@KevinOConnor

Out of curiosity, how was that step size derived?

Oh it's maybe the source of all my problems... I naively put my Marlin settings in the printer.cfg. In Marlin I have 79.74 steps/mm for X and Y axis and I translate it in klipper by 1/79.74 = .012540757. The theoretical value is 80 steps/mm and I end up with 79.74 after calibration with measurement. I am not supposed to do that right ? (I'm new to 3D printing)

I suspect the issue could be solved by wiring up the driver's UART interface to Klipper. With the runtime configuration, there's a good chance disabling the driver's stealthChop2 "speed adjusted" mode would fix this. It's also possible disabling step interpolation might fix it.

I saw yesterday you pushed your UART branch on master, I have also some TMC2208 in UART mode (with separate RX and TX pins), I will give it a try and test your proposed solutions ;)

@Artem-B At the end I will maybe just use my others LV8729 at 1/64 microsteps on X and Y

[FromtonRouge]

@KevinOConnor I can confirm that with the calculated value (80 steps/mm => step_distance: 0.0125) everything is fine, I can pass the problematic gcode and now I can even print the benchy boat with the default square_corner_velocity value, no more stall :+1: ... at the moment :)

[Kespa76]

Hi,
I'm currently configuring Klipper and it will run with TMC2208 (24V) on a corexy printer. I've almost read all the topic and didn't find a real solution to this issue?
What do you recommend : to keep my TMCs or to go back for others drivers like A4988?
Thanks

[AxMod3DPrint]

@Kespa76 - 2208s should be working now. There have been several commits to fix issues and configure them via UART see https://github.com/KevinOConnor/klipper/blob/master/config/example-extras.cfg

If you are still having issues, please provide your klippy.log file as described in https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

[Kespa76]

@AxMod3DPrint Ok thank you ! I'm not very comfortable with the UART connection.
Do you have an example of wiring to enable UART with ramps ? Is the wiring showed in this instructable correct?

[KevinOConnor]

Is the wiring showed in this instructable correct?

It's possible to do that, but it is more work than is needed. The Y cable is not necessary on Klipper.

FWIW, here's what I did: I bridged the solder jumper so that PDN_UART is connected to MS3 on the stepstick. On my board (an MKS Gen-L) there is a physical jumper underneath the stepstick socket that allows one to connect MS3 to high. I removed that jumper and I used a multi-meter to identify which of those two jumper pins was connected to the MS3 line of the stepstick. I then used a jumper wire to route that MS3 pin on the Gen-L to a spare mcu controlled pin elsewhere on the Gen-L board. That was it. The only soldering I did was to bridge the solder jumper.

-Kevin

[Kespa76]

@KevinOConnor Ok! So if i understand, the steps to do are:

• Bridge the solder jumper near the PDN_UART pin on the stepstick
• Remove all the physical jumpers on the RAMPS (MS1, MS2)
• Wire the PDN_UART pin of the stepstick to a free pin on the RAMPS. (AUX2 for example)
• Configure Klipper to communicate via UART declaring the RAMPs pin connected to the UART ?

This should enable the UART "write only mode". Right ?

[theopensourcerer]

@KevinOConnor I saw your note in #978 just now...

FWIW I replaced my DRV8825s with TMC2208s[1] about 2 months ago, am running them in standalone mode and they seem to be fine. I have not had any problems that I am aware of:

[1] https://www.amazon.co.uk/gp/product/B07GTKM6FC

[KevinOConnor]

@theopensourcerer - Thanks. Could you attach the klipper log file from a recent run? (Mainly I'd like to see your config and mcu details).

-Kevin

[theopensourcerer]

@KevinOConnor I have been printing all weekend but I just shut my printer down earlier so the klippy.log only has the config info and the initial "chatter" between the pi and mcu but maybe there's something in there which might be of use. I have the MKS Gen v1.4 board (very similar the "L").

klippy.zip

[theopensourcerer]

I have the first two jumpers (pins 1&2 joined, and 3&4 joined) on each of the pololu sockets installed and the third is open. I read somewhere that is how to put them in standalone mode.

[KevinOConnor]

@theopensourcerer - thanks, that log contained the info I'm looking for. I don't know why you would not see the issue given our current understanding of it. Thanks for the feedback.

-Kevin

[theopensourcerer]

I'm so glad I didn't know about the issue before or I might not have even bought them ;-)

If I can do any tests or whatnot just shout - am happy to do what I can to help.

[cosminr86]

Hi.
I have a strange problem.
Tmc2208 on all axis. On almost every print my z stepper stops working after a random period of time. Sometimes after 3h, sometimes after 15-16h (yesterday it ruined 16h print).
The tmc's are configured with uart, z stepper is in spreadcycle mode. The other axis works ok.
Any ideeas?

[KevinOConnor]

@cosminr86 - I'd guess overheating of the driver. There's very little that we can do to assist without a log though - see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

-Kevin

[cosminr86]

It seems, again, was a hardware problem. I had "stepstick protector" (China clones). For some reason the z one stops working after a while. I take them out and all of my prints (3 so far) was successful.
It is not a heating problem, I got two 40mm fans blowing at the drivers.
Maybe this will help someone else.

[cosminr86]

@KevinOConnor after 4-5 prints it happened again.
my last log file
klippy-z-problem.zip

[cosminr86]

another failure.
This is dump_tmc output, while it was printing, but the z axis disabled.

Send: DUMP_TMC STEPPER=stepper_z
Recv: // GCONF: 000001c0
Recv: // GSTAT: 00000003
Recv: // IFCNT: 0000000c
Recv: // OTP_READ: 0000000f
Recv: // IOIN: 20000350
Recv: // FACTORY_CONF: 0000000f
Recv: // TSTEP: 000fffff
Recv: // MSCNT: 000001b8
Recv: // MSCURACT: 011f0068
Recv: // CHOPCONF: 14030053
Recv: // DRV_STATUS: c0190010
Recv: // PWMCONF: c80d0e24
Recv: // PWM_SCALE: 00000022
Recv: // PWM_AUTO: 000e002b

Send: DUMP_TMC STEPPER=stepper_x
Recv: // GCONF: 000001c0
Recv: // GSTAT: 00000001
Recv: // IFCNT: 0000000c
Recv: // OTP_READ: 00000010
Recv: // IOIN: 20000340
Recv: // FACTORY_CONF: 00000010
Recv: // TSTEP: 000fffff
Recv: // MSCNT: 000002d8
Recv: // MSCURACT: 01c4010f
Recv: // CHOPCONF: 14030053
Recv: // DRV_STATUS: c0190000
Recv: // PWMCONF: c80d0e24
Recv: // PWM_SCALE: 00000020
Recv: // PWM_AUTO: 00090028

Send: DUMP_TMC STEPPER=stepper_y
Recv: // GCONF: 000001c0
Recv: // GSTAT: 00000001
Recv: // IFCNT: 0000000c
Recv: // OTP_READ: 0000000f
Recv: // IOIN: 20000140
Recv: // FACTORY_CONF: 0000000f
Recv: // TSTEP: 000fffff
Recv: // MSCNT: 00000158
Recv: // MSCURACT: 018000d3
Recv: // CHOPCONF: 14030053
Recv: // DRV_STATUS: c0190000
Recv: // PWMCONF: c80d0e24
Recv: // PWM_SCALE: 0000001e
Recv: // PWM_AUTO: 00090025

Send: DUMP_TMC STEPPER=extruder
Recv: // GCONF: 000001c4
Recv: // GSTAT: 00000001
Recv: // IFCNT: 0000000c
Recv: // OTP_READ: 0000000f
Recv: // IOIN: 20000140
Recv: // FACTORY_CONF: 0000000f
Recv: // TSTEP: 000fffff
Recv: // MSCNT: 000000a8
Recv: // MSCURACT: 007e00d4
Recv: // CHOPCONF: 14010053
Recv: // DRV_STATUS: 80060000
Recv: // PWMCONF: c80d0e24
Recv: // PWM_SCALE: 00000007
Recv: // PWM_AUTO: 000e0024

[Artem-B]

another failure.
This is dump_tmc output, while it was printing, but the z axis disabled.

Send: DUMP_TMC STEPPER=stepper_z
Recv: // GCONF: 000001c0
Recv: // GSTAT: 00000003

Yup. The driver is halted. drv_err is set...

Recv: // DRV_STATUS: c0190010

And so is s2vsa ("low side short indicator phase A") which suggests that it's not overheating. Nor is it likely to be due to rapid direction change (unless you have mesh bed leveling enabled which could cause z motions in both directions). It could be a real short, but it's more likely to be due to the failure to properly regulate current. I.e. in stealthchop mode, the motor coils are driven by PWM-modulated voltage, so a quick short movement may not have time to raise voltage enough due to the motor's inductance. This would look the same as a short to the driver and may explain this stall. Interpolation makes this problem worse as it sometimes need to move the motor faster than dir/step pulses would indicate. See Fig 11.2 in https://datasheet.octopart.com/TMC2208-LA-T-Trinamic-datasheet-101614865.pdf

Here are the things I'd try, in order:

• check for mechanical issues -- verify that Z moves smoothly. Z axis on my CR-10s used to have some spots where there was a noticeable bump due to some accumulated debris.
• lower max z acceleration/speed
• lower motor current to the point where it starts skipping and then bump it up a bit.
• disable interpolation
• disable stealthchop mode
• use 24V to power the stepper.

You may need to do few iterations of adjusting current/speed settings to find a stable point.

[theopensourcerer]

@KevinOConnor One other thing that might be relevant is I am using 24v power*. I have seen other comments elsewhere about the 2208s not working well (or as well) at 12v - just a thought.

• It's not quite 24v. My printer has a 300x300 400W bed and I only bought a 500W PSU when I built it so I turned the voltage output down as low as it would go, ~19V IIRC, to reduce the current draw from the bed. I've been running it like this for probably 6 months, and had the TMC2208 installed for over a month now and all seems fine.

[theopensourcerer]

I spoke too soon ;-)

I've been printing a Donkey model[1] today for my son. I tried three times. Twice, one of the X & Y steppers stopped at about the same point (I have a COREXY so the nozzle just went back and forth in a diagonal motion before I noticed). The third time I re-sliced the model in a different layout completely and tried again - but one motor again stopped working.

I thought of this ticket, replaced my TMC2208s on X & Y back to the DRV8825s I was using before and it's now much further into the print than it got with the TMCs and looks like it will finish.

The weird thing is up until this print I have not experienced any issues at all. Most of the stuff I have been printing is fairly "square" or "boxy" whereas this Donkey is far from it. So maybe there is something in the amount of movement/directional changes to this problem? Just a bit of a random thought.

[1] https://www.thingiverse.com/thing:687161

[KevinOConnor]

Okay, thanks for the feedback. The problem occurring on prints with "organic shapes" would be expected, as it should only occur when a change in direction occurs nominally just past a step point (think nanometers). As described in https://github.com/KevinOConnor/klipper/issues/196#issuecomment-416237533 .

FWIW, the feedback on the tmc2208 has been positive when using them with run-time configuration. (Basically requires one to run a wire from the PDN-UART pin on each driver to a spare pin on the micro-controller.)

-Kevin

[KevinOConnor]

@cosminr86 - I recommend you change your config so that stealthchop_threshold is just above the maximum velocity for each axis. So, try using stealthchop_threshold: 7 in the [tmc2208 stepper_z] config section. (I believe using a stealthchop threshold just above the axis velocity should allow the stepper to stay in stealthchop mode continuously - but prevent the reverse direction issue outlined above.)

Let us know if that fixes the problem for you.

-Kevin

[cosminr86]

@KevinOConnor, thanks for the suggestion. I disabled stealthchop and lowered the current of the z axis and I had a couple of successful prints (30h one). I will try with the stealtchop set to 7 as you advise, and I will let you know if it is ok.

Thank you!

[Artem-B]

I may have figured out how to make TMC2208 drivers to behave a bit better. The post a bit long. TL;DR; version is -- disable PWM_AUTOGRAD and set PWM_GRAD to a value slightly higher than PWM_GRAD_AUTO.

---

I've hooked up current sensor to TMC2208 on my printer. Looking at the waveform with an oscilloscope showed that with fast enough acceleration (3000) from a stand-still, the stepper fails to drive full current amplitude into the motor and I sometimes can hear tell-tale knocks of skipped steps. The waveform looks very similar to this one taken from the video posted by Trinamic:

Trinamic recommends reducing acceleration and it indeed helps. In my case with acceleration reduced to <1000 the driver can reach configured current with no problem and the steps are no longer lost.

Going slower is a known solution, but that got me thinking. The driver had no problem driving full current amplitude while the motor was going fast, which is the hardest part due to increased back EMF, so the failure to drive full current at the beginning was likely due to the automatic tuning mechanism. AFAICT from reading the datasheet this is mostly needed to deal with changing driving voltage and changed load. Neither is common in 3d printer. Motor power supply is typically fixed at 12v or 24v and the carriage mechanical characteristics also do not change much (modulo weight increase due to filament deposition).

PWM_GRAD parameter looks like the primary suspect -- it's responsible for how fast the stepper scales output voltage in relation to motor speed. E.g. if PWM_GRADis too low, then the stepper may not be able to compensate for back-EMF and the current will not reach the level we need. The datasheet of TMC22xx seems to have less info about the process, but the Figure 6.4 in TMC2130 datasheet does show that decreased current during acceleration is the result of too small PWM_GRAD:

So, I've disabled PWM_AUTOGRAD and set PWM_GRAD to a value slightly higher than the one the driver determined as reported by PWM_GRAD_AUTO field in PWM_AUTO register. I've also set PWM_OFS to match that of PWM_OFS_AUTO.
That does two things. First, explicitly setting PWM_GRAD and PWM_OFS allows the driver to start from already-tuned settings for the motor, so it should work better after power-on before the automatic tuning cycle is finished. Second is that by disabling gradient autotuning, we can tell the driver to scale the driving voltage faster with increased speed. We may overshoot the current limit once we reach the steady state, but that's less of a problem than skipped steps.

In the end, I've added following settings to each or the [tmc2208 ...] sections:

driver_PWM_AUTOGRAD: False
driver_PWM_GRAD: GG
driver_PWM_OFS: OO

where GG is decimal value of the upper 16 bits of PWM_AUTO register and OO is the value of the low 16 bits of PWM_AUTO as reported by DUMP_TMC command for the given stepper after it got a chance to move and idle for some time (e.g. after homing the axis or extruding some filament).

EDIT: @derdigge explained the steps in the post below :

Send: dump_tmc stepper=extruder
...
Recv: // PWM_AUTO: 000e0024

The value
which is converted to dez 000e = 14 and 0024 = 36

so in config:

driver_PWM_AUTOGRAD: False
driver_PWM_GRAD: 14
driver_PWM_OFS: 36

I've eventually picked PWM_GRAD values for each motor that allow me to drive them with acceleration set as high as 3000 without any missing steps.

One issue with this approach is that it's probably going to be tricky to figure out correct PWM_GRAD settings without checking the current waveform with an oscilloscope. Without that, one should probably start with the values in PWM_AUTO, bump PWM_GRAD slowly until missing steps are gone and watch out for motors getting too hot (in case too high PWM_GRAD results in a current too high for the motors).

[ghost]

@Artem-B

Thanks for that detailed explaination. Unfotunatly your settings wont work for me.
Maybe others noticed that one also. Can you please specify the correct config?

Error: Unable to parse option 'driver_PWM_GRAD' in section 'tmc2208 extruder'

`[tmc2208 extruder]

uart_pin: ar37

tx_pin: ar35

microsteps: 16

interpolate: True

run_current: 1.0

sense_resistor: 0.110

stealthchop_threshold: 500

driver_IHOLDDELAY: 8

driver_TPOWERDOWN: 20

driver_BLANK_TIME_SELECT: 2

driver_TOFF: 3

driver_HEND: 0

driver_HSTRT: 5

driver_PWM_AUTOGRAD: False

driver_PWM_AUTOSCALE: True

driver_PWM_LIM: 12

driver_PWM_REG: 8

driver_PWM_FREQ: 1

driver_PWM_GRAD: GG

driver_PWM_OFS: OO`

[Artem-B]

GG and OO are supposed to be the decimal values for the gradient and offset correspondingly, extracted from the appropriate fields of the PWM_AUTO register. Note that the register values are reported as hexadecimal numbers, but klipper config wants to see decimal values, so you'll need to convert the values.

[rodjerhell]

каким образом узнать необходимые значения ? какой алгоритм для этого ?

[ghost]

EDIT:

With a help of a friend i thing i got it:

my output :

Recv: // PWM_AUTO: 000e0024

which is converted to dez 000e = 14 and 0024 = 36

so in config:

driver_PWM_AUTOGRAD: False
driver_PWM_GRAD: 14
driver_PWM_OFS: 36

Is This correct?

@Artem-B Sorry but i understand half what your explaination post tells us. As it looks you´re the only person who solved this. A Hex to dez converter dont know GG or OO, thats why. Can you please for me and maybe others try to help how this is done? Theese seem to be obvious things for you. At least for me it is not.

Lets take a look at my output:

Send: dump_tmc stepper=extruder
Recv: // GCONF:          000001c0
Recv: // GSTAT:          00000001
Recv: // IFCNT:          00000042
Recv: // OTP_READ:       0000000c
Recv: // IOIN:           20000141
Recv: // FACTORY_CONF:   0000000c
Recv: // TSTEP:          000fffff
Recv: // MSCNT:          000003e8
Recv: // MSCURACT:       00f401dc
Recv: // CHOPCONF:       04030053
Recv: // DRV_STATUS:     c0130000
Recv: // PWMCONF:        c80d0e24
Recv: // PWM_SCALE:      00000016
Recv: // PWM_AUTO:       000e0024

So my PWM_AUTO Value is 000e0024 which is 917540 in decimal regarding to excels hex to dez converter. This confuses me in total as it is not even close to anything i saw here and in default configs.

Whats wrong with my brain? please help me.

[lorf]

@rodjerhell @derdigge I made a patch that will decode some TMC2208 registers to decimal values, You can temporarily use it while tuning your drivers: https://github.com/lorf/klipper/tree/tmc2208-decode

Send: dump_tmc stepper=stepper_a
Recv: // GCONF:          0x000001c4
Recv: // GSTAT:          0x00000001
Recv: // - uv_cp (undervoltage): 0
Recv: // - drv_err (error shutdown): 0
Recv: // IFCNT:          0x00000006
Recv: // OTP_READ:       0x0000000d
Recv: // IOIN:           0x20000148
Recv: // - VERSION: 0x20
Recv: // FACTORY_CONF:   0x0000000d
Recv: // TSTEP:          0x000fffff
Recv: // MSCNT:          0x000000b4
Recv: // MSCURACT:       0x006e00dd
Recv: // CHOPCONF:       0x13030053
Recv: // DRV_STATUS:     0x80130040
Recv: // - stst (standstill): 1
Recv: // - stealth (stealthChop): 0
Recv: // - CS_ACTUAL (actual current scale): 19
Recv: // - t157 (157 C reached): 0
Recv: // - t150 (150 C reached): 0
Recv: // - t143 (143 C reached): 0
Recv: // - t120 (120 C reached): 0
Recv: // - olb (open load B): 0
Recv: // - ola (open load A): 1
Recv: // - s2vsb (low side short B): 0
Recv: // - s2vsa (low side short A): 0
Recv: // - s2gb (short to ground B): 0
Recv: // - s2ga (short to ground A): 0
Recv: // - ot (overtemperature): 0
Recv: // - otpw (overtemperature warning): 0
Recv: // PWMCONF:        0xc80d0e24
Recv: // PWM_SCALE:      0x00000016
Recv: // - PWM_SCALE_SUM: 22
Recv: // - PWM_SCALE_AUTO: 0
Recv: // PWM_AUTO:       0x000e0024
Recv: // - PWM_OFS_AUTO: 36
Recv: // - PWM_GRAD_AUTO: 14
Recv: ok

[Artem-B]

Recv: // PWM_AUTO: 000e0024

which is converted to dez 000e = 14 and 0024 = 36

so in config:

driver_PWM_AUTOGRAD: False
driver_PWM_GRAD: 14
driver_PWM_OFS: 36

Is This correct?

Yes, that's exactly what needs to be done.
I could've done better job explaining these steps. Sorry about that. :-(
Also, thank you for posting the explanations. I'll update my post with these details.

[rodjerhell]

I had problems with turning off the printer, I can not figure out the reason. how to find the problem? 2208 driver
klippy.log

[ghost]

@Artem-B Nothing to be sorry about. Not all people share thyre knowledge in detail. There is one thing i still did not get. When do i have to take the PWM_AUTO values? Mine are different everytime i try to pick them up....

[Artem-B]

The values should be valid after the driver went through the automatic tuning process (Chapter 6.1. in the TMC2208 datasheet)

Basically, the sequence looks roughly like this:

• enable the motor, so the full configured current runs through the coil.
• stand still for 130ms or more. [Note: you may want to set hold_current current to be the same as run_current so this phase is not accidentally done with the reduced current. By default the driver switches to hold_current after ~ 0.4s of idle time (driver_TPOWERDOWN).]
• move motor at a reasonably high speed for few hundreds of full steps (~few motor rotations)

The values adjust to the properties of the particular motor, so they may be somewhat different even for the motors of the same model. They may also adjust depending on external factors like motor power supply (fluctuating voltage will affect the gradient, IIUIC). In any case, the values you get are just a starting point for further tuning. The idea is to get the automatically determined parameters that proved to be somewhat suboptimal, and then manually adjust them so the driver works in situations that autotuning can't cope with.

[ghost]

@lorf
I tested your patch today. DRV status can help people a many. But its not complete so far. I am sure that this would be a candidate for a pull request here. I do currently decode it in excel.

[lorf]

@derdigge OK, filed pr #1156

[killvearn]

I'm having this issue with my TMC2208 too in standalone mode (I don't have pins on the board to use UART). I changed the extruder driver with an A4988 and the problem on E stepper is gone, but still on some prints and at the same spot the Y axes stops working while the rest of the axes keeps going.
I was thinking, given that with marlin the problem isn't showing, maybe was addressed using the TMC2208_STANDALONE parameter in configuration.h.
Here's the difference between the A4988 and the TMC2208_STANDALONE mode:
A4988: MINIMUM_STEPPER_DIR_DELAY 200 - MINIMUM_STEPPER_PULSE 1 - MAXIMUM_STEPPER_RATE 500000
TMC2208_STANDALONE: MINIMUM_STEPPER_DIR_DELAY 20 - MINIMUM_STEPPER_PULSE 0 - MAXIMUM_STEPPER_RATE 400000
Is there a way I can make those changes in Klipper so I can test if the problem goes away?

[mattthebaker]

I've read through I believe the entire issue. Other than suggestions to try, it doesn't seem that any tests have been done with interpolation disabled. I've been reading the tmc2208 datasheet, and the "microplyer" aka interpolater most certainly uses delta t to the previous step when calculating the time base for interpolation.

It interpolates the time in between of two step impulses at the step input based on the last
step interval. This way, from 2 microsteps (128 microstep to 256 microstep interpolation) up to 256
microsteps (full step input to 256 microsteps) are driven for a single step pulse.
The step rate for the interpolated 2 to 256 microsteps is determined by measuring the time interval of
the previous step period and dividing it into up to 256 equal parts

Fig 11.2, TMC220x pg 60.

Could the very short step time in the problematic gcode result in very short/fast interpolated microsteps and an associated fast current ramp (enough to trigger the protections)? You would expect it to not be any worse than performing an un-interpolated step. Its not clear if the systems are coupled in more ways than just the internal steps. The StealthChop2 issue might just be cascading from the conditions created by the interpolater.

It is unclear how it is intended to respond to direction changes.

The attention warning might be a significant red flag.

Knowing whether the issue is present without interpolation, and whether it is present when running a higher external microstepping could be useful for determining root cause.

[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 https://github.com/KevinOConnor/klipper/issues/196#issuecomment-447605307 . 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 e872290c4). 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