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)

[Tom Line]

Originally Posted by Sconrad

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)

If you think this compile and build time is bad, go back to 2009 (the introductory year of the cRio and Labview for FRC).

You can minimize compile and build time by:
1. Using text files that read in constants that you use. You can FTP the text file, modify it, FTP it back, then have your code re-read it. This requires a little knowledge of the File I/O pallet and FTP, but it's a huge boon when you are tweaking things like autonomous.

2. Run the program from your laptop / computer rather than building it and deploying it. Use controls instead of constants. Once you've reached the right values, right click on the control and change it to default to your new value.

In fact, in 2010, the very first time we deployed code was the week of bag. Up until then we were always running from the computer while we updated it.

Labview handles loops just fine. The problem with using loops in Teleop and elesewhere is that the robot framework is already a giant loop that runs over and over again. The timing is tied into the driver station packet timing, and watchdogs monitor that your code is inputting and outputting often enough. If you have a loop in teleop and that loop takes some time to complete (we're talking more than around 1/20 seconds) you'll trigger the watchdogs. They assume something has gone wrong, and begin disabling functions on the robot for safety reasons.

Because Teleop is already one big loop, there's never really a reason to RUN a loop there. If you need something to loop more quickly, then use the period tasks (the area where the vision VI is put) in robot main.

[SuperS_5]

Hi,
I ended up getting really busy after posting on this thread, and then totally forgot about it. The recent bump brought it back into my attention.

Also, I've been trying to apply classes to FRC robotics programming, but I never got particularly far. What exactly would you encapsulate?

At the the of my first reply, I didn't realize that OOP was not supported for the cRIO. This years update will fix that though.
One of the principles of OOP in LabVIEW is to make nearly everything a subVI. If you need data out of the OOP wire, you use a specialized subVI. (Accessor) All methods can be made into subVIs. I especially force this when working with specialized code like database calls, or any kind of math algorithm. These can change often, so if they are subVIs, it makes it to modify later.

Different "Objects" would each be a separate class. For example, the vision system would have it's own class. Acquiring test images, might come from a web camera on your laptop. The testing web camera, and the robot camera would each be a child class of the vision class. (This is starting to get into dynamic dispatching, which should be in a different thread.)
In particular the various physical devices that you are controlling would each be a different class. For Example:

• Drive Train
• Compressor
• Arm System
• Grabber System
  -- The solenoids and sensors would each be a separate class. (But not children of the above 2 systems.)

Can you explain why you'd use functional globals instead of the actual Global that we use in the FRC framework? Is there a performance/readability/usability benefit?

I use functional globals a default over LabVIEW globals. The LabVIEW global is great for beginners, but, it can be limiting. (Just like using a boolean instead of a TypeDef'd Enum as an action.) The functional global allows for init code, calculations, and other interesting code to be done directly on the data before/after the stack. This allows for modification of the data globally for specific actions. This makes it a precursor to OOP. I generally make the functional global as part of the class that owns that data.

However, compile/build time has been an issue

The newer versions of LabVIEW have improved on this a bit. LabVIEW 2011 has made significant improvements in the area. For FPGA coding, I have seen single wire edits take up to a minute or more in LabVIEW 2009 and below.
Unfortunately the only solution for this year is to get faster computers. I didn't actually see much a problem in this area for FRC on my laptop, even though I was using a virtual machine to code in. (I have an i5 at 2.4GHz and at the time 4GB of RAM)

• System memory is the single biggest factor in LabVIEW performance up to 3GB of RAM. After that, other system resources become bottle necks for code development.

Some things that helped us were to avoid organizing code in subvis and avoiding while loops in teleop and autonomous

I would highly recommend not avoiding subVIs. This is a very basic coding practice in LabVIEW. If you are having troubles with the compile time, maybe we can help you out in another thread. The alternative to the file reading is using FP controls, either directly on the subVI or the Driver Station control panel. (The former being easier, but requires running from the development system.)

Nested Loops, except in very distinct cases, are usually very bad practice. Unfortunately it is way too easy to do. Generally junior programmers will do this when they don't know about the framework that they are working within. This applies to FRC and the professional world.

[Tom Line]

On a happy note, we are using Labview 11 for the beta test and are very pleased with the run, build, and deploy times. The first time you build and run as startup is the same speed as the old software, but after that it seems to go VERY fast (perhaps not bothering to build and deploy unchanged files). It's a nice change.