Coolstep for TMC2130, 2209, 5130, 5160

[Fabi0San]

Description

This change implements configuration and initialization for the CoolStep feature of many Trinamic drivers, which enables cooler running steppers and/or eventual torque boost to avoid skipping steps.

Benefits

This will allow TMC drivers to use the CoolStep feature which dramatically decrease heat and power use.
With CoolStep on, extruder steppers can save energy and heat while idling or extruding slowly and retracting, but apply full current and even overcurrent in situations where more force is needed as full speed extrusions, or pushing hard on a squished first layer. XYZ steppers can equally save energy and heat on easy moves and apply extra power on high acceleration moves.

The power savings are surely welcome but the heat and overcurrent capabilities are the real game changers for 3d printers as you can use smaller/cheaper/lighter steppers and only overcurrent them when needed instead of provisioning bigger/expensive/heavier steppers for the rare events that require the extra torque.

Keep in mind that applying overcurrent to stepper will cause it to heat up, if done often it may get hot enough(supernova) to blow a coil. Much like overclocking, if you go that route monitor your stepper temperature and consider beefing up heat dissipation.

But in the typical scenario the steppers will run much much cooler and the short burst of overcurrent every now and then wont be enough to get it even warm.

Though 2130s only have CoolStep and StallGuard for the SpreadCycle chopper, the 2209 brings those to StealthChop which makes them much more useful for 3D printers and relevant for Marlin.

Related Issues

This is a second coming of this change which was once reverted mainly because it was integrated with a different change around driver type auto-assignment which had issues. Details here: 71539bc 18a7276#comments #16790

So I'm bringing it back this time without the problematic auto-assignment and I'm leaving CoolStep disabled by default as it needs to be tuned to the user's specific machine.
I suggest reading your stepper driver's datasheet for proper tuning procedure of CoolStep.

[thisiskeithb]

I remember this PR from before 🙂

Adding some good documentation/examples for drivers to Marlin’s Documentation repo (which feeds marlinfw.org) would probably help adoption and prevent a flood of tickets when users don’t tune this feature properly.

[Fabi0San]

Thanks for the pointer, I'll make sure to document the basic tuning procedure.

[thinkyhead]

Everything looks good. My only question is, should it be possible to enable / disable this feature only for certain steppers? Or, is it important that it is always enabled?

[Fabi0San]

My only question is, should it be possible to enable / disable this feature only for certain steppers? Or, is it important that it is always enabled?

Thanks for looking Scott,
Yes, there can be many scenarios where one wishes to enable on E only or XY only. It is not a requirement to be all or none.

[teemuatlut]

Make a sensible interface that would actually warrant being called a feature. In its current state this is quite literally no different from using the TMC_ADV macro. A feature should be more than just a list of values to push to the driver.
How are you addressing the tuning procedure? How should a user know if the current is stuck on min or max value? Why should the user learn about 6 parameters total to use this? How was this tested? How did you validate that it actually works? How does this play with sensorless homing? Why would adding 200 lines of settings be a good idea?

[thinkyhead]

These are all good questions. At the moment Trinamic drivers are very new to most of us. I have not read the datasheets closely enough to understand all the features of TMC drivers and how they interact. It seems like a good idea to provide a way to interact with this feature of the stepper driver for the serious geeks.

If Trinamic has a set of sketches to exercise motors, do diagnostics, and figure out the best settings, that would be a good thing to get a hold of. Of course, to really tune things in situ, such tests need to be added to the firmware and tested under common conditions.

If we wanted to be able to test and tune this feature, what kind of testing and tuning code would we need to add? Could the tuning be done dynamically in the background of a test print job? How do we interpret feedback from M122 in order to apply tuning to CoolStep and other features?

At the moment, we rely very heavily on TMCStepper managing all these details automatically. Are there any plans to add formal support for testing and tuning of CoolStep (and other features) to assist in finding the most optimal values? Where can we turn to get the best information and advice for TMC drivers?

[teemuatlut]

One problem is that if you don't tune it right, you'll either pin the current low which means you'll be skipping steps and if on the other side you'll pin it high which means will lead to the driver overheating and it shutting down. You'll need to find a good balance and the correct upper and lower limits. This PR does not provide tools to do that. You'd need something like statistical heuristics that you could run while doing a sample print and get data back what you could use to tune the parameters. I don't think M122 is a good tool for this because you wouldn't want to poll the data while the motor is stopped nor would it likely show the peaks required for accelerations. You'd need to see that the driver responds properly to quick direction changes and accelerations. Or maybe you could periodically check where the actual current is in a given situation and "train" the driver dynamically. At this point we start to talk about actual features.
Several of the parameters here I think shouldn't be exposed to the user. Min current I think should never be at 1/4 and the current increase should be quick as possible in order to react to accelerations. Not quite as clear would be the current decrease which I think should be on the slower side. It's better to be cautious and avoid skipping steps.

TMCStepper provides an interface and some helper methods but it doesn't really provide any features to Marlin.

The CoolStep (or SmartEnergy) is described in the datasheet and there's probably an application note as well.

Serious geeks can already tune just about anything with the TMC_ADV macro. This PR doesn't add anything new.

I also have a really big issue with how this floods the config file. It's already way too long as it is.

[Fabi0San]

Make a sensible interface that would actually warrant being called a feature.

Oh wow, I'm sorry @teemuatlut if I've offended you wit my sincere time and skill donation to your open source project. I'll be happy to issue you a full refund 😜

A feature should be more than just a list of values to push to the driver.

I didn't mean to claim CoolStep as my feature, it is a TMC feature and just like other features like StealthChop, StallGuard, MicroPlyer, which have their configs (X_MICROSTEPS, X_CURRENT, X_STALL_SENSITIVITY, INTERPOLATE, etc) sent straight to the driver I made the naive assumption it was an acceptable pattern for suggested changes. And for the oversight I apologize.

How are you addressing the tuning procedure?

No different from StealthChop and StallGuard tuning this feature is machine dependent and requires an oscilloscope with a current probe.

How should a user know if the current is stuck on min or max value?

M122

Why should the user learn about 6 parameters total to use this?

I agree the raw interface is not user friendly, We can certainly put our heads together and try to make it easier for the user. I'm not sure how far we can go though if even the chopper settings are not tuned and used with marlin defaults. Those parameters are also not user friendly and I'd say even more important.

How was this tested?

You mean the code I wrote? M122, if the driver got the settings Marlin's job is done.

How did you validate that it actually works?

You mean the TMC functionality? Oscilloscope and Current Probe as instructed by the Datasheet

How does this play with sensorless homing?

Should not make a difference, the stall will still happen at the same back-EMF threshold. If the current is reduced during homing, the limit will be respected, CoolStep only reduces the current bellow a certain threshold and increase above another threshold, both bellow StallGuard threshold.

Why would adding 200 lines of settings be a good idea?

I don't like it either, but that is the pattern we have for all the other TMC settings as they are required parameters to the constructor of the driver instance. We may be able to find alternatives by leaving it off if the settings are not defined.

[Fabi0San]

These are all good questions.

Agreed.

If Trinamic has a set of sketches to exercise motors, do diagnostics, and figure out the best settings, that would be a good thing to get a hold of.

Page 59
In a nutshell it is jogging around at typical speed/accel/voltage/curents and make note of the range of SG_RESULT so we understand what unconstrained movement looks like and let coolstep reduce the current in this range, anything harder than this will trigger an increase. How fast to increase is also configurable, I'd say as fast as possible and reduce as slow as possible.

As @teemuatlut suggested this may be possible with some eager polling of during a jog of the axis being tuned.

How do we interpret feedback from M122 in order to apply tuning to CoolStep and other features?

As @teemuatlut mentioned, for coolstep particularly we need to pool values during movement, maybe some debug bit we can turn on to periodically report or log min max avg.

Where can we turn to get the best information and advice for TMC drivers?

I have been using TMC stuff for several years now and have become very familiar with various of their drivers and procedures, but won't claim to be an expert. Their stuff is meant for the designers of the machines, not the users, and those two are worlds apart as you can see in this very discussion.

TMCStepper is really pass through, it is on us to create a user friendly interface, I just fear it may not be possible without some hardware modifications and user involvement.

[Fabi0San]

One problem is that if you don't tune it right, you'll either pin the current low which means you'll be skipping steps and if on the other side you'll pin it high which means will lead to the driver overheating and it shutting down. You'll need to find a good balance and the correct upper and lower limits.

Absolutely! If used wrong the feature will hurt more than help. I don't think this is unique to CoolStep though, StallGuard and even the chopper timing settings if left untuned can be just as harmful.

This PR does not provide tools to do that. You'd need something like statistical heuristics that you could run while doing a sample print and get data back what you could use to tune the parameters. I don't think M122 is a good tool for this because you wouldn't want to poll the data while the motor is stopped nor would it likely show the peaks required for accelerations. You'd need to see that the driver responds properly to quick direction changes and accelerations. Or maybe you could periodically check where the actual current is in a given situation and "train" the driver dynamically. At this point we start to talk about actual features.

Sounds cool and expensive, I'm not passionate enough about CoolStep to invest the time needed to realize this vision. Keep in mind that once tuned this code no longer needs to run. My approach is to find the lowest current(600mA) I can use to move at my typical feed rate (150 mm/s) and find out the max SG__RESULT in that period, anything more than that I take to my driver's nominal max(1.4A). Simple and works great.

I'd suggest a simple sampler turned on and off via debug bits which gives min, max and mean SG_RESULT. Maybe we can write code that takes from there to CoolStep configs, but even that is more than I can commit right now.

Several of the parameters here I think shouldn't be exposed to the user. Min current I think should never be at 1/4 and the current increase should be quick as possible in order to react to accelerations. Not quite as clear would be the current decrease which I think should be on the slower side. It's better to be cautious and avoid skipping steps.

I agree we can hide the reaction time parameters or have them as single setting for all drivers. Not so sure about 1/4 current, especially if someone wants to play with overcurrent. I won't fight for it though...

Serious geeks can already tune just about anything with the TMC_ADV macro. This PR doesn't add anything new.

That is how I've been ruining but felt this would make it accessible to more people.

I also have a really big issue with how this floods the config file. It's already way too long as it is.

I agree, should we keep these undefined when not used? Is there another way to keep non functional configs out of the config file?