Problem connecting to the CRIO

[silas13579]

Well the reimaging of the CRIO seemed to help. We just tried deploying a default robot project, and the CRIO was still not accepting it. Then we switched to our practice bot, with a different CRIO and a different ethernet and tried deploying our code, which didn't work, and then tried deploying a default project onto that, and that too did not work. They both were stuck in the same "waiting for the target (RT CompactRIO target) to respond."

[Mark McLeod]

Reimaging the cRIO works (in a brute force kind of way), because as a side effect it wipes out your user code that is responsible for the problem.

The No App switch (a DIP switch on the 8-slot or for the 4-slot virtual through the cRIO Imaging Tool) disables your user code when the cRIO is reset and is quicker.

[Greg McKaskle]

Exactly. And once the errors on the diagnostic screen are fixed, neither will be necessary. Until they are fixed, don't Run as Startup, use the run button instead.

Greg McKaskle

[silas13579]

Alright so I'm getting confused now. What is the diagnostics screen? The part of the driver station? Because I'm not sure how it may be in our code, seeing as the default robot project didn't deploy either.

[Mark McLeod]

It's not the code you are deploying. It's the code already running on the cRIO from the previous deploy.

The Diagnostics tab on the Driver Station has a message window.
There are a lot of warnings that can obscure the real error messages, so copying and pasting all of them into a text file makes them a lot easier to look through.

You can also look at the Driver Station log from the Charts tab, in the lower right is "Launch Viewer."
You have to pick the latest log or two by date, then look at the Event List tab for error messages.

[silas13579]

I'm pretty sure I found the error. We were kind of recycling last years code, and last year they had nothing in finish.vi, so this year we assumed that we could go the same. Would this have been causing the problem? I'm in the middle of fixing it right now, so I can update with whether it works.

[silas13579]

Nope never mind it's still not working. We have tested deploying quite a bit today, and it seems to work after we flash it until the first time we perma deploy onto the robot, which then causes every attempt after that first perma deploy to fail, until we flash it again. It also occasionally gives this error: Access denied: Another project is using this target. You must disconnect the existing project from the target or restart the target before establishing a new connection. Note: The existing project may be running on a different host computer.

[Mark McLeod]

That pretty much proves that it's your code.

If you want to post it we can help track it down.
The Driver Station log might show very high CPU utilization.

[silas13579]

After searching, we still can't find any errors, so we will just only perma-deploy once code is finished, and temp deploy at all other times. We also created backup code in java.
Thank you all for all your help.

[Levansic]

What did you put into your finish.vi? Make sure every peripheral opened in begin, is closed in finish.

By any chance, are you using CAN? We've had these issues when a Jaguar couldn't respond back due to not being connected.

[Danny Diaz]

Just as an FYI, FRC418 practically NEVER updates code via the deployment method. On a 4-slot cRIO, it's just a major pain in the butt to get the device into Safe Mode to be able to upload code.

We only FTP file updates. Assuming you don't try to run code "interactively" via the "run" button from within "Robot Main" (which disables the "Run as Startup"), we just FTP the startup.rtexe file created by the build process. It is 100% effective, and "deployment" takes seconds - instead of minutes. Remember you have a full file system under the hood, and the "deployment" phase merely uploads the startup.rtexe file (via mechanisms that seem to always be thwarted by bad robot code) and sets a token within ni-rt.ini that tells the system to load the file. If you do that manually, it always works.

-Danny

[Alan Anderson]

Originally Posted by Danny Diaz

We only FTP file updates.... It is 100% effective, and "deployment" takes seconds - instead of minutes.

The standard Run As Startup also only takes a few seconds this year. It's obvious that there have been some highly effective fixes made since last year's version.