One side of drivetrain not working properly

[MrTechCenter]

For some reason, whenever we enable our robot, the left side of our drivetrain runs at full power. We can still override it with a joystick...to an extent. When the joystick value returns to "0" the motors continue to run. We are using VexPro ball shifters with two CIMs per side all being controlled by four Victor 888s. The Victors are connected to the Digital Sidecar via two PWM-Y cables, one for each side. We are using LabView 2013 for programming.

[BitTwiddler]

What happens if you disconnect the PWM cable for the left side?

[MrTechCenter]

The left side doesn't run.

[Kusha]

Try replacing the ribbon cable from the c-rio to the sidecar.

[MrTechCenter]

Replacing the ribbon cable did not help.

[BitTwiddler]

The left side doesn't run.

OK, something is commanding the motor controller to go forward (or reverse as the case may be). i.e. you are getting a pulse width <> 1.5 ms.

[MrTechCenter]

It is definitely a code problem, because with a brand new cRIO project, it worked fine.

[BitTwiddler]

[QUOTE=MrTechCenter;(30 minutes later after looking through every inch of the code): I found the problem! PWM was backwards./QUOTE]
It's amazing the way those pesky cables manage to turn themselves around, isn't it?

[MrTechCenter]

All PWMs are plugged-in correctly and into the right ports on the Digital Sidecar. It worked properly when we tried it once and we didn't change anything after that on the robot or the code except for accidentally breaking a single wire in the code and replacing it, and we made sure that everything else was exactly the same, and no other wires in code were broken. But for some reason, it's not working again.

[BitTwiddler]

It is definitely a code problem, because with a brand new cRIO project, it worked fine.
Agreed. I think it is the code.
I bet it will run fine with another try with a new project using the default FRC code.

[Mark McLeod]

All PWMs are plugged-in correctly and into the right ports on the Digital Sidecar. It worked properly when we tried it once and we didn't change anything after that on the robot or the code except for accidentally breaking a single wire in the code and replacing it, and we made sure that everything else was exactly the same, and no other wires in code were broken. But for some reason, it's not working again.

If you want to zip up the entire project and attach it, we can take a look.

[Team3266Spencer]

Did you try re-calibrating the victors?

[MrTechCenter]

The coding laptop is at our shop, so I can't upload the project as of right now. We have not yet re-calibrated the Victors. Tomorrow, we are going to just start our code over from scratch and see if the problem reoccurs.

[apalrd]

Unplug the joysticks and plug them back in.

When you plug in a joystick, it re-calibrates itself to zero where it is when you plug it in. If you leave a gamepad upside down and plug it in, and it is resting on the stick, then when you pick it up and it spring returns to center it will have learned an incorrect zero point and will now be holding a nonzero value at what should be zero.

In LabVIEW, if you hit the Run button in code and wait for it to deploy, you can click on a wire to view the value of that wire in a probe watch window. That can be helpful for finding where numbers come from in more complex code.