Waiting for cRIO to respond

[CALICAWESOME]

So it's a day before the end of the build season (go team go) and we've encountered a last minute coding problem in labview. I'm sure this issue has been asked about, and resolved countless times, but I've scoured the internet, and haven't yet found a solution.

So we're connected to our bot, cRIO is all formatted, and jazz, ip 10.22.62.2, Computer's ip is at 10.22.62.6, subnet mask 255.255.255.0, and default gateway set to 10.22.62.4. The driver station is giving us a green light on communications, and a red on robot code. I've tried pinging 10.22.62.2, it's giving me an okay, so the computer, and the driver station can connect to the cRIO, and everything is fine until we hit labview. Our RTA is built and set as startup. Once I try and deploy our code to the robot, everything goes fine, we get the conflict resolution saying all the VIs are part of a Real-Time Startup Application, the console displays that it's deploying everything, then it shoots us "Waiting for Real-Time target (RT CompactRIO Target) to respond" twice in the deploy console, and goes into an eternity loop of waiting. If it helps, when I start the deploy, the little green dot next to the cRIO thumbnail in the project browser is off.

We had this problem last year too, I have no idea how we fixed it (we came dead last in our regional anyways... heh heh heeeh...). Please help D: We're a not-very-experienced team at a loss of how to deal with this problem.

[Alan Anderson]

If you haven't installed the second LabVIEW update, then you might be suffering from SmartDashboard Paralysis. There was a bug that prevented the running cRIO code from terminating when the download process asked it to, and things hung at that point.

The workaround (before the update corrected the problem) was to not have the Dashboard program running when beginning to download code to the cRIO. A simple way to do that is to temporarily select "remote dashboard" on the Driver Station's "Setup" tab.

[propionate]

We faced a similar problem, and simply reimaging the cRIO fixed it for us. Worth giving it a try, unless you already have.

[bvisness]

Our team just recently encountered this same issue with our 4-slot cRIO. We found that a reliable way to fix it was to FTP into the cRIO (using just the IP, no password), going into "ni-rt", and deleting the "startup" directory. It fixes the problem every time, although the cRIO sometimes has to be rebooted first.

I'm not sure if that's what "Unset as startup" already does, but I know it works for us.