Program overloading the cRIO?

[Mark McLeod]

Looks better.

To check how long this takes to execute, you can use the Elapsed Times.vi located under Support Code in the Project Explorer window.
Just drag and drop a copy anywhere in your Teleop, double-click to open its' front panel, then use Run in Robot Main.vi to try it out on the cRIO. Watch the Elapsed Times front panel to see how long Teleop is taking. You don't want it to be longer than 100ms, in fact less than 20ms is best.

You might have an issue with your checks for x+y /= 0
Joysticks at rest don't always equal 0. There can be a trace non-zero value, way too small to move the motors, but the cases depending on exactly zero might never be active for that reason.
Depends on the game controller though, so it might not be an issue.

Did you consider making a single button on each joystick a toggle?
Last joystick to push the button gets all control.
Stick with what makes the most sense to you though.

P.S.
I'm pretty sure that you'll find that your Teleop is too slow.
You can isolate and identify the slowest parts by using the Diagram Disable Structure to gradually comment out groups of statements to see what causes the slow down.

[ablahblah]

Ran too slow on site, and had no time to test and remake code. Eventually I just dictated that the odds of a joystick failing are so slim that the redundancies were pointless, and I stuck in the backup non-redundancy program that i made the night before. Works the way we want it to now, I thought redundancies weren't too worth it in the beginning anyways. Ty for the support nevertheless though, certainly another pebble in the pile of programming knowledge that I've been building up!

[edzenitis]

We had similar problems to team 2893. After Autonomous mode finished, Teleop mode would work only half the time. I don't know if these are related or separate problems, but we were getting error messages about Robot drive being too slow, when Teleop did work it was sometimes sluggish, and data rate on the field was taking twice as long as the other teams. There seemed to be a pattern where we would deploy the code, it would work in Auto and Teleop. Then the next round, Teleop wouldn't work. When the code was redeployed, the same thing happened. This was repeated ~6 times during the tournament. We raised the radio up higher for the last two rounds, but had similar issues. We never experienced this when tethered to the cRIO.

We don't have a spare cRIO or I would try running the software using the Elapsed Times.vi to see if Teleop is running too slowly and try to isolate the problem. I'm posting the code if anyone is willing to take a look at it or possibly run it to see if the timing is reasonable or not.

[Greg McKaskle]

I believe that deleting the compressor code will solve the problem.

The compressor code is a bit more complex than it needs to be, and it looks to me like the GetEnabledState was intended to be placed a periodic task. The timeout of 100ms means that this is slowing down your TeleOp and causing the safety VIs to kick in.

Greg McKaskle