Communication issues?
 

That's at least what I assume it is. My team recently agreed to present our robot at sports event (football game?) to show our support for breast-cancer awareness, and we forgot to check that the robot works first (how can you turn that down?). We booted up the robot today to do some diagnostics with the solenoids not properly functioning, and we found a new issue. The first time we turned it on, it was okay. It could drive and actuate two of the three solenoids. I was told to redeploy the code (because the hardware is apparently flawless), and we began having trouble. I should mention that before we started it up, we switched the target server to the proper one for a 4 slot cRIO. When it booted up, the "Robot Code" and "Communications" lights were on, but the robot itself was unresponsive. We tried re-imaging the cRIO, restarting the DriverStation, restarting the computer, and rebooting the robot. Every time resulting in a similar message: Most of these we've seen (switching network types, disconnecting the joystick, etc), but we're not sure what to make of some of these things. Were thinking it might be the DriverStation itself, because of something we had done earlier that day. We tried to set up the gyro on another robot (with an 8 slot cRIO). It was miserable. It starts at some huge number and counts up at an increasingly fast rate. This dynamic message continues to display on the DriverStation regardless of which robot (if any) is currently connected (by the way, we never got the gyro to work). Does anyone have any ideas as to what the cause of the problem is? Thanks!

Re: Communication issues?
 

The fact that the communication and robot code lights were on makes me strongly suspect that communication between the cRIO and the driver station is not the issue.

Questions:

1. You said the problems started when you downloaded new code. Are you sure you put the correct, and functioning, code on the robot?
2. Does the Robot Signal Light show the correct slow blink when the robot is enabled for teleop? (on for approx. 2 seconds, off for approx. 0.5 seconds)
3. Do you get any messages in NetConsole?

Re: Communication issues?
 

I'm sure that the code functions. I stripped the entire code down to the bare minimum for drivingThe code I downloaded was C++, and so was the code prior to re-imaging the cRIOIn WindRiver, you have to select the target depending on weather you are using a cRIO or cRIO-II (I'm not 100% sure of the terminology... I'm working from memory)Is that a light on the cRIO? The only light whose blinking patterns I can remember are the ones on the Talons (orange, same time on as off; Pretty sure it should be solid orange when enabled). I appreciate the response :)

Re: Communication issues?
 

Thanks for clarifying. I only looked at your linked picture after I posted and that answered the question of which language. The answer about the target server came shortly thereafter. I've mostly programmed in LabVIEW and Java, so I didn't remember that.

The RSL is the orange dome light that connects to a separate port on the digital sidecar. If you don't have one connected, there's a small LED on the DSC next to the RSL port that mirrors the RSL, so you can use that instead.

It's helpful to know the state of the Talons as well. If they were solid orange when the robot was enabled, than that basically answers the same question.


New question: Is your program printing any error messages in NetConsole? Can you try printing the values that you're sending to the motors? (I believe in C++ you can just use printf or cout)

Re: Communication issues?
 

The messages you post are not all that unusual. I can help interpret some of it.

This means that calls to read and control the Cypress I/O board failed. This often isn't an issue, but if you expected it to work, the message helps verify that there was an issue.

This means what it says. While the robot was enabled, a joystick was disconnected or stopped working. If you didn't physically disconnect it, this message indicates that power management, static electricity, or cabling is causing you to lose the joysticks.

Messages like this are normal and tell us how long the cRIO had been up before it was connected to the DS and that the DS didn't need to change the network config for "Ethernet".

This one indicates that the radio was rebooted and some details that matter sometimes.

This message is produced anytime that a ping to a device changes.

The better way to look at this info is in the DS Log file viewer. It condenses these messages and filters them. It also places them on a time line along with CPU and voltage levels and helps identify many more issues.

As for what is wrong with the robot, it doesn't seem to be a communications issue. It seems to be enabled at one point, but the code and/or electrical isn't doing what it should. Since it sounds like you made significant changes to the code -- even simplifications count as changes -- I'd start there. Use the Charts tab to see how the code is running. Add print statements to see what code is running, etc.

To debug the gyro, you should probably break it down. If you were using LabVIEW, I'd suggest you run the example project for the gyro on your cRIO. If it works, use it as a template to compare against. If it also doesn't work, look at the wiring, the sensor, etc. I assume you have similar examples in C++.

Greg McKaskle

Re: Communication issues?
 

Soo... we can't print any information to the Driver Station or Netconsole.... The orange light, when enabled on either robot, stays on for about two seconds and then off for about half of one, and when disabled it's about an equally timed on/off sequence. Now neither robot is functioning. I'm beginning to think that WindRiver is just re-using the old *.out file (because the "gyro reading" [accumulator] continues to count up no matter which robot is attached)... any ideas?

Re: Communication issues?
 

Sounds right. I'm pretty sure this is a program issue, and not a comm issue.

Double-check your build log to see if there are any errors. Completely different IDE and everything, but I've seen Visual Studio get into weird states where it will report permission errors and won't overwrite its old build files.

What happens if you manually delete the existing .out file and rebuild?

Re: Communication issues?
 

Firstly, I'm glad that something is working properly :D You mean the *.out file in the IDE? The same thing happens when I delete it. I'm thinking I may need to FTP wipe the thing from the cRIO... I'm working on my FileZilla skills, but I haven't got a robot to test on at... 12:30am.... Thanks for the reply!

Re: Communication issues?
 

Here's an update. We finally properly deleted the *.out file from WindRiver, and I believe we may have caused new problems in our search to find the original issue. Now, there is no flashing light on the Digital Sidecar, no errors in the build, and no gyro reading (yes!). For some odd reason, when we re-image the cRIO (which we've done quite a few times in the last day or so), the module which connects to the Digital Sidecar is now red, where it was green before in the same location (slot 3). According to the control system information: ...so does that mean we burnt out or damaged the module? Thanks!

Re: Communication issues?
 

The normal location for the Digital module (where the Digital Sidecar attaches) is slot 2.

Slot 3 is for the pneumatics module.