Reflash of cRio to deploy labview code

[Sparktracer]

Hello CD Community,
I am a mentor for team 5201. We are currently compeating at Troy, Mi Regional and have ran into a problem that has stumped the FTA's. In order to make any change to the LabView code we found that we have to re-flash the cRio every time. Here is a brief description of events.
cRio has running and functioning code. Need to make motor speed change in Auton.
Adjust value in Auton code. Save change.
Connect programming computer to cRio to test.
Ensure communications and robot code are good in Driver station.
Click RUN button in Robot Main VI
Get message that target already has code deployed. OK to run test.
Ger the following messages, with error:
Waiting for the target (RT CompactRIO Target) to respond

Image of error is available on NI:
https://decibel.ni.com/content/thread/21245?tstart=0

We found out late this evening, after changing cRio(not the problem), that another team has the exact same problem at the Troy event.

We are looking for input on possible root cause and solution.

Our programmer is in the process of writing complete new code (about 30 minutes, no camera, rookie team). We noticed that the backups that we have been saving are starting to get buried about 6 folder deep. We are going to try a fresh build at the deslktop to see what happens tomorrow. We have tried 2 cRio's and 2 different programming computers and can reproduce the problem very regularly.

Our current work around is very time consuming.
We modify our code.
We re-flash the cRio (about 6 minutes)
We then can Run the code from Robot main to test. If we have enough time, we can adjust code and re-run to test.
Once testing is complete, we build and then Run at Startup.(about 2 minutes)
As you can see, just the flash and run at startup takes a good 8 to 10 minutes. This does not leave much room for testing when you have scheduled matches 8 to 12 minutes apart.
If we run at startup, our next code change will require another re-flash of the cRio.

Some people are thinking that we are corrupting the cRio if we do a run-continious and/or use the red stop button after testing. we tested this tonight and using only Run and the Finish button in Robot Main and still locked up the cRio trying to run a test.

Any assistance would be greatly appreciated.

Thanks in advance from Team 5201

[Joe Ross]

Rather the doing a full re-image of the cRIO, try going to the imaging tool and turning on the no-app switch and then reboot the cRIO, reload your code, and then go back the imaging tool and turn off the no-app switch. Unless the cRIO image is actually getting corrupted (not likely), this is a faster way to get no code running on the cRIO. The most common reason for deployment errors like this is the code already running on the cRIO.

To get to the root cause of the problem, what is the cRIO CPU usage and RAM usage when running. These are shown in the Driver Station charts tab. Swamping the CPU or using too much ram may interfere with the deploy process.

[Sparktracer]

Joe,
Thank you for your reply. I had worked with Andy from NI in the past and we have seen issues when using the no-app switch. I agree that this is a faster way to load code, but not the fix to the root of the problem.

Working with the CSA at Troy, we were able to locate the root cause of the problem.

We had a ref call in periodic tasks that had accidentally been disabled in begin. This was causing the controller to lock up during a deploy.

If you happen to have this problem, or one very similar, verify that you have good code in periodic tasks.