Is it possible to burn out a Talon SRX through programming?

Today, I was working on our robot, which has a talon SRX powering a rotated arm. However, after running the robot for a while, the talon started smoking (it was holding the arm at a specified angle.) Obviously this wasn’t good and signaled a burned out talon. The team said they had a similar problem last year that was caused by the program constantly outputting to the talon in order to keep it in place, rather than using a brake to hold the talon. This didn’t make a whole lot of sense to me, as I was using the closed loop position setting on the talon, and I assumed that the talon would not change any settings if the target position was set to the same value as before. I added some safety code anyway to only set the target if it was different from the previous output, and went back to working after electrical team replaced the talon. However, that talon too started smoking, and I have now burned through two hundred dollars worth of talons. Not very fun.

Anyway, here is the configuration code:

Here is the command code which sets the arm angle and checks the last input:

Here is the arm subsystem code:

So final question: Is it actually possible to burn out a Talon SRX through programming and if so, what can I do to fix it? We currently believe that the program is causing the motor burnout, but I have no idea what to do about it.

First of all, IIRC, the Pheonix API does the exact same thing under the hood to reduce CANbus congestion. If you call .set() with the same parameters as the last call, I don’t think Phoenix will even issue a duplicate CAN message.

However, brake mode is entirely different from closed-loop position control. In brake mode, the motor output leads are shorted inside the Talon, which effectively causes increased drag on the motor shaft (due to feeding the motor’s generated EMF back into it, etc… there’s probably a good @Ether post with the details). In closed loop control, however, the Talon is actively sending current to the motor, which introduces the possibility of burning it up.

That being said, while using position control to hold a fixed angle could destroy the motor, I don’t think I’ve heard of it burning out a Talon. Supposedly, those can handle 60 A continuous. As a sanity check, I’d recommend testing the code on a Talon with a motor that’s not connected to anything (free-spinning). That should be enough to prove that it’s not the code.

1 Like

We have burned out numerous motors, but never a talon. Something is odd in your situation. Do you have something connected to the data port? If so what?

The only way I know to burn out a Talon is reverse polarity on the power or hooking the power up to the motor output. Tom’s suggestion about checking the data port is a good out. the V out on it does not like to be shorted. It will survive a short while but will fail unpredictably later. Have the Talon ever been used? It relatively easy to burn up a motor on position control.

CTRE has great customer service and they are bored this time of year. I recommend having all the details at your finger tips and call them.

Thanks all for the suggestions, I’ll try them the next chance I get.

There’s a (very, super small) chance you got a faulty unit. We’ve had it happen during 2018, when we got one and it started smoking just as you describe. After checking all of the connections to it were good (and back then we didn’t even use the closed loop function on it, just one end connected to the PDP and the other to the motor), we decided to open it up and discovered a blown up capacitor IIRC.

Since we live in Israel we realised sending it out to CTRE will probably be a waste of time during the season, we just ordered a new one, but if you did receive a faulty unit I’d send it back to them and ask for a replacement.