Erratic Driver Carrier Behavior

mtl · August 17, 2022, 6:16pm

I’ve been having several different problems with the TB67S128FTG Stepper Motor Driver Carrier.

One problem I’ve noticed is the potentiometer has been known to reset itself. There have been a few dozen boards this year with potentiometers that were set correctly and worked for hours, days, and even months before the potentiometers were somehow reset while screwed into a metal board. I know they turned on their own because I started marking them with a sharpie and found that some of those marks had moved when the driver carriers stopped working and the potentiometer was not set to the correct voltage.

Some boards overheat. I’m not sure what’s causing this issue or how to troubleshoot it.

The most common problem, in fact even more common than functional boards, is the motor the carrier is driving simply will not turn. I have tried replacing every other part when this problem arises and it is only fixed by replacing the driver carrier several times.

Here’s an overview of the project. Python code implementing the GPIO module or C code implementing the BCM2835 library is running on a Raspberry Pi running Raspberry Pi OS. The Raspberry Pi and driver carrier are both connected to a Traco Power TPP 65-251 power supply (https://www.digikey.com/en/products/detail/traco-power/TPP-65-251/9382127). The driver carrier is driving a NEMA 23-22-02SD-AMT112S stepper motor (https://www.digikey.com/en/products/detail/cui-devices/NEMA23-22-02SD-AMT112S/9477649).

And as for the wiring…
IOREF on the driver carrier is connected to V2 on the power supply.
VIN on the driver carrier is connected to V1 on the power supply.
GND on the driver carrier is connected to COM on the power supply.

GND on the driver carrier is connected to GND on the Pi.

ENABLE on the driver carrier is connected to the Pi GPIO.
STANDBY on the driver carrier is connected to the Pi GPIO.
CLK on the driver carrier is connected to the Pi GPIO.
CW/CCW on the driver carrier is connected to the Pi GPIO.

The algorithm used in both the Python and C programs is as follows:
set ENABLE to HIGH
set STANDBY to HIGH
set CW/CCW to HIGH/LOW

for n steps {
set CLK to HIGH
wait for 800ms
set CLK to LOW
wait for 800ms
}

set ENABLE to LOW
set STANDBY to LOW

The 3rd and most common problem has always been present, but its frequency has significantly increased since the beginning of this year. For a while, the soldering iron was set to 850 degrees F. If there was a change in the frequency of problems after turning this temperature down to 650-700 F, it only increased. The soldered connections are all making good contact.

Immediately after soldering, the board’s potentiometer is set to about 1.34v. The same power supply is used for this. A large number of boards show either 0v or 22+v immediately after being soldered. I do not know if this happens before soldering or only after. Of the boards that show 22+v, some have gone over 30v, which makes no sense to me because the power supply’s range tops out at 24v. When the multimeter displays 0v or 22+v, turning the potentiometer does not affect the voltage. These voltages are constant across every connection on the board.

Of the boards that are correctly set to 1.34v, more than half simply do not turn the motor. When the potentiometer is checked again after trying to turn the motor, the multimeter displays 1.34v, but sometimes displays 0v or 22+v on some boards.

I have tried replacing the power supply, the stepper motor, the Raspberry Pi, the Raspberry Pi SD card, and even the Raspberry Pi hat to no avail. I am at a loss for ideas for further troubleshooting and would appreciate any help.

BrandonM · August 17, 2022, 10:57pm

Hello.

It sounds like you are connecting a 5V line from your power supply to the IOREF pin, but please note that the Raspberry Pi uses 3.3V logic and are not 5V tolerant, so you should change that connection to a 3.3V source.

There’s a lot going on in your system, so it would be useful to get more information before focusing too much on any of the problems in particular. Could you please provide the following information?

Pictures of your setup that show all of your connections.
Quantify the number of drivers you are using in your system (or if there are multiple systems), along with how many units are exhibiting each behavior you described.
Close-up pictures of both sides of your TB67S128FTG driver carriers (preferably a selection of units that exhibit each behavior you are describing, with a clear indication of which is which).

It is not common for us to hear about the potentiometers moving on their own, but it has come up before in applications with significant vibrations. Is the plate they are mounted to vibrating (perhaps even by the motor being in contact with it) or being subjected to any kind of impacts? You mentioned some boards overheating; how are you determining they are overheating and what are they doing?

Brandon

mtl · August 26, 2022, 1:25pm

Interesting note on the IOREF pin.

To answer your question about vibration, yes, there can be a significant amount of vibration on the metal plate the driver carrier is attached to.

I was able to get pictures of a system with a driver carrier that overheated. The driver carriers typically get warm to the touch, but sometimes they simply stop working and become dangerously hot to the touch. They are never dangerously hot to the touch and not stop working, which lead us to the conclusion that they have some sort of temperature safety like a desktop CPU. I checked the potentiometer on this driver carrier and it was set to around 1.357v, but should’ve been 1.34v ±0.007v. Is that possibly what caused this problem? This one shut off after about 5 minutes of use. Here are pictures of the system:

This is the driver carrier with the Raspberry Pi cut off on the left.

This is the power supply that supplies power to the driver carrier and Raspberry Pi.

This is the motor mounted to the system.

This is another view of the driver carrier, again with the Raspberry Pi cut off on the bottom.

This is the driver carrier and the Raspberry Pi side by side.

Aside from the entire length of each wire, that is the whole system. One power supply, one motor, one driver carrier, and one Raspberry Pi. There are many systems, as in a few hundred thus far.

I removed the driver carrier and took pictures of the bottom of the board, which is the soldered side.

Out of I believe 5 driver carriers since I last posted, this is the first that has overheated. I will work on getting pictures of driver carriers that exhibit the other problems.

BrandonM · August 26, 2022, 11:49pm

Thank you for the additional information and pictures.

A lot of your solder joints look like they are just tacked in place and are lacking solder, especially since it is subject to significant vibration. Generally, you should aim to have the solder wetted over the entire pad and all the way around the pin. You can find some examples in the Adafruit guide to Excellent Soldering. I recommend reworking your solder joints before continuing.

For the one that overheated, it is possible that the potentiometer moving and increasing the current limit could have contributed to the problem (1.357V would put it just above the 2.1A that we expect it to handle continuously). Has that unit worked again after that happened? The TB67S128FTG carrier has protections against over-temperature conditions, so if it did get too hot, I would expect it to trigger an over-temperature event temporarily. Additionally, please note that electronics like this can get hot enough to burn you long before the chip overheats.

Brandon

mtl · August 30, 2022, 5:01pm

Out of 8 driver carriers tested today, only 1 did not get dangerously hot during a few minutes of testing. They usually get very warm to the touch, but typically not hot enough to burn my skin. All the potentiometers were correctly set to 1.34v ± 0.007v. They did not automatically shut down, so I assume they didn’t hit the maximum allowed temperature, but this kind of heat is still not normal. The soldering on a few of these boards looked better than the previous pictures I sent. I took pictures of 3 driver carriers. Does the soldering look good? If so, is there anything else I can do to troubleshoot? Or is there not a problem because they didn’t automatically shut down due to overheating? They did not run for more than a couple of minutes. Should I run them for longer to see if they do shut down automatically?

I reset the potentiometer on the last driver carrier I mentioned that overheated and it worked correctly after that.

BrandonM · August 30, 2022, 10:15pm

Thank you for the updated pictures. It looks like you could maybe still improve the wetting on the ground pads on unit #3 (the ones near the larger, unsoldered, pins), but overall those look a lot better to me.

I am not sure what you are basing this on; are you able to take a quantitative temperature reading? As I mentioned at the end of my previous post, electronics like this can get hot enough to burn you long before the chip overheats. The TB67S128FTG driver does have over-temperature protections, so it will trigger an error if it overheats and stop driving the motor. With a VREF of 1.34V, you are setting the current to just under 2.1A per phase, which is what the board could handle continuously in our tests (and in our test environment). If your application allows for it, you might try lowering the current limit to see if that helps at all, but it does not sound like your boards are overheating. Lowering the current limit should cause the driver to run cooler, but will also likely limit the maximum torque and speed you can get from your motor.

When you tried the boards after reflowing the solder (even for only a few minutes), did they still have any of the problems you mentioned in your first post?

Brandon