[Greg McKaskle]

Just to elaborate a bit on how the logged info can help identify the culprit.

The Log File Viewer should appear in your Start menu and can be launched from your DS on the Charts tab. After you experience a reboot, a dead bot, or some other confusing event on the robot, I'd encourage you to note the time of the event according to your DS laptop. Then you can locate the log file that contains the info.

In the log file, you'll see a plot of robot voltage. If the voltage dips at about the same time as the communications loss, it is a reasonable guess that they are related and worth investigating if low voltage condition was the cause. If you let the robot reconnect, the cRIO will actually tattle on the radio if it was up the whole time but also saw that the radio was unreachable. This shows up as a event marker when reconnection takes place. Hover your mouse over the events and their text will show up in the lower left text box. If the event doesn't exist, then it is likely that the cRIO was also rebooting due to low power. By the way, the cRIO also logs an event each time it boots, so that helps to determine if one, the other, or both devices rebooted.

It isn't always a problem with power, so the log will also show CPU usage. It is quite easy, especially with C++ to crash the cRIO, and all languages make it easy to get hung in a loop. If voltage is normal, the red CPU trace may offer insight into why the code wouldn't respond.

Finally, the green and blue plots are for communications quality. In some circumstances it isn't power or code, but external conditions like an arc welder, a microwave oven, or a super-crowded network. The cRIO doesn't reboot, it simply can't talk to the DS well enough to operate safely.

If you are struggling with issues like this, please ask. The tools can always be improved, and many folks do not know how to read the logs that we have.

Greg McKaskle