100% CPU usage and double timeout bug

[Greg McKaskle]

I reread the post with less bleary eyes and noticed that you said you received a watchdog error. The disable topic was about Safety Config, so I had them confused.

Watchdog is not on by default, and Safety is enabled only for the RobotDrive. Please determine which is on, try turning it off and verify that the symptoms change. If the jerking is being caused by WD or Safety, then it means you are missing deadlines. It may also mean you have a workaround.

Assuming you are missing deadlines, I'd verify you have no errors in the Diagnostics panel, as the current mechanism for catching errors and shuttling them to the window is quite heavy and can cause you to miss deadlines. If a missing jag is still being referenced, or a disable structure causes a wire to be bad and causes errors, ...

The disable issue is problematic to the original thread because most robots are in disable when they are being reimaged or reprogrammed. If disabled robots are throwing errors they take longer to respond and sometimes require a NoApp switch or similar. Making the disable code less CPU intensive due to errors seems like it will resolve many of these issues. I don't think disable has any impact in your robot's twitch.

Greg McKaskle

[Tom Line]

The closest thing I've seen to what you describe is when we deploy code from a given computer while tethered. Now, while the code is running, we disconnect the tether. If you reconnect your tether cable you will be unable to redeploy code until you reboot the crio or power your robot up then down.

I cannot say that I've ever seen a situation exactly like what you describe. Once the cRio timed out, it won't do anything for us until we reboot it.

Regarding the disabled mode and not deploying, we ran into the same problems with problematic deploys ALL the time last year (2011). What we found was that because we have every sensor, data accumulator, etc enabled in disabled (including vision) so that we could debug, it pushed the the CPU too high to do a successful deploy.

We now encase all of our disabled code into a single If/Then case connected to a Button on the front panel. The default position of that button is OFF, so when we deploy to the robot permanently none of the extraneous sensor stuff runs in disabled mode.

When we temporarily deploy from the programming computer, we turn the button on when we need the data to tune things, then turn it back off to deploy so there is no code running in disabled mode.

[Levansic]

Originally Posted by Tom Line

Regarding the disabled mode and not deploying, we ran into the same problems with problematic deploys ALL the time last year (2011). What we found was that because we have every sensor, data accumulator, etc enabled in disabled (including vision) so that we could debug, it pushed the the CPU too high to do a successful deploy.

We saw that as well. We pushed our vision processing onto our driver station, to keep CPU utilization down. Interesting solution for debugging and quiet mode. We'll probably implement something similar this year.

-- Len

[Levansic]

I'm a little late in posting about this, but here's a follow-up on our issue.

Our main programmer deleted all of the code related to the no-longer present CAN Jaguar. I verified that this code was covered by Disable blocks, but in some cases, still had wires coming or going.

All of the problems and all of the watchdog errors we were having went away!

Now, our diagnostic log on the DS is completely empty, except for a new message at references the watchdog. Again, we are not in any way calling any watchdog functions in our team code.

The new solitary error code is as follows:

Watchdog Expiration: System 1, User 0

Because the robot is now working great, I'm of the opinion that this error doesn't matter. At the same time, I am a little concerned because we shouldn't have any error for a function we aren't calling.

-- Len

[Joe Ross]

Originally Posted by Levansic

Now, our diagnostic log on the DS is completely empty, except for a new message at references the watchdog. Again, we are not in any way calling any watchdog functions in our team code.

The new solitary error code is as follows:

Watchdog Expiration: System 1, User 0

Because the robot is now working great, I'm of the opinion that this error doesn't matter. At the same time, I am a little concerned because we shouldn't have any error for a function we aren't calling.

The system watchdog is based on communications and can't be disabled. The user watchdog is what you can control programmatically. I believe it's normal (or at least not uncommon) to see a single System watchdog expiration when starting the program.

[Alan Anderson]

Originally Posted by Levansic

The new solitary error code is as follows:

Watchdog Expiration: System 1, User 0

That single system watchdog error is expected. It is an artifact of the timing when the robot transitions from disabled to enabled. Don't worry about it.

[Levansic]

Originally Posted by Greg McKaskle

Watchdog is not on by default, and Safety is enabled only for the RobotDrive. Please determine which is on, try turning it off and verify that the symptoms change. If the jerking is being caused by WD or Safety, then it means you are missing deadlines. It may also mean you have a workaround.

That's what has been puzzling us. We don't have anything referring to the watchdog and certainly didn't add any watchdog vi's, and we have safety config disabled on our drive. We didn't add safety config to any of our other motor controls. Our cRIO's are old, dating back to 2008. Even though we re-image them several times a year, is there a a possibility that old watchdog code is still lingering in a zombie state?

Originally Posted by Greg McKaskle

Assuming you are missing deadlines, I'd verify you have no errors in the Diagnostics panel, as the current mechanism for catching errors and shuttling them to the window is quite heavy and can cause you to miss deadlines. If a missing jag is still being referenced, or a disable structure causes a wire to be bad and causes errors, ...

We'll have to look closer this week. I don't remember what else was coming up as errors. The watchdog one stands out, as we didn't think we had any code that used that deprecated system.

-- Len