Problem With Talon SRX Enabling

[Alan Anderson]

Originally Posted by King Nerd III

There are drivers for the roboRIO that need to be installed. They will not install through Ethernet.

That's because they are USB drivers. They don't have anything to do with Ethernet.

[King Nerd III]

Oh! I just remembered what we figured out yesterday! The only Talons that enable during the Teleop over WiFi were the ones used in a command that is set as a default command. We have verified this by changing the default commands and the Talons do switch around. But for us this is not feasible as then the only command for an elevator moves it up and we can't have it constantly moving up.

[King Nerd III]

Originally Posted by King Nerd III

Oh! I just remembered what we figured out yesterday! The only Talons that enable during the Teleop over WiFi were the ones used in a command that is set as a default command. We have verified this by changing the default commands and the Talons do switch around. But for us this is not feasible as then the only command for an elevator moves it up and we can't have it constantly moving up.

UPDATE: We figured out that if we connect to the robot, go to the DriverStation and click "Restart Robot Code" all the Talons will enable!

[duane]

This seems like a programming problem then.

Just like PWM, you need to tell every speed controller what speed it should be running at all the time. Even if the speed is zero, you are responsible for continuously updating every speed controller.

[King Nerd III]

Originally Posted by duane

This seems like a programming problem then.

Just like PWM, you need to tell every speed controller what speed it should be running at all the time. Even if the speed is zero, you are responsible for continuously updating every speed controller.

We tried this. It did not fix anything, but the way we did it with the button is good enough. Turns out even if they don't say that they're enabled they still drive the motor.

[Alan Anderson]

Originally Posted by King Nerd III

Turns out even if they don't say that they're enabled they still drive the motor.

That sounds like a serious and dangerous problem! Can you document it? Provide the code that runs a disabled Talon SRX, include screen captures of the web interface showing how everything is configured, and see if anyone else can reproduce it.

[Jefferson]

Originally Posted by King Nerd III

UPDATE: We figured out that if we connect to the robot, go to the DriverStation and click "Restart Robot Code" all the Talons will enable!

I'll add a little to this thread... and hopefully it's not just confusion. I've not documented this issue elsewhere because I can't reproduce it now.

The short story: 2 of our SRXs wouldn't enable with the rest of them. One was in follower mode, the other in closed loop (but wasn't the master of the follower). This only happened when the robot was power-cycled. If we, like OP says, restarted the robot code, all SRXs enabled as expected. It was repeatable for the code we had at the time. We had to make some changes and the issue disappeared. (Un?)fortunately it went away before I could fully debug it and didn't get a commit at that point.

I know it kind of stinks, but our workaround was just to restart the code whenever we power cycled. That reliably fixed the issue.

[ozrien]

Hey Jefferson, I think I have it figured out. Seems like calling joystick routines in the disabled loop has the undesired effect of causing the RIO's backend to crash/restart on power boot. It only happens once and doesn't affect much since the robot is booting up anyway. But there is a moment where when the CANTalon's object constructor's set up their messages, there is no one listening at the other end.

If you're grabbing joystick values in disabled() and using CAN Actuators I recommend calling one of the setXXX() routines on each CAN Actuator in the disabled loop. That way if this problem occurs, the code will periodically signal to the back end that those CAN objects exist and should be enabled. I reproduced your problem and tested the workaround.

So for your two CANTalons (or just do all of them), try calling set(0) in the disabled loop so that on-power-boot they get reregistered ok.

[Jefferson]

Originally Posted by ozrien

Hey Jefferson, ...

Omar,

Thanks! Just to make sure: calling a Get() function should be enough, right? I'd rather not disturb some of the position control with a Set() function.

[ozrien]

Gotta be a set. It will not disturb anything because it's in the disabled loop. It updates the control frame bytes, which aren't sent until after you enable.

[King Nerd III]

Originally Posted by ozrien

Hey Jefferson, I think I have it figured out. Seems like calling joystick routines in the disabled loop has the undesired effect of causing the RIO's backend to crash/restart on power boot. It only happens once and doesn't affect much since the robot is booting up anyway. But there is a moment where when the CANTalon's object constructor's set up their messages, there is no one listening at the other end.

If you're grabbing joystick values in disabled() and using CAN Actuators I recommend calling one of the setXXX() routines on each CAN Actuator in the disabled loop. That way if this problem occurs, the code will periodically signal to the back end that those CAN objects exist and should be enabled. I reproduced your problem and tested the workaround.

So for your two CANTalons (or just do all of them), try calling set(0) in the disabled loop so that on-power-boot they get reregistered ok.

Could this possibly be what is causing our Talons to not enable? We don't have a disabled portion in our command based framework, but could easily add one if it would help.

[ozrien]

Try it to at least rule it out.

[ozrien]

More info at Talon SRX Software reference Manual section 21.18