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

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

M82
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

[ViperWorx]

@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