CRio waiting to respond

[Greg McKaskle]

If you click to the Diagnostics tab of the Driver Station, does it have a lot of errors, or a steady stream of errors? If so, see if fixing those errors helps with the difficulty deploying. Also, look at the Charts tab to see if the CPU usage is very high.

Greg McKaskle

[Laxkief9098]

The computer's CPU usage is relatively low (10%) and the following errors occurred and I am not sure how to fix them:

Warning <Code> 44002 occurred at Ping Results: link-GOOD, DS radio(.4)-bad, robot radio(.1)-bad, cRIO(.2)-bad, FMS-bad Driver Station
<time>2/17/2014 3:55:33 PM<unique#>17
FRC: Driver Station ping status has changed.

Warning <Code> 44004 occurred at Driver Station
<time>2/17/2014 3:55:32 PM<unique#>16
FRC: The Driver Station has lost communication with the robot.

WHat can I do to resolve these errors because the first error (44002) has always appeared; however the second error (44004) is new.

[Greg McKaskle]

If you look at the timestamps, the communications goes down. This means that for over one second, no valid status packets from the robot have arrived. About one second later, the ping is performed, and the radios and cRIO are not there. Without knowing your system, I'm not sure if it is just the cRIO that disappeared or if the radio in-between caused the issue.

Note that the DS doesn't know about intent, and these errors often show up when you reboot the cRIO, deploy and restart, etc.

Greg McKaskle

[Laxkief9098]

Are there any solutions I can try because the problems continue to persist when I am hardwired into the CRio directly, bypassing the D-Link? How can i fix it if it is the CRio that disappears?

[Greg McKaskle]

Can you post a picture of the deployment dialog?

Greg McKaskle

[Laxkief9098]

The deployment decided to work most of last night and it was not until later that the deployment process failed. I attached a picture of a screenshot. The deployment process failed yet I am able to ping the CRio.

[chris.boyle]

I am also interested in how to get past this particular issue, as we have been seeing this a lot also.

One method that works for us is to start the cRIO Imaging Tool and change the NO APP setting to TRUE and apply. Then deploy the code. Restart the cRIO Imaging Tool and set the NO APP back to FALSE and apply these changes.

[Laxkief9098]

Is there a solution that fixes it so that we do not have to use the re-imaging tool every time we need to deploy code?

[Greg McKaskle]

At this point I don't have a project that shows the issue in a reproducible way. Please contact NI technical support and see if they have suggested solutions, and see if they would like a copy of your project and files so that it can be investigated more thoroughly.

Greg McKaskle

[adciv]

We've seen this occasionally over the past few days in our marathon programming sessions (code, deploy, test, repeat endlessly). If rebooting the Rio/Radio doesn't fix the issue, we then reboot the Computer. Occasionally Windows is the problem.

[chris.boyle]

Originally Posted by Greg McKaskle

At this point I don't have a project that shows the issue in a reproducible way. Please contact NI technical support and see if they have suggested solutions, and see if they would like a copy of your project and files so that it can be investigated more thoroughly.

Greg McKaskle

I took his advice and called NI on bag day, unfortunately I did not have the cRIO in front of me at the time. Tech support was very helpful and mentioned a couple of things to look for to identify the reason for not being able to deploy code.

1) Check for high CPU utilization:
If the CPU utilization is too high it does not deploy code. It pegged at 100% for a few seconds during the start up. Our CPU was running between 35 - 40% after initial start up was complete. This was still too high for our 4 Slot cRIO.

2) Check for CPU utilization with no applications running:
Reformat the cRIO, reboot and run without deploying any code. Check the CPU utilization at this point. We were running at 0%. If there was any CPU utilization, I was supposed to call back before they closed at the end of the day.

I offered a copy of our robot project code to test with. They said due to the many different environments, it would be a very generic test and may not reproduce our situation.

The suggestion was:
A) Use the cRIO Imaging Tool to set the NO APP Switch
B) Reboot cRIO
C) Deploy code
D) Use Imaging Tool to turn off NO APP Switch
E) Reboot cRIO

These steps are also necessary if we want to run the code from a laptop to debug. It is a viable work-around for now. I can imagine this becoming an issue at competitions if we need to redeploy any code in between matches.