No Robot Code

[alex42]

Thanks for the suggestion, but I don't think it's that. The code seems to compile just fine, and most of the time it runs just fine. When the cRIO doesn't work, it's still the same code running, so it doesn't seem to be the code. I also don't think that the necessity of reloading the code after reimaging the cRIO is what fixes it, since we load new versions of the code all the time, and at least once we loaded new code while the problem was happening and that didn't fix it.

[alex42]

By the way, the problem has ceased to go away when we reimage. It does not happen though with the default FIRST code, so it seems to be a code problem. However, it also doesn't happen with archived code from a week ago, even though it clearly should if it's a code problem.

[alex42]

Correction: yesterday the code from a week ago worked. Today it doesn't. Default still works though.

[Greg McKaskle]

Reviewing the meaning of the LEDs may help a bit. The robot LED means that the robot IP ping succeeds. The communications LED means that the communications task on the cRIO is responding to the control packets being sent from the DS. Finally, the Robot Code light really means that the robot code is calling into the communications task often enough.

If the cRIO is vastly overtaxed by the code you are writing, it might behave the way you describe, where the WPI framework is not being updating the battery value and other fields as it is supposed to.

I don't remember what language you are using, but if you can determine the CPU usage via spy or a similar tool, it may help you figure out what portion of code is responsible.

Greg McKaskle