100% CPU Utilization Using 10ms Periodic Task

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

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

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

[Alan Anderson]

Congratulations on finding and fixing the problem.

In normal usage, an incorrect RefNum name should have given you an error message on the Driver Station. Did you do something with the error output on the RefNum Get function that would have caused the system to think you were checking and handling the error yourself?

[Phalanx]

Originally Posted by Alan Anderson

In normal usage, an incorrect RefNum name should have given you an error message on the Driver Station. Did you do something with the error output on the RefNum Get function that would have caused the system to think you were checking and handling the error yourself?

We didn't wire anything to the error out terminal. So we weren't masking it or handling it ourselves. I didn't see an error message at the time.

Originally Posted by Greg McKaskle

I'm also curious if it is clear why the error message wasn't making its way to the DS.

Greg, I can't answer that other than to say, that the error message was probably missed and the DS log wasn't closely scrutinized. My programming team told me last night, that they did see an error message the next day.

I've got to do a better job teaching this stuff. This is for a team that had zero programmers at the start of build season. I'm not that dissatisfied with where they've gotten given the short time.

[wt200999]

Originally Posted by chris.boyle

This is how we are avoiding refnum errors. Requires more work up front, but should never have an 'invalid' refnum problem. Just make sure you pick the correct one.

Do you inline this SubVI?

If my understanding of the LabVIEW compiler/optimizer is correct, if you were to inline that VI, every instance of that VI would be copied down into the code and the controls would all be optimized out. The case structure would also be optimized out leaving the 'normal' method for accessing resources. This would give you the less CPU usage overhead compared to format into string or a subVI call, while supporting the normal methodology used by the WPI Library.

[Greg McKaskle]

I was asking just to see if there was a bug or something that could be improved for the future.

One such thing is to make the errors be on the front page instead of the second page. Other things can be done so that the errors or number of errors are more obvious. The other issue is that the current error routing is too slow and often causes watchdog issues. I believe that is fixed for next year along with a deploy issue that it can sometimes cause.

As for the string dictionary that was demonstrated. That is a great way of preventing inconsistent spelling. I'm not sure if it is necessary or good for all teams, but if you have the skills to make the subVI and update the typedef enum, it is a great solution. The overhead of the subVI should be quite small. Making it a subroutine would shrink that by quite a bit. Making it be inlined will, as pointed out, should make it disappear entirely as the compiler substitutes the code, then propagates constants, then removes unreachable code.

Greg McKaskle

[chris.boyle]

We are not really concerned with the efficiency of the string dictionary as these are only called once at the entry of Begin, Periodic Tasks, Finish and Disabled if they are motors.

The references returned are stored in the Shift Register for the duration of the execution. With our rule of only a single Get Reference allowed, it has not been a problem with speed, just planning.

[plnyyanks]

Originally Posted by wt200999

If my understanding of the LabVIEW compiler/optimizer is correct, if you were to inline that VI, every instance of that VI would be copied down into the code and the controls would all be optimized out.

Close. Making a sub-VI inline makes LabVIEW think that the code in that VI is actually on the block diagram's parent (and avoids the overhead of making a subVI call). So having an inline subVI is exactly equivalent to not having the subVI there at all (and its code just in the block diagram of its parent).

A third way to minimize subVI overhead is to inline subVIs into their calling VIs. When you inline a subVI, LabVIEW inserts the compiled code of the subVI into the compiled code of the calling VI. If you then make changes to the subVI, LabVIEW recompiles all calling VIs of that subVI to include those changes. Essentially, inlining a subVI removes the need to call the subVI at run time. Instead, LabVIEW executes the subVI code inside the compiled code of the calling VI.

Inlining subVIs is most useful for small subVIs, subVIs within a loop, subVIs with unwired outputs, or subVIs you call only once. To inline a subVI, place a checkmark in the Inline subVI into calling VIs checkbox on the Execution page of the VI Properties dialog box. You must also place a checkmark in the Reentrant execution checkbox on the same page of the dialog box. LabVIEW automatically preallocates clones for each instance when it inlines the subVI.

Source, and for more light reading on the subject, a description of how the compiler works with some nifty diagrams on what inlining does if you scroll down a little.

[Greg McKaskle]

Once the code is inlined, the compiler will propagate constants, we call it constant-folding. The result of this is that the string is known at compile time and all other cases are eliminated for that instance because they are unreachable. The overhead when inlined, both in runtime size and execution is equivalent to wiring a constant.

Greg McKaskle

[Chris Hibner]

Originally Posted by 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.

I have a rule with our software students: if I catch you typing a refnum name in any VI other than Begin.vi, you get the mother superior whack on the knuckles with a ruler. Copy/Paste ONLY!!!!