Crio not responding to code deployment

[randalcr]

Hey all, so we have reached that part of build season where the Crio starts acting up for no apparent reason. The issue is that when we try to deploy code to the robot, the deployment progress stops at "waiting for the target to respond". Sadly the target never responds, and we have reboot the crio several times or in most case, re-image it entirely.

I have no clue where to begin on troubleshooting this, but have found that it does it regardless of whether the driverstation and dashboard are open on the same computer doing the deployment or if they are on two separate machines. We have tried swapping out the crio with a different one, but the problem persists.

Is there an update for labview out or something that we've missed?

[RufflesRidge]

When you are having this issue, if you go to the Charts tab of the Driver Station what do you see for the red cRIO CPU% plot? Is it at 100%? Your application may be starving the cRIO CPU making it difficult for it to respond to other processes like a new code download.

[randalcr]

it's happening right now, and the chart says that the Crio CPU is holding at 0%

It's acting like the deployment is hung between wiping the current code from the crio and putting the new code on

[Greg McKaskle]

One thing that can happen is that the code on the cRIO is constantly throwing errors and the error console is running almost constantly. It is bad enough that this slows things down, but in some situations, it can cause the deployment to drop its state. This means that both machines are waiting for each other, not aware that the conversation was dropped. The fix was too risky to put in this year, and the solution is to fix the issue that causes constant errors.

You can verify this is the issue by opening the Diagnostics tab and seeing lots of errors flowing by. You will also see high CPU usage at that point. Try other robot modes to see if the errors can be avoided. If not, use the imaging tool to set the no app switch. You could also ftp, delete a file, and reboot.

There is almost never a reason to image the cRIO except for at the beginning of the season or unless you've glob'ed when you shouldn't have with ftp. I'm not sure I've ever seen evidence of a corrupt file system. Of course the imaging step won't hurt, but it is the tin-foil hat for SW problems.

Greg McKaskle

[randalcr]

Thanks Greg. It's currently stuck at 100% CPU usage. We're going to try isolating the code from the issue and see if we put in a bad loop or something somewhere.

[Greg McKaskle]

Sounds like a good approach.

Curious if the error are happening, or not?

If you have trouble getting to the bottom of it, post more details, like code.

Greg McKaskle

[randalcr]

the only errors we are getting are the occasional bad refnum errors for our solenoids and ultrasonic sensor that we dont have plugged in to the robot. We were getting tons of watchdogs last night, but we had a change that corrected that.

[Greg McKaskle]

OK. I would be surprised if maxing out the CPU alone would cause this issue. To get technical, it has more to do with thread transitions than CPU usage.

It may be worth checking the Begin and usage for the sensors and solenoids. A missing analog sensor and many other connections will not cause a SW error. In many cases, the SW cannot tell it is missing. The error is more likely due to a mismatch in naming or configuration.

Greg McKaskle