Re: 100% CPU Utilization Using 10ms Periodic Task
 

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?

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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!!!!

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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

Greg McKaskle

Re: 100% CPU Utilization Using 10ms Periodic Task
 

We're going one better than that this year. The names only appear in one place in the code.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

Global variables? Please share how you're doing it.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

We have the same philosophy about keeping the names in only one place.

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. :)

Timing is not an issue, as they are only called once at start up and the refnum values are stored in the shift registers for the duration. In addition, we only allow access to a particular device in one loop. It is not allowed to have multiple loops trying to access the same refnum.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

We have our code separated into drivebase and "other" sections. The Drivebase vi is a Case statement with cases for Begin, Teleop, Finish, and 10ms Periodic. The refnum name constants are outside the case and tunneled in.

We call the Drivebase vi from inside Begin, passing it the "Begin" selector. We also call it from within Teleop, Finish, and a 10ms loop in Periodic Tasks, passing the appropriate selector each time.

The "other" vi (name withheld to protect the mechanism) is similar, but also includes 5ms and 100ms cases.

I started out trying to use shift registers in a single-execution while loop to hold the refnum values, but Test mode requires everything to be in the RefNum Registry. Since I had to use Refnum Set anyway, I went with Refnum Get wherever resources are used. I might do some timing tests to see how the timing is affected by using shift registers instead.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

You can simplify this by using "Format Into String" on the enum.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

That's how we did it last year. It was a lot of upfront work to create all the typedefs, but it made the programming completely safe from simple typing errors. We wrote wrappers around all the RefNum Get functions so they could accept either strings or enums.

We also had bunch of special global cluster arrays defining everything necessary to open relays, digital inputs, counters, encoders, drivebase motor sets, individual motors, solenoids, analog inputs, etc. Begin and Finish ran through the arrays opening (and closing) everything, so once we had the basic code framework written we never needed to touch those VIs again.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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.

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.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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

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.

Re: 100% CPU Utilization Using 10ms Periodic Task
 

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