IF NEEDING HELP POST HERE!

[J-Mech]

Hello,

Thanks for putting this post up. Our team is having trouble connecting to the cRIO. We have tried reformatting it and reinstalling both Wind River and LabVIEW several times. We can ping the cRIO; however, when we go to connect to it or build and place code onto it the programs will not connect. We do have the latest images and updates as far as we can tell. The error we get most often is that it failed to launch the target server. Do you know of any reasons this may be happening? Everything is wired correctly according to the diagram.

Thanks in advance for your time.

[nick_champ_2]

Just the basics I figured you have covered but still have to verify. Do you have your up address set in the crio, the computer, and how do you have the items connected.

[DavidGitz]

I would try connecting the cRIO with a crossover to your development computer and try to connect from there. I would make the IP settings on your computer 10.xx.yy.7, 255.0.0.0 and 10.xx.yy.2

Is your classmate able to see "Communications" from the Driver Mode?

What is the RSL pattern? That could give some information too.

This is from last year's documentation, but I assume* it is the same.

Solid ON = Autonomous Enabled
Solid ON, but blinks OFF every 1.5s = Teleoperated Enabled
Slow Blink (900ms on / 900ms off) = System disabled; caused by system watchdog, user
watchdog, or Driver’s Station set to Disabled.
Fast-Slow Blink (200ms on / 900ms off) = Low battery (<12 Volts) or no user code and system disabled either by system watchdog, user watchdog, or Drivers’s Station set to Disabled.
Fast Blink (200ms on / 200ms off) = System error: No Driver’s Station communication, bad cRIO Image, bad team ID, extensive communication errors. (I assume it's this one).

[J-Mech]

Yes we have the IP set up for the cRIO and it is connected to the developer computer with the Ethernet cable. I connected the system to the classmate and it was a communications error(Fast Blink). I have verified that all of the IP addresses are set to what the manual gave for configuring the cRIO.

[gr8dragon]

Im sorry if this is the wrong place to post this, but I am having great difficulty getting values from the vex ultrasonic sensor(using windriver). I seem to get either zeros or INF. Could it be the way i have plugged it in?

[DavidGitz]

Originally Posted by J-Mech

Yes we have the IP set up for the cRIO and it is connected to the developer computer with the Ethernet cable. I connected the system to the classmate and it was a communications error(Fast Blink). I have verified that all of the IP addresses are set to what the manual gave for configuring the cRIO.

If I understand what you're doing correctly, that won't work. The cRIO port 1 is the only port that can be used for communication, port 2 is for sensors/other devices. So from what I understand you have setup, you have the development computer connected to the cRIO port 1 (using an ethernet cable, which is wrong, should be a crossover). You also have the classmate connected wirelessly to the Bridge, and the Bridge ethernet cable is connected somewhere it shouldn't be.

The first configuration I would try is connect your development computer with a crossover cable to the cRIO port 1, and using the IP settings I gave earlier. If you can ping it, that means that the cRIO is imaged, I believe. I would stick with the LabView image if you follow my troubleshooting advice, since I don't have working knowledge of WindRiver. Then you should connect to the cRIO using LabView with a default project and build/run as startup to get working code on the cRIO.

After all these steps are completed successfully, I would start with checking out the wireless configuration/communication with the Classmate.

If you are unsure of anything I've said here, refer to these documents:
http://www.usfirst.org/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2011_Assets/Kit_of_Parts/How_to_Build_and_Load_Programming_in_LabVIEW,_C,_a nd_Java.pdf
http://www.usfirst.org/uploadedFiles...cRIO_Rev_A.pdf

I really wish they would have made the control system instructions in one document this year, so teams knew how to progress through the documents instead of a collection of separate documents. If they would have been consolidated (like last year) I believe that your team would probably not be having this problem.