Advanced LabVIEW programming?

[Sconrad]

Originally Posted by JohnGilb

Hello all!

I've got a question for you. Our team has been working with LabVIEW since it was available to FRC teams, and I think we've finally arrived at the point where we know how to make things work.

However, this is a very different thing from knowing how to make them work well. So, I'd like to ask you all in this forum - what techniques, design patterns, or features of LabVIEW do you use in order to make a really great robot?

(I heard there was a talk at the Championship this year along these lines, but I can't find any documents on it).

Here's what we've "discovered" (and note that some of these are probably pretty basic):

TypeDefs
Our team now makes liberal use of strict TypeDefs as interfaces between VIs. It's so much easier to add a new state to an enum or expand functionality by changing a TypeDef, and watching the changes ripple through your program.

Limited updates to Motors/Actuators
Using the feedback nodes (or a local variable, just something that stores information) we now only call the various incarnations of SetSpeed.vi if the input value has changed. This actually freed up a surprising amount of machine resources.

Program while expecting to fail
Any time we add a new feature that can be tweaked, we always create a control instead of a constant. Inevitably, at runtime, we discover something wrong, and it's far easier to tune a control than redownload the entire program.

Use of State Machines
The LabVIEW case structure makes programming state machines very easy, and FRC robots often have to accomplish all sorts of sequential tasks. Using a local variable or feedback node to control the current state makes the structure quite compact and easy to read.

Use the Profiler
The profiler that comes with LabVIEW is pretty powerful - it can be hard to read at first, but when you're trying to squeeze just a little more functionality out of the cRIO, knowing where you're bottlenecked is a significant help.

As far as I know (my second year on the team), we haven't had much trouble with the code overloading the cRIO resources in any way. However, compile/build time has been an issue. Some things that helped us were to avoid organizing code in subvis and avoiding while loops in teleop and autonomous (nested loops apparently are very difficult for labview to manage)