We decided to switch from PWM Talon to CAN Talon SRX to try and take advantage of the integrated closed loop capabilities
Out first test was to use the CAN Talon’s straight out of robot builder as part of a dual motor controller drive train.
All the code works correctly except that when we disable the robot then re-enable in tele-op, the motors don’t move (and the LEDs on the CAN Talon’s) don’t change colors red/green - they just blink yellow)
Restarting robot code solves the problem. We switch back to PWM talons and all works correctly. We are suspecting something happens to the motor controllers when we disable. The CAN Talon SRX manual makes note of needing to service the controllers during disable_periodic. Curious if anyone else has this issue.
I was reading the Talon software manuals last night and I’m planning on checking the status of the Talons on the Roborio web page to see if they are disabled. We did confirm with the debugger that we are correctly calling the robotdrive “drive” functions with a valid magnitude and curve, so it feels like the CAN Talon is disabled…
Looking at the self test results of the CAN Talon SRX in Roborio web page:
When our code works, the Talon’s report Enabled/Mode 0
We then disable and re-enable in teleop mode and the Talon’s report “Enabled/Mode 15”
It seems like the CAN Talons switch to mode 15 when we disable. We tried setting the modes back to 0 in the teleop init, but it doesn’t seem to force them to change mode (Roborio still reports them as Mode 15)
Continuing to read Talon SRX Software User’s Guide for hints…
Our talons are exhibiting the exact same behavior, except it happens DURING teleop. We have been experiencing comm issues, loosing comms every few seconds, so I guess we are switching from disabled to enabled, but that’s a problem for a different thread.
Looking at WPILIB c++, RobotDrive appears to call Disable() when RobotDrive::StopMotor() is called. But it doesn’t Enable() anywhere. Are you calling StopMotor()? If so try setting the output to zero using the normal routine instead (arcadeDrive, tankDrive, etc.).
We are calling stopmotor() at then end of our autonomous. I realized this last night and had theorized something like you discovered in the WPIlib source…
Yes, this was the first thing we tried last night once we discovered Mode 15. It appears to give us consistent operation toggling enable/disable in Teleop. We still have an issue going between autonomous and teleop, but I believe this 16.12 workaround is certainly poking at the problem area…
This effectively solved our problem. The root cause was motor safety helper timing out occasionally (robot builder was enabling it by default as part of the drive train init) and a call to StopMotors in our autonomous code. Both of these events set mode 15.
We now have reliable open loop control of the CAN talons…now on to closed loop!