Log in

View Full Version : TalonSRX problem

FRC2501
13-02-2015, 09:37
Our team is using Talon SRXs for our drive this year, but at random times (not while enabled) the SRXs will stop moving the robot, showing a neutral signal but enabled (solid yellow), it takes 1-3 reboots of the robot to get them working again. This issue has brought us to the brink of abandoning the Talon SRXs for the stable Talon SRs.

Here is what troubleshooting we have done:

Try older versions of the robot code
Try just basic drive code
Update Talon SRX firmware to newest version (1.4)


Attached is our robot code
FRC2501
17-02-2015, 17:01
We contacted the manufacturer and they told nus how to fix it
Alan Anderson
17-02-2015, 17:10
What was the solution?
Ether
17-02-2015, 17:17
We contacted the manufacturer and they told nus how to fix it

Was it related to this?

http://www.chiefdelphi.com/forums/showpost.php?p=1445412&postcount=23
ozrien
17-02-2015, 19:40
The symptom was that the Talons would go solid orange, and not drive, after enabling the robot. Also DS messages confirmed motor safety trips.

The cause was motor safety tripping. Seems to be a common thing to trip over when using C++ and RobotDrive. Workaround was to RobotDrive::SetSafetyEnabled(false).
GeeTwo
17-02-2015, 23:37
Seems to be a common thing to trip over when using C++ and RobotDrive. Workaround was to RobotDrive::SetSafetyEnabled(false).

Wow. That's rather a major showstopper to learn after Australia and most of Asia have bagged!
ozrien
18-02-2015, 00:04
Wow. That's rather a major showstopper to learn after Australia and most of Asia have bagged!
There are several posts discussing this over the past two weeks. Many of which you posted on.

And by the way, the DS tells you exactly what is wrong, so this isn't very difficult to workaround.

Software can be worked on after after bag.
Kevin Sevcik
18-02-2015, 11:48
Wow. That's rather a major showstopper to learn after Australia and most of Asia have bagged!Also, this has been a feature in the code for several years now and is documented in the WPILib material. It's only a showstopper if something like a team sending multiple different Set()s to the same motor in one loop is a showstopper.