[Greg McKaskle]

About the scale on the chart. The graph plots are plotted against the scale, so 0 is not the bottom of the black chart area. If you see your red plot go to the bottom of the black plot area, that would be negative, and I'm not sure if that is a good thing for your CPU.

The reason the scales are lifted off the bottom was to leave room for the instrumentation dots. There are four plots below the 0 on the scale, one for the robot mode that the field or DS gave to the robot, and one each for any calls by the code to declare what was run. At least for LV, the framework has VI calls in it to place a dot on the chart each time the teleop code is run, each time the disabled code is run, and each 20ms while the auto is running. This should help identify when robot code doesn't leave auto, or runs auto and tele or other odd combinations during the event, as well as noting when the code doesn't run anything for extended periods (typically caused by large delays inserted into teleop).

Anyway, thanks for verifying.

I looked into why the autonomous is by default higher than the others, and it is caused by RobotDrive not being updated. Not updating for 100ms causes the robot safety override to kick in. No big deal, but it uses the uncaught error mechanism to print the message to the DS. This adds the extra overhead. Next year, we'll hopefully be able to redo the uncaught error stuff to be cheaper, and/or explicitly send the safety message. A properly written auto should never go into safety, at least not until it has run to completion and stops sending motor commands.

Does anyone else seem to see excessive CPU usage in simple code? Is this one still causing anyone issues?

Greg McKaskle