Advanced LabVIEW programming?

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

[Jimmy Nichols]

I'm not able to answer your questions directly, but I'm hoping others will chime in and see this post.

I have been meaning to post this info, but with work, team activities, and family I haven't had the chance. I took LabVIEW Core 1 and Core 2 courses for work a couple months ago. I'm working on a project for work in which I will be data collecting several instruments, controlling the traversing action of a camera and reading the camera image into and inspecting the image, all in LabVIEW. When I was setting up the courses with my local Sales rep, who knows all about FIRST, he mentioned something quite intersting. He said that if a LabVIEW course is in its last week before the class starts and is not full, then High School students and he thought college students could take the classes for free. He didn't confirm this for me and I haven't followed up with him, but if this is true that could greatly help all teams, if they have courses offered in thier area. You can check the NI training site at: http://www.ni.com/training/

I hope some teams can check into this and are able to utilize this.

[SuperS_5]

Hi,
I agree with most of your "discoveries." They are all good programming techniques. There is a lot of detail about advanced architectures over on the NI forums and LAVAG.org.

Originally Posted by JohnGilb

Limited updates to Motors/Actuators
Using the feedback nodes (or a local variable, just something that stores information)

One thing I have a problem with is using local variables for almost anything except updating the FP via a specific state call. (IE. only one local variable per control.) I use functional globals for this. These are typically implemented via feedback nodes/uninitialized shift registers. There should be a tip video up for that.

I now use classes fairly extensively. Every logical unit of the code would end up being it's own class. I then lock down things like my functional globals so that other code cannot use it without permission. I have found that this works very well in both single and multi developer teams. The LV implementation of classes forces the programmers to follow better programming techniques.

[JohnGilb]

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?

[JohnGilb]

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

If any team or enterprising individual has been experimenting with that, I would love to see some sample code.

[Greg McKaskle]

The presentation in St Louis was titled "Making the Most of LabVIEW for FRC: Performance, Debugging, Architecture". I was able to find the abstract online, but not the slides. Perhaps I don't know where to look. I might be able to find a version of the slides, but Doug Norman could give the official ones to you. They were also presented in August by Aaron Pena at the Austin off-season event, so maybe someone who attended has a copy.

The presentation first describes a bit of how to determine what your performance needs to be, then shows how to use the Elapsed Time subVI, the System Monitor, and/or the Performance Profiler to measure what your actual performance is and what components are responsible for the load on the CPU. Further in the slides, it covers a few architectural approaches for moving code from teleop and running it when it needs to run, rather than for every packet.

Basically, this revolves around using the Periodic Tasks more and the Teleop less. If you have a subsystem that needs to run every 200ms in order to check sensors and setpoints and update an outptut, you can put that code into periodic tasks and expose the setpoint using either global variables. If the subsystem needs to run when a setpoint is changed, then consider using an RT-FIFO -- a powerful realtime queue that allows you to choose when the loop should run, and allows the rest of your program to enqueue new setpoints or actions.

Other techniques for structuring your code is to look at using object classes. Object classes in LV are a powerful mechanism for code extensions and organizing things in larger teams. It allows for exposing some fields and hiding others so that subsystem complexity is more manageable. The most interesting thing about LV objects is that they are by value. Most languages use new foo() to return a pointer to a foo. Each piece of code that is handed the foo pointer interacts with the same foo. This makes some things easy, but parallelism quickly introduces errors. In LV, the constructor returns a foo on the wire. When the wire is branched or stored in a global, each is its own copy. This means that unless they contain a refnum, they are independent and can be operated on in parallel without introducing the same sorts of bugs. LV does the same thing for arrays and strings. Anyway, for most FIRST teams, I don't know that the code grows large enough to need to use object class mechanisms in order to manage complexity, but it is a useful technique nonetheless, and if a team wants to investigate it just to learn, I am certainly willing to assist.

Greg McKaskle

[Jon236]

Greg,

Weren't all the presentations at Championships supposed to be posted? Either by FIRST or WPI, I believe.

Summer's over! Let's get the presentations up for everyone!

[Mark McLeod]

Jenny asked FIRST HQ that question recently:
http://www.chiefdelphi.com/forums/sh...49#post1074949

[plnyyanks]

Originally Posted by Greg McKaskle

If the subsystem needs to run when a setpoint is changed, then consider using an RT-FIFO -- a powerful realtime queue that allows you to choose when the loop should run, and allows the rest of your program to enqueue new setpoints or actions.

Greg, I have a question. How does a RT-FIFO differ from a regular Queue (found in the Synchronization palate)? It seems to me (after doing some reading about the RT-FIFO here), that the two are essentially the same thing. The only apparent difference is that an RT-FIFO would be specifically for Real-Time applications, while the other queue is for others. Can you please explain the difference between the two and when to use one over the other?
Thanks,
Phil

[Joe Ross]

Originally Posted by Greg McKaskle

Other techniques for structuring your code is to look at using object classes. Object classes in LV are a powerful mechanism for code extensions and organizing things in larger teams. It allows for exposing some fields and hiding others so that subsystem complexity is more manageable. The most interesting thing about LV objects is that they are by value. Most languages use new foo() to return a pointer to a foo. Each piece of code that is handed the foo pointer interacts with the same foo. This makes some things easy, but parallelism quickly introduces errors. In LV, the constructor returns a foo on the wire. When the wire is branched or stored in a global, each is its own copy. This means that unless they contain a refnum, they are independent and can be operated on in parallel without introducing the same sorts of bugs. LV does the same thing for arrays and strings. Anyway, for most FIRST teams, I don't know that the code grows large enough to need to use object class mechanisms in order to manage complexity, but it is a useful technique nonetheless, and if a team wants to investigate it just to learn, I am certainly willing to assist.

I was under the impression that Labview object oriented programming wasn't supported in our version of LabVIEW RT (although later versions do support it). Was I wrong? Some of the stuff we do would be a lot simpler to implement as a class.

[JohnGilb]

This year's LabVIEW does in fact support it - I tried playing around with it a bit, though it's very different from using classes in other languages. (As Greg points out, data is passed by value instead of by reference).

[Greg McKaskle]

The initial year was based on LV8.5, and they were not quite happy with objects under RT, so it was disabled. Support was on for LV8.6RT.

As for differences between the FIFO and the queue, there are more similarities than differences, but the RT one has an implementation that doesn't use locks and generally has less overhead. The general queue has a few additional features. Since I don't expect you to be passing much data or to be updating often, I suspect they are interchangeable for you. If I were you, I'd devise a quick test to verify that.

Greg McKaskle

[plnyyanks]

Thanks Greg, I'll be sure to write a quick VI to do some tests when I get the chance.

[Joe Ross]

Here's what made me think objects wouldn't work in 8.6 RT: http://zone.ni.com/reference/en-XX/h...portedvxworks/

[Greg McKaskle]

I found corroborating evidence that OOP wasn't enabled on RT until the 2009 edition. Oops.

http://zone.ni.com/devzone/cda/tut/p/id/3573

Greg McKaskle