It's time to get the TMC5272 plugged in and running, so let's see how the TMCL-IDE works and just what it can do.
Installation and Setup
I'm running on Windows, so I downloaded the latest version of TMCL-IDE from ADI Trinamic's website here. At this time, it is V4.5, but at the commencement of the challenge it was V4.4, so it seems it gets regular updates.
Installation is a case of following the wizard. Afterward, the software is installed - the default directory is "C:\Analog Devices\TMCL-IDE-Rel4.5.0\V4.5.0"
Plugging in the USB-C connection, the Landungsbrucke is automatically installed and comes up as a USB-COM port with the above VID 2A3C (Trinamic Motion Control GmbH & Co KG) PID 0700 (Evaluation Device) pair.
Starting the software tells us the firmware on the Landungsbrucke is out-of-date and to download new firmware from here. Make sure you download the corresponding version of file - in my case, the V3 file.
Then, the board can be flashed using the firmware update tool. It takes a minute or two and then the board automatically resets.
If you start with the power supply off, as suggested by the manual, the system will detect the board and the driver board then complain there isn't any motor supply. Turn the power supply on and voila - it's all ready to go. The IDE seems to default to automatically enabling the drivers, hence the warning to not unplug or plug motors to the kit when it is on, as it can cause damage.
Looking at the guide, it seems that setting the current was the next step. Choosing the reference resistor to be 10k is the best option to enable the maximum current of 0.8A RMS, as the motor itself is rated for 1A. However, when I did this and hit the "Calibrate settings automatically" button, it complained that it can't reach the full current and the resulting motor movements seemed to have low torque. I suspected it wasn't running the right current, but reducing this to 0.75A seems to change the button to green and no warnings appeared. So it would seem that the chip might not be able to run at the full rating in the way it is configured, but this may be the closest we can get.
The IDE has a lot of useful, albeit, sometimes intimidating features. For example, the advanced configuration for the current gives a few more options, while the box to send raw commands gives a lot of freedom but doesn't give a lot of guidance.
The register table is amazing though - lots of information here and the possibility to monitor the values as well. This really is a lot easier to work with than the datasheet alone.
Chopper settings allows for changing the StealthChop feature on or off. This has the effect of mitigating some of the classic stepper noises from the motor by controlling the driving waveform and frequency. I'm not quite sure how to set the appropriate threshold settings, and as a result, I do get some strange positioning undershoots when turning it on. Perhaps it's my incorrect settings that are causing the motor to miss steps.
The Sine settings dialogue allows you to tweak the driver's waveforms. There is also an automatic tuning feature that tunes the phase offset between windings for better StallGuard performance.
As far as I can tell, StallGuard is a feature for sensorless detection of an impending motor stall, potentially avoiding step-loss and allowing for sensorless stepper applications. It seems that this dialogue is used for testing the stall-guard values that need to be set under application load to determine when a stall should be detected. While a simple idea, getting this to work reliably in practice is a bit of a challenge. I tried stalling the motor manually, causing step-loss, but depending on the situation, sometimes it would show something while other times it did not. It seems it's not a system that works well at very high or very low speeds for "hard" stops based on FluidNC's Wiki, and a few steps lost appears to be not-unusual.
Movements
Time to get it moving. Two of the main modes are Velocity Mode and Position Mode. Velocity mode is as it sounds - it controls the speed of the rotation and the acceleration used to get there.
The system allows you to configure the relevant speed and acceleration values, with a graph showing the actual values the driver is generating. Using the motion calculator also allows you to translate the stepper-motor driver units into something more "human".
The second mode is the position mode, which is perhaps the more useful mode for some applications which rely on the stepper's behaviour to move a precise number of steps (or microsteps).
In this case, I was able to program in a "wave" where the stepper turns in one direction a full rotation, then back in the other, with smooth acceleration/deceleration such that the motor's position is changing nearly perfectly sinusoidally.
Here's a quick video of this happening:
Does It Get Hot?
Surprisingly, no. Not really. Then again, it's not driving a heavy load - just its own inertia and a tiny bit of electrical tape, back and forth.
The Landungsbrucke is hotter than the driver board!
The driver chip up-close isn't particularly hot either.
Turns out, the motor is the hottest part of it all!
Integration
From here, to use the driver in a practical application, there seems to be two ways forward.
One potential way is to use the Landungsbrucke since there is a full TMC-EvalSystem firmware sources available and the bootloader nature of the firmware also means that no special programmer is necessary - TMCL-IDE is all you need. To actually get developing will require Eclipse IDE and GCC toolchain to be set-up, and I suppose it would take some effort to understand the code that already exists, much of it going to support other boards that are not the one we are using. As I'm not particularly familiar with the Gigadevices MCU and the HAL functions, I decided that this probably isn't my preferred path, but it is an interesting one as it truly makes it an evaluation platform, rather than just a simple piece of demonstration kit.
The other way would be to talk to the TMC5272 directly over its SPI or 1-Wire UART interfaces. Thankfully, rather than starting from scratch, ADI Trinamic have a TMC-API which provides a C-based vendor-agnostic code that can be glued into your platform of choice by writing the necessary call-back functions to provide higher-level control of their stepper drivers. This is like having an Arduino library at hand, just that you need to "teach" the code how to access the hardware of your platform. That's a nice compromise. As for hardware connectivity, it seems SPI would be relatively straightforward, however, for a large number of motors, 1-wire UART would be more efficient as it supports multiple drivers on the same line. It's a strange hybrid between I2C's open-collector bus and regular UART, allowing it to be "shared". But because of this, there are some considerations, especially that all TX lines should go high-Z when done, so that may introduce some timing constraints. Perhaps it'll be SPI for me.
Finally, this has me thinking about just how to implement this for my Variac. The Variac has hard stops at each end and StallGuard might be usable to detect the end-stops as the spinning resistance of the wiper and the hard stop should be sufficiently different and no harm will happen if the torque is limited by a reduced drive current (and hopefully, any mounting hardware will be durable to the torque too). But having read that it's not good at low speeds has me slightly worried. What if the motor is already at a limit and is trying to find the limit - will it work? Or will it be reliable? I presume this means, after every power loss, the system will have to sweep the Variac's full range, which wouldn't be nice to any connected load and also adds wear to the carbon brush.
Another thing is whether I drive it in position or velocity mode. I think my application is better suited to position mode, as there's about 270 degrees of travel at the most. But this is where things get complicated, as amount of turn for a given voltage increase or decrease depends on the input voltage on a Variac, which is the quantity that is varying and not being directly measured. So perhaps this means I have to either take a naive approach and do fixed steps up or down and repeat until the result is in the desired range (in which case, it feels like I'm going the quick-way-out and it's almost like using a step/direction input and thus losing all the smarts). Or I will need to compute, based on the step number, the transformer's ratio at the time a voltage reading is taken, then back-calculate what the input voltage would be, then calculate the target ratio that would give the desired voltage, then compute what step number that would be, then drive to that location. I think this is a more sensible approach, but it depends on the ratio computations being very accurate (and thus, perhaps a fine-tuning loop might be necessary too). Having the ability to adjust a dead-band to avoid needless moves is also important, as I won't want to "burn out" the carbon brush with too many needless moves.
Another issue simply is that the Tektronix PA1000 Power Analyser only gives a voltage reading twice-a-second. This means that the opportunity for compensations will be limited, so we want to make the best compensation we can at each step. Unless I build my own mains-waveform-sampling input, which could theoretically go down to "per-cycle" levels of feedback, but that is a potential danger.
Finally, I would still need to design a chassis to hold the motor and a coupling to somehow connect the two round-ish shafts together. While 3D printing is likely going to be the only means I have for this, whether the material will be strong enough to withstand repeated StallGuard trips to find the rotation limits, whether I can even get the right size/shape to fit as the Variac isn't designed for any mounting on the top surface, are all going to be challenges. Perhaps I have bitten off more than I could chew ...
Conclusion
In this part, I've managed to get the three boards running with TMCL-IDE. The TMCL-IDE package is rather useful in testing and demonstrating the capabilities of the stepper motor driver and as a reference for what register values are set for a given mode of operation. As a true novice in this area, there are many settings I don't fully understand, but despite the stumbling in the dark, at least I got some motion out of it and resolved initial difficulties with connection and low torque. That being said, I still exceed the limits from time to time, purely by accident.
Integration of the driver is eased by the libraries provided by ADI Trinamic, but also, can include the use of their Landungsbrucke board as they have an Eclipse/GCC build environment and the board has a bootloader that allows for flashing without the use of any dedicated programmers. The downside would be needing to setup such an environment and familiarise myself with the existing code for the Gigadevices MCU on the board, plus learn about its HAL functions. Otherwise, use of their libraries by coding out the "glue" portion is a possibility, thereby working with Arduino or something more user-friendly. However, this is working at a lower level and will require connectivity by SPI or 1-wire UART (which is convenient for running many stepper drivers, but is a bit like an open-collector bus like I2C, just using UART).
Will I get to the end? I doubt it given the time remaining and my current state of health. Aside from the complexities of learning to drive the stepper driver on another platform, to realise the project will also need mechanical design to couple the motor to the Variac and right now, I can't even walk to the 3D printer ... or to where my Variac is stored. Unfortunately, my participation in the design challenge seems to be nearing its end ...
