Failed to connect to Target. After Second Download

[chris_elston]

We are having a consisent problem with our 2013 and 2014 4-slot CRIO.

After imaging the CRIO to version 52. We can build and deploy the code once no problems.

The next time we want to build and deploy, we get a timeout. It starts to reformat the controller, but then gives a failed to connect to target timeout.

During this time, we have a DOS box open and we can PING the controller IP no problems. There is not a network connection problem.

The only way to download again, is to go through the process of downloaing the firmware again in the CRIO, then we can download once and we are back to the same problem. Can't download a second time, even though we can ping the controller no problems.

After we download the first time, we can drive the robot around no problems. We also have only 33% CPU utilization. Some people say that if your CPU is busy all the time, it times out when trying to service a download, but in our case, we have verified via the driver station that the CPU usage is only 33%. So I don't believe this is the problem why the second build and download never works.

It seems the 8-slot CRIO doesn't have this problem.

What suggestions can you give us to troubleshoot next?

[HollyBerry]

Do you have your build set to run as startup?

As you mentioned, the main cause of this is when the CPU is too busy to communicate back through the LV thread. When you are monitoring your CPU usage, is it showing at a constant 33% or is it varying up and down around that value? If the CPU is railed, the first thing you will lose is network communication from the cRIO. Since your CPU usage is being updated in the driver station through the network, it could be railed and still showing you a value of 33% since the updated value is not current.

A workaround to prevent re-imaging the cRIO would be to delete the app from the cRIO in a file browser. You can ftp into the cRIO and view the files on it by typing ftp:\\10.xx.yy.2 into a file browser.