Since that thread, our cRIo died. We got NI to send us a new one, which arrived today. So, right after we run the new LabVIEW update and DS update on the classmate, we hook up the new cRIO, image it, and load our code. When the cRIO boots again, we see the intermittent “no robot code” problem has returned. We thought that was a cRIO problem, but apparently we were wrong. So, as a test, we run the default robot project. It seems to work fine (although we don’t have any sensors connected other than the camera and we don’t have any outputs connected besides a few jaguars, so there could be I/O problems we don’t know about) except for the flashing of the status light. The status light, when the robot is set to engaged, gives the fast blink (indicating System error: No driver’s station communication, bad cRIO Image, bad team ID, extensive communication errors.), more or less. Every two or three blinks, it would give one blink that was even faster, hardly more than a flicker. However, sometimes the faster blink would go away for several minutes. The DS was getting perfect communication, we had checked that the cRIO was set to the correct team number, and we had just installed the LabVIEW update, which contains the new cRIO image, less than an hour ago, so it seemed unlikely it had been corrupted. During our testing, we also noticed that the lights on the shelf the solenoid breakout board was plugged into weren’t lighting up at all. We tried removing the shelves for the analog inputs and solenoids, but that didn’t help. In the process of all this, we reimaged the cRIO repeatedly, so we decided to try my code again. It still gave “no robot code” intermittently. We determined that running from the front panel vs. running as a startup application made no difference for either problem. However, at one point during this testing, the default code failed to load, saying it was corrupted, but we recompiled it and then it worked. Then, the DS started saying the battery was at 00.00 volts. We switched batteries, which accomplished nothing, and then tried booting the cRIO into safe mode and then back out again. That also had no effect, and at that point we had to call it a night, having accomplished nothing more than establishing a lot of things that were not causing the problems.

I forgot to mention: the lights on the cRIO do not seem to be indicating any problem (at least when running default code; we forgot to check when running our code). None of the lights are blinking, at least, which some of them ought to be if there’s a problem.

You’re using some terms that I don’t quite follow. What does “robot set to engaged” mean? What are the “shelves” for the analog inputs and solenoids?

When the Driver Station reported zero for the battery voltage, did you have power supplied to the Analog Breakout on the cRIO module in slot 1? That’s where the cRIO reads the value from.

What Robot Signal Light are you observing, the big amber one or the little green one on the Digital Sidecar? When the big one is flashing, is the green one flashing exactly the same way, or is it on steady with a brief flicker off every second and a half?

Whoops, I meant to say “enabled”. I might want to start proofreading my posts.

I generally use the words “shelf” and “module” interchangeably.

The Analog Breakout probably was unplugged at the time.

We didn’t bother to check the little green light on the Digital Breakout board, since we know that the big light just echos the little light. We could check that though, and if it isn’t blinking the same signal then we’ll know something’s very wrong.