Losing Communication with CRIO during Deploy

[MotorHead]

While trying somethings on last years robot a new problem has occurred in that when attempting to deploy new code I get a loss of communication error and the deploy halts and never starts again. This seems to only happen if code is already running on the CRIO. If no code is present prior to deploying, download is fine.

The workaround I came up with immediately was to re-image the CRIO to wipe out the old program. I searched some forum archives and saw discussions last year about using the NO APPS dip switch setting and resetting the CRIO. Haven't tried it yet, but it seems that should work as well and is a little faster.

What bothers me is this wasn't a problem all last year and now all of a sudden it is. I have installed Driver Station and Utility updates and CRIO image is the current one for the 2011 build season. FYI, we are also using LabView. Did this introduce the problem? Are any other teams seeing this? Based on archive posts from last year, a number of teams were experiencing this issue but I saw no conclusive answer as to the cause, only the work around solutions described above.

Would like to hear from anyone else having this issue and any other solutions/workarounds. Thanks.

[Alan Anderson]

Without seeing the exact sequence of what's happening to you, I can't be sure, but I have a theory. If your program is keeping the cRIO extremely busy, it won't be able to respond quickly to the programming computer's attempts to communicate with it, and LabVIEW will complain about communication problems. It's easy to overwork the cRIO like that -- all you have to do is forget to put a little bit of delay in a neverending while block. Check your code for fast-running infinite loops and see if you can't slow them down a bit.

[Mark McLeod]

Your symptoms are pretty typical of a saturated cRIO as Alan suggested. Common reasons include unregulated loops (add a time delay (Wait) of 10-100ms to loops).

Use the System Manager to see your CPU utilization on the cRIO.
This post describes how to use it.

[Tom Line]

We have had the same problem ongoing now since we began using the Crio's. Sometimes it will deploy, most often it will not. We have checked with the system manager and it does not show high utilization.

There are two solutions. You can get in the habit of throwing the no-execution switch on the crio so it boots without running the code, or you can reimage it. Either way will allow ou to deploy your code (just remember to change the dip switch back if you go that route).

We've met a number of other teams with the same issue, and I believe if you search you'll find other threads about the same thing.

http://www.chiefdelphi.com/forums/sh...517#post951517

[MotorHead]

Thanks for the feedback.

The project that started this was I just need simple arcade control of our robot. So I started with this years framework and added the vi's to telop mode for arcade control. The program does nothing else. So if any loop needs slowing down, it would be the the loop in Robot Main.vi. That loop repeatedly calls the telop.vi looking for joystick input. There are parallel loops for periodic task and vision, but they either have plenty to do (vision) or wait statements (periodic tasks). I would hate to have to intentionally slow down the Robot Main loop.

Out of curiosity, I will give a try this evening to see how that works. Maybe when the programs grow in complexity they tend to slow down on their own due to more overhead. But when the framework is used for just a simple task, it needs to be slowed down a little. Seems a bit odd, but hey, it is programming!

[lscime]

We've had similar issues in the past. Our current understanding (after talking to NI and doing our own testing) is that sometimes the cRIO is "too busy" running already deployed code to communicate with the computer properly. We came up with a solution that has worked well for us and other teams that have tried it. The steps are listed below:

1. Turn off your robot.
2. Flip the "no app" dip switch on the front of the cRIO. This tells the cRIO not to run the code on startup.
3. Turn on the robot and wait for it to boot.
4. Build and deploy your code.
5. When LabVIEW prompts you to restart the robot - flip the "no app" dip switch back to the original position and finish rebooting the robot.
6. Now you should be ready to rock and roll.

Hope this helps,

-Luke

[lscime]

Also, here's the original thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=84311