[FTC]: C-Rio cant connect to target...again

[whcirobotics]

The problem is here.! again...

We are able to to deploy our code to the robot with the ip address 10.15.14.02 while connected to the wireless router and doing the build > deploy > run as startup method.

But We know and knew that there is a easier way then waiting 10 -15 minutes just testing the code. And that was the "run" button on top of the robot main. But whenever we press it, it gives us the deployment window, and as it continues, in halfway it gives the error " Waiting for real time target (RT compaq rio target) to respond." ...

And it never responds. Why may this be the case? We can deploy the code and it works, but when we try to do it via the "run" button it never works. This has been the case since the last season and we want to fix it so it isnt as hard to test code as it had been the last season. Help Needed please.

{WHCI robotics}

[Andrew Schuetze]

I have no help to offer you on this specific issue and I beleive that there are others that will be able to offer some advice.

I am not certian it will make much of a difference as a lot of folks use the portal view instead of the forum view when searching CheifDelphi. However, you have posted your FRC question about the cRIO and deploying code in a forum for the FIRST Tech Challenge. So some FRC types won't be looking here.

You probably want to post this in a FRC programming or controls technical forum.

[PhilBot]

In order to do a "Run" operation I beleive the cRIO has to unload the currently running application. This may be what is causing your problem.... It may not be being unloaded sucessfully.

One alternative that is easy to try is to set the DIP Switch on the cRIO to tell it not to run anything on startup... thus leaving the processor free to load your new program.

You'll need to check the manual, but if you flick that switch and reboot, the robot will start up "naked". You can always put the switch back to get your normal run-on-startup behavior.

[Mark McLeod]

This got solved.

The problem was some left over default framework example code was causing rapid errors and sucking up all available CPU cycles.