Communication issues?

[Greg McKaskle]

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

Warning <Code> 44006 occurred at Driver Station
<time>10/9/2013 5:43:38 PM<unique#>1
FRC: Custom I/O is not enabled or is not connected to the driver station.

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.

ERROR <Code> -44009 occurred at Driver Station
<time>10/9/2013 5:43:38 PM<unique#>2
FRC: A joystick was disconnected while the robot was enabled.

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.

WARNING <Code> 44007 occurred at FRC_NetworkCommunications <secondsSinceReboot> 104.262
Warning <Code> 44001 occurred at No Change to Network Configuration: "Ethernet"<noNICConfig>

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".

WARNING <Code> 44008 occurred at FRC_NetworkCommunications <radioLostEvents> 102.504 <radioSeenEvents>
FRC: Robot radio detection times.

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

Warning <Code> 44002 occurred at Ping Results: link-GOOD, DS radio(.4)-bad, robot radio(.1)-bad, cRIO(.2)-GOOD, FMS-bad Driver Station
<time>10/9/2013 5:44:05 PM<unique#>4
FRC: Driver Station ping status has changed.

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

[ekapalka]

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?

[RyanCahoon]

Originally Posted by ekapalka

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.

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

Originally Posted by ekapalka

Soo... we can't print any information to the Driver Station or Netconsole.... 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?

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?

[ekapalka]

Originally Posted by RyanCahoon

Sounds right.
[...]
What happens if you manually delete the existing .out file and rebuild?

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!

[ekapalka]

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:

Any red modules are either missing or not installed in the correct slot

...so does that mean we burnt out or damaged the module? Thanks!

[Mark McLeod]

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

Slot 3 is for the pneumatics module.