cRIO Silent Crash Immediately on Enable

[zsnow]

When we debug code on our robot, everything loads fine all the way up to DisabledInit. However, right was we hit enable on the Driver Station, the Driver Station says there is no robot code. In the WTX Console for WindRiver, we get a portion of our output lines before it randomly stops with no error. This crash all seems to happen instantaneously. The amount of output we get (from our TeleopInit function) varies each time we attempt to debug the code. After we hit enable, the robot RSL blinks in a long-on, short-off sequence for some time, during which the Victors' and Jaguars' indicator lights show their being in the neutral state. Later, the RSL does the long-on, long-off pattern, and the Jags and Victors start blinking as well. All through this the Driver Station shows the robot's status as being "No Robot Code".

[Alan Anderson]

When you see the No Robot Code message, does a red light appear on the Robot Communication indicator too?

Are you connecting to the robot using a wireless connection?

Do you have an air compressor on the robot?

What does the Driver Station show for battery voltage when you lose communication?

What is the D-Link's power input connected to?

[connor.worley]

Can you copy any output from NetConsole?

Can you post code?

[zsnow]

I'd like to prefix this by noting that I am currently not next to the robot, and I am operating on memory for the moment. I'd also like to thank the both of you for your assistance.

When I saw the "No Robot Code" message, I do not recall the Robot Communication light in the Driver Station going red.

We have tried both wired and wireless connections, both producing the same results.

There isn't an air compressor on the robot, nor any other power-intensive component, unless the Victors, Jaguars, and cRIOs could be considered as such.

I'm not sure as to what the battery voltage showed. Looking at the Driver Station Log Viewer, I see the voltage consistently at 12 V. On top of that, we tried replacing the battery with one we knew was fully charged, but it made no difference.

I am unsure as to what the D-Link's power source is. However, I have a gut feeling that this is not the cause for the behavior.

At this time, I have no output from NetConsole, but will work on that next time I attempt to run the code.

This line of code is what I think might be contributing to the behavior:

if (m_controller == NULL)
	m_controller = new SendablePIDController(P, I, D, this, this);

This is a line from a class which controls a motor. This line is run on DisabledInit(), however, m_controller->Enable(); is not called until TeleopInit(). The object which contains and initializes the PIDController follows the interfaces for PIDSource and PIDOutput. Thus, I could say that instance of that class contains a PIDController, which contains two references to instances of that class, each of which contains a PIDController... so on and so forth. I know that this is bad practice, but i think that when this situation is combined with the fact that the PID control loop runs on a separate thread, you get a recipe for disaster.

I may be able to ask my mentors to run some tests or try out code changes you may suggest in order to diagnose the issue.

[ebarker]

Do you have any uninitialized pointers ? Pointers used but not setup correctly in the constructor ?

[zsnow]

It seems that the post review is taking a long time. I'll have a mentor post for me if this continues.

Edit: Ed, I think the last section of my previous post might be relevant (it wasn't visible at the time of your posting due to my being a new user).