cRio requires imaging before every deployment

[billbo911]

We are having an issue with one of our cRio's. Whenever we want to deploy modified code to it, the process fails as LabView goes into a loop while waiting for the cRio to respond.

With a couple off season tournaments left, we want to be able to modify our code when needed. Currently the only solution we have found is to run the cRio Imaging tool and format it first. When we do this, we can deploy the newly modified code. The problem is, this is quite time consuming and doesn't always work well between matches.

This "failure mode" used to only show up every now and then, but lately, it happens every time.

Has anyone else had this issue, and if so, did you find a solution and what was it?

[Mark McLeod]

Usually in this case, setting the No-App switch in the cRIO Imaging Utility (or the physical DIP on an older 8-slot) and do a reset the cRIO or restarting it will then allow you to download new code.

[billbo911]

Originally Posted by Mark McLeod

Usually in this case, setting the No-App switch in the cRIO Imaging Utility (or the physical DIP on an older 8-slot) and restarting the cRIO will then allow you to download new code.

Thanks Mark, we will take a look at that option ASAP, might even be this evening.

[Greg McKaskle]

Adding to Mark's suggestion. This failure to download is generally caused by errors that are being caught and logged to the DS while the download occurs. It is complicated, but basically the error handling, as implemented six years ago for FRC uses an obscure hook that transitions to the UI thread in order to catch the error. This is time consuming, and it turns out, not something the download code ever expected to happen. So if the phase of the moon and other things align, the deployment code will get its state confused and it will give up trying to download, but won't really tell you that.

We are using a new error catching mechanism in 2015, BTW. No more thread switches for us.

Greg McKaskle