cRIO Does Not Communicate, Yet Can Be Pinged and Re-Imaged

[1951-44U]

Once, we had code working in C++ on the practice base, which could drive around and shift via pneumatics. Then the next day, we tried to download basic encoder initializing code that was based off the working code, and found that the cRIO did not accept the code (aka it showed "No Code" on the Driver Station). Then we shifted from our brick-like Dell laptops to my Thinkpad that I brought in with WindRiver to try out. It worked.

So we got the encoders to output basic values such as period, and closed shop for the day. The next day, when we came back in and re-connected everything to work some more on the encoders, the robot refused to communicate with the rest of the system. The driver station displayed "No Comm". Using my laptop, I could ping all the individual components of the system, the cRIO and the Driver's Station. We tried a direct connection between laptop and cRIO. That did work, but WindRiver would not connect with the "target server" (aka the cRIO). Pings, re-images, all still worked. Then we tried it wirelessly. Pings still worked (we didn't attempt to re-image via WiFi as we feared the time it would take). Driving and the driver station didn't. Then we tried restarting everything without the laptop in the system. That didn't work. Then we re-imaged the cRIO and tried all of the above again. It didn't work.

In addition, the digital input module on the cRIO had LED's that would cascade when everything was in order. It is not cascading now. Also, the signal light does not light up at all (I thought it was an indication that something on the robot, namely the cRIO, had gone awry -- a re-imaging blew that theory). All connections are tight, the batteries are of ample power and voltage.

There were several posts on NI about the "No Code" issue (http://decibel.ni.com/content/thread/2321), which I believe may have been an error in differences of individual updates on our old laptops. However, we did nothing to the robot between closing shop on the day we got it to work and booting it up again the next day, and it now refuses to communicate.


Any ideas on how this may have happened? Thanks in advance for any contributions.

[kamocat]

My best guess is that your deployment didn't set the real-time application to run as startup, and so when you reboot the cRIO, it doesn't automatically run your code.
I'm sure you know that in reimaging the cRIO, all your code is removed.

Please describe in more detail your procedure for testing connectivity with the driver station? Are you deploying code to the cRIO first, or are you just booting up the system?

[Greg McKaskle]

A cRIO that is running the OS can be pinged and it will respond. If it is also running robot code, it will respond to the FRC protocol and will show as having robot code.

The cascading lights last year were not on the digital breakouts, but on the relay module, and that was a "feature" of the default project image and could have been in your code as well I suppose.

Greg McKaskle

[1951-44U]

Originally Posted by kamocat

My best guess is that your deployment didn't set the real-time application to run as startup, and so when you reboot the cRIO, it doesn't automatically run your code.
I'm sure you know that in reimaging the cRIO, all your code is removed.

Please describe in more detail your procedure for testing connectivity with the driver station? Are you deploying code to the cRIO first, or are you just booting up the system?

We use WindRiver/C++, so we download the code. What happened was that we fixed the "No Code" error and was able to do a good bit of programming, but it was getting late and we wanted to resume a few days later. So we turned everything off and put it away, without deleting or re-imaging anything, so the old program was still there. When we set up everything (DS, Robot, Laptop), the robot refused to connect with the DS once we turned it on. The status light didn't blink at all, which I found suspicious.

First thing I did was ping IP's, and checking all the IP's of the DS and the cRIO, found no problem. I could also re-image the robot from the laptop, which would declare successful on the laptop but upon reboot of the robot after reimaging with default code in it, the robot still refuses to connect. We did this several times. We also tried it with wireless modem. We confirm that the wireless bridge and router are connecting and communicating with each other, but still can't control the robot with the DS.

Originally Posted by Greg McKaskle

A cRIO that is running the OS can be pinged and it will respond. If it is not also running a robot code will also respond to the FRC protocol and will show as having robot code.

The cascading lights last year were not on the digital breakouts, but on the relay module, and that was a "feature" of the default project image and could have been in your code as well I suppose.

Greg McKaskle

Yea, the lights on the relay module was what I was referring to. Do they signify anything (e.g. Digital Relay Module active and working? Data transmission?, etc.)?

[AustinSchuh]

If you have a serial port on your computer and null modem cable, you can view the boot messages to help figure out what's going wrong. The serial port also provides a console if you want. I remember finding instructions from FIRST about how to set up the serial port a year ago when I started playing with the internals of the cRIO. I want to say it's the standard 9600 baud and you need to set one of the DIP switches on the cRIO to enable it.

[Greg McKaskle]

Originally Posted by 1951-44U

Yea, the lights on the relay module was what I was referring to. Do they signify anything (e.g. Digital Relay Module active and working? Data transmission?, etc.)?

They signify that the default code is rapidly switching the relays. Cute with nothing attached, a bit scary if pneumatics or any other outputs are attached to the module.

Greg McKaskle

[1951-44U]

Originally Posted by Greg McKaskle

They signify that the default code is rapidly switching the relays. Cute with nothing attached, a bit scary if pneumatics or any other outputs are attached to the module.

Greg McKaskle

So they signify activity in the digital outputs?

Originally Posted by Greg McKaskle

A cRIO that is running the OS can be pinged and it will respond. If it is not also running a robot code will also respond to the FRC protocol and will show as having robot code.

The cascading lights last year were not on the digital breakouts, but on the relay module, and that was a "feature" of the default project image and could have been in your code as well I suppose.

Greg McKaskle

So what would cause a cRIO to be pinged yet not communicate with the DS specifically? (I say the DS specifically because I can re-image from the laptop and can ping it via WiFi as well -- thus the problem is limited to the "DS <---> cRIO" connection)

[Greg McKaskle]

Make sure to check the team ID on the DS as well as the IP on the laptop.

Greg McKaskle