100% CPU Utilization Using 10ms Periodic Task

[Phalanx]

Here's what I'm doing. In the 10ms loop in Periodic Tasks I have the following:

2 separate GET digital I/O VI's
Each output I perform a Boolean NOT
Each output is stored in a Boolean global variable.
The RefnumGet VI's are outside the loop.

When this code is added, my CRIO cpu spikes to 100%.
When I remove this code my CRIO CPU is at 50%.

I'm rather puzzled/stumped that this little bit of code causes that much pain.
Any ideas?

[Alan Anderson]

Check the diagnostics window on the Driver Station for any error messages. If you have a broken RefNum or something similar, the error processing has a significant effect on the CPU.

[gpetilli]

We observed similar symptoms. We tried a 10ms PID timed loop which read some I2C sensors and wrote to the PWM outputs and we measured periods of 11ms to 16ms. We have changed our scheduler to do 15ms since this appears to be the limit of either the cRIO or the scheduler. Do you really need 10ms?

[Phalanx]

Alan,

I don't get any error messages other than RobotDrive isn't running fast enough when that code is enabled. Without that code enabled, I receive no error messages at all. Hence, my puzzlement.

Originally Posted by gpetilli

We observed similar symptoms. We tried a PID timed loop which read some I2C sensors and wrote to the PWM outputs and we measured periods of 11ms to 16ms. We have changed our scheduler to do 15ms since this appears to be the limit of either the cRIO or the scheduler. Do you really need 10ms?

I don't NEED 10ms. I prefer something faster than Teleop for what I have in mind.
In a worst case scenario I work something else out.

[gpetilli]

Originally Posted by Phalanx

Alan,

I don't get any error messages other than RobotDrive isn't running fast enough when that code is enabled. Without that code enabled, I receive no error messages at all. Hence, my puzzlement.




I don't NEED 10ms. I prefer something faster than Teleop for what I have in mind.
In a worst case scenario I work something else out.

We were less concerned with 10ms than the consistency of the period, although faster is certainly easier to stabilize. The teleop period is nominally 20ms but it is determined by the drivers station across WiFi and has considerable variability.
What else are you considering for your worst case scenario? Keep in mind that all actuator controls must come directly from the cRIO - safety feature so that the field can shut it down.

[Phalanx]

We've got a winch and pulley that pulls down our spring loaded launcher, and there's a limit switch to let us know when it's fully tensioned so we can turn off the motor and lock it in place.

The winch is really fast, it takes less than 1 second to reload. So I wanted something really fast to make sure we turn off the motor quickly to avoid breaking anything.

In a worst case scenario, I can slow it down and monitor it all in Teleop. I just didn't want to do that. The global variables are later sent in Teleop to the dashboard via network tables as indicators of it's readiness, although we may move that code to the 100ms loop.

[Mark McLeod]

I dropped what you described into a (almost) default project and didn't see the major jump in CPU utilization that you got.
Sounds like other code cross influences may be at work.

If you want a second set of eyes on your code we can do that.

[Joe Ross]

Originally Posted by gpetilli

We observed similar symptoms. We tried a 10ms PID timed loop which read some I2C sensors and wrote to the PWM outputs and we measured periods of 11ms to 16ms. We have changed our scheduler to do 15ms since this appears to be the limit of either the cRIO or the scheduler. Do you really need 10ms?

I would expect that I2C could be less efficient then DIO. You were also doing your test in java and with lots of additional calculations, right?

[Alan Anderson]

Originally Posted by Phalanx

I don't get any error messages other than RobotDrive isn't running fast enough when that code is enabled. Without that code enabled, I receive no error messages at all. Hence, my puzzlement.

What you're doing shouldn't give you what you're getting. Something else is going on here. To start with, can you show us the loop that pegs the CPU?

[gpetilli]

Originally Posted by Phalanx

We've got a winch and pulley that pulls down our spring loaded launcher, and there's a limit switch to let us know when it's fully tensioned so we can turn off the motor and lock it in place.

The winch is really fast, it takes less than 1 second to reload. So I wanted something really fast to make sure we turn off the motor quickly to avoid breaking anything.

In a worst case scenario, I can slow it down and monitor it all in Teleop. I just didn't want to do that. The global variables are later sent in Teleop to the dashboard via network tables as indicators of it's readiness, although we may move that code to the 100ms loop.

For a similar function on our bot, I am strongly recommending using a Jaguar and hooking the limit switch directly to the limit switch inputs on the Jaguar. This has the added advantage that if the winch moves during a collision, the Jaguar will retention. I also feel safer if high force mechanisms are directly controlled by hardware. If software also needs to see the limit switch, you could poll it via CAN bus.

[Alan Anderson]

Originally Posted by Phalanx

We've got a winch and pulley that pulls down our spring loaded launcher, and there's a limit switch to let us know when it's fully tensioned so we can turn off the motor and lock it in place.

It is possible to set up the switch to trigger an interrupt. However, I wouldn't try that until every other option is exhausted. Normally one wouldn't want to do actual motor control in an interrupt service routine.

[gpetilli]

Originally Posted by Joe Ross

I would expect that I2C could be less efficient then DIO. You were also doing your test in java and with lots of additional calculations, right?

Understood that DIO is much faster and yes we are using Java. Rough calculations show ~1ms to read the sensors, so that is significant, but should not be a show stopper.
Lots of calculations is a relative term, we are doing the heavy lifting (atan) in the teleop routine and as little as possible in the PID routine. If I were coding it, it could be even faster, but we try to stay within the capabilities of the students. 15ms should be fine for a drive train PID (WPI uses 50ms). Most of our sensors have programmable on chip filtering which we set to <50Hz bandwidth to minimize aliasing.

[chris.boyle]

Originally Posted by Alan Anderson

Check the diagnostics window on the Driver Station for any error messages. If you have a broken RefNum or something similar, the error processing has a significant effect on the CPU.

Replace the tunnels into the loop with Shift Registers. This will help if there are any errors found during any loop. Without them, the code has to find the errors every loop.

[Phalanx]

Originally Posted by Mark McLeod

I dropped what you described into a (almost) default project and didn't see the major jump in CPU utilization that you got.
Sounds like other code cross influences may be at work.

I'm beginning to think that as well. Finding it will be the challenge.

Originally Posted by Alan Anderson

It is possible to set up the switch to trigger an interrupt. However, I wouldn't try that until every other option is exhausted. Normally one wouldn't want to do actual motor control in an interrupt service routine.

Exactly. I definitely don't want to be doing much in an ISR. ISR's need short and sweet. Learned that lesson a long long time ago.

Originally Posted by Alan Anderson

What you're doing shouldn't give you what you're getting. Something else is going on here. To start with, can you show us the loop that pegs the CPU?

I agree, which is why I'm so puzzled by this. I'll post loop later when I have access to it. It's really simple and straight forward, but another pair of eyes never hurts. It's got to be something else, something I'm not seeing, something I'm missing.

Originally Posted by chris.boyle

Replace the tunnels into the loop with Shift Registers. This will help if there are any errors found during any loop. Without them, the code has to find the errors every loop.

Interesting idea, not something I want to resort to. I'd much rather isolate, identify and fix it.

Thanks everyone for your input and advice. Time to delve deeper, cross "T's" dot "I's" and make sure there isn't something stupid, which there probably is.

[Phalanx]

I found the problem. One of the GetRefNum's had an incorrect name. The name in Begin.VI was "Ball Collector Limit Switch" and in PeriodicTasks.VI it was "Ball Limit Switch". I corrected that issue and now CPU is back to normal levels.

So as I'm fond of saying.... "Programmers don't need to spell correctly, just consistently!!!"

Thanks for your insights, help and input.