Issues with new Talon libraries

So we have everything updated, from what I can tell. Talon’s are at 3.3, used the latest phoenix installer to update the roborio, everything looks good on versions from what I can tell.

We copied over the arcade drive example from the ctre example’s, but nothing’s happening… we tried to control just a single controller using controller.set, but nothing. We plugged in an old victor over pwm using the same code and it worked just fine. So I’m looking for suggestions on what to check next? I’ve walked through all the documentation, examples, and what not, but something still isn’t right. Anyone have any clues? Thanks!

Are the Talon IDs set correctly?

Can you post your code?

Talon id’s are set correctly… I can see all 4 talon’s in rio web config. Here is the code that I’m using…

WPI_TalonSRX driveBaseLFM = new WPI_TalonSRX(1);    
	WPI_TalonSRX driveBaseLRM = new WPI_TalonSRX(3);    
	WPI_TalonSRX driveBaseRFM = new WPI_TalonSRX(0);    
	WPI_TalonSRX driveBaseRRM = new WPI_TalonSRX(2);
	DifferentialDrive drive = new DifferentialDrive(driveBaseLFM, driveBaseRFM);
	XboxController controller = new XboxController(0);

        public void robotInit() {

	public void teleopPeriodic() {
		double forward = controller.getY();
		double turn = controller.getX();
		System.out.println("X: " + turn + "//Y: " + forward);
		drive.arcadeDrive(forward, turn);


What do the lights on the Talons do when the motors should be moving (page 32)? Is there any output in the driver station console?

The lights don’t change when the motors are supposed to move… I believe it is just the steady flashing amber light. (I’m not in front of the robot anymore, so I’m probably getting the color wrong, but it’s the usual steady flashing when nothing is moving)

The talon’s were working yesterday. This morning the rio was updated to the latest firmware and that’s when things stopped working. After the rio was updated, the can libraries were reinstalled to the rio, not sure if we missed something else in that process.

The flashing amber means the Talons are not receiving communication from the roboRIO.

Can you still see the Talons in the roboRIO Webdash?
(Did you run the Phoenix Lifeboat Web Config update for the roboRIO?)

It could also be due to a disconnected CAN wire, but seeing it in the WebDash will tell you.

And I may be getting the color wrong… we can see all 4 talon’s in the web interface and run the self test on all 4, everything comes back good. They do show as enabled in self test when the robot is enabled. We did run the phoenix lifeboat utility, it said everything was good on that end.

I would suggest falling back to as simple a test program as you can, e.g., just a basic program with a line to run one Talon at a fixed speed for example.

Yea, that’s kind of what we did… the code I posted above was using the arcade drive function, but we tried it with calling the set function on one of the talon’s as well. Same result :frowning: At this point, I might just reset the rio and start from scratch, maybe something got messed up on it.

That sounds like the best idea.
Redo the roboRIO from the bottom up.

We had a similar problem to this, but if you held down the joystick for long enough, it would accelerate.
We were doing configOpenloopRamp(60, 0) on each of our motors, and the 60 used to represent the amount of volts the motors would ramp up each second. But it was changed to be the amount of seconds the motor takes to go from 0 volts to max, so our motors were accelerating very slowly.
Changing the 60 to 0.5 solved our problem

So we’ve narrowed it down to a problem with our talon’s… we have 2 new talons that we got through first choice this year, they both work fine. The 4 talon’s we got in the off season won’t work. All 6 were flashed to the same firmware version using the same firmware file… the 4 were flashed when they were all connected together, the 2 new ones were flashed when they were the only device on the can bus. So our first step today is going to be reflash them and assign new id’s one at a time. Unless there are other suggestions? From what I can tell, all 6 are the same hardware revision…

Dave - if you’re still having trouble, please contact our support:

As a general statement for everyone, PLEASE contact our support when you’re having trouble with one of our products. Chief Delphi is not an official channel for support from us.

You will get a much faster response and resolution contacting us directly.

We were able to fix it, the 4 older talon’s required a recalibration. As soon as we did that, they started to function as expected.

What do you think you are calibrating? The only time calibration should be used is when using PWM. CAN does not require any sort of calibration.

It beats me… the motors wouldn’t run. We ran the process where we held the little button down as we applied power, the lights flashed green, then we left off the button. Reflashed the firmware and everything started working after that. Just flashing the firmware alone didn’t fix things, it was only after we did the reset procedure.

I find this document to be very helpful.’s%20Guide.pdf

Page 31.

You factory defaulted all of the settings.

Ah, gotcha :slight_smile: My student was doing most of the work, I was bouncing around between things, I thought I heard something about calibration, so I figured that’s what it was they did. I’d still be curious as to what we did to begin with that caused them to do that, but we’re back up and running now, so it’s all good. I appreciate the help looking into things :slight_smile:

One possible reason for the Talon SRX not working is that you had limit switches enabled with normal close on the Talon possibly from previous season. It bite us a few times. We had repurposed Talons from previous year that were used in an elevator which had upper and lower limit switches to our drive train and the robot was not running. After some debugging, we found that the limit switches on the Talon was enabled with normal close, so without the limit switches connected, the motor will not run.

Yea, we didn’t have limit switches, but we did have encoders that were no longer plugged in. So that may have been what the issue was.