Advanced LabVIEW programming?

[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

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