Electronic Design

LabVIEW Embraces Graphical Object-Oriented Programming

Celebrating 20 years, LabVIEW 8.20 takes a new approach to OOP.

To mark the 20th anniversary of LabVIEW, along comes LabVIEW 8.20 replete with object-oriented support. If the original LabVIEW is C, LabVIEW 8.20 is C++. It's a superset based upon the original virtual-instrument (VI) methodology developed 20 years ago. LabVIEW is also one of the few graphical programming languages standing alongside UML (Universal Modeling Language) and Matlab's Simulink. Each language offers a distinctive approach and purpose, as well as its own terminology.

Espousing the dataflow approach, LabVIEW originally targeted the test and measurement community, though its current version also suits embedded programming. National Instruments uses its own set of terms to describe the programming environment and constructs (see "LabVIEW Terms," p. 40). Many LabVIEW programmers already perform object-oriented programming (OOP). The basic building block is the VI, which is comparable to a subroutine with multiple input and output parameters. A VI can contain multiple controls that map to variables in other programming languages.

The major difference is that LabVIEW uses its own defaults (such as making variables static), providing a basic form of encapsulation. A graph control, for instance, typically will appear in its front panel and remain there as long as the program is running. It's possible to make copies of a VI, which creates a limited building-block approach to OOP that doesn't have a parallel in most common programming languages.

The major drawback to this approach, compared to conventional OOP support, concerns the lack of inheritance and the ability to have multiple methods associated with an object. A VI is simply one method or subroutine. This is where LabVIEW 8.20's OOP support comes into play.

THE DETAILS OF LABVIEW OOP
LabVIEW's object-oriented support is built around the Project Explorer, which also is used to manage VI files in general (Fig. 1). A class container file simply brings together a set of common controls and method VIs.

This class container essentially matches a typical class definition with object variables and method function definitions. As with most LabVIEW constructs, they're presented only in a graphical form. For example, even the class hierarchy is presented this way (Fig. 2).

LabVIEW wires use pass by-value semantics. A node begins processing when all of the required input wires deliver a value. A node delivers its output values to the output wires once it completes its computation.

A wire that splits to connect to two destination nodes causes a copy of the data or object to be made for each node (Fig. 3). Most class VIs (methods) pass the incoming object to an output port so the same object can be used in a series of calculations (Fig. 4).

The pass by-value approach has some interesting implications when it comes to objects, as well as due to the fact that most other OOP languages use a pass by-reference model. Of all the differences associated with LabVIEW's OOP approach, this one will most likely cause confusion with new LabVIEW users.

LabVIEW's designers made a number of choices that simplify the implementation and the understanding of the OOP support. For example, only single inheritance is supported; Java-style interfaces are not. In addition, LabVIEW classes only support private data, not public or protected as in Java and C++.

Likewise, there's nothing akin to friend classes and class variables. Instead, the designers opted to force the use of get/put-style methods to expose internal data in the former and global variables or unitialized shift registers for the latter. Other OOP languages have taken a similar approach.

LabVIEW class VIs, also called dynamic VIs, correspond to virtual methods in other languages. A subclass can override a parent's dynamic VI. But LabVIEW doesn't permit overloading VI dispatch based on the type of inputs. This doesn't prevent the support of polymorphic objects, and similar support can be attained using data-type detection.

A useful overview of why the designers made these tradeoffs can be found at National Instrument's Web site. Search for Lab-VIEW Object-Oriented Programming: The Decisions Behind the Design in the NI Developer Zone.

Pricing for LabVIEW 8.20 starts at $1199.

National Instruments
www.ni.com

LabVIEW Terms

Front panel: user interface
Block diagram: VI editing interface
Nodes: program execution element, including terminals and VIs
Terminals: input or output node
Controls: LabVIEW input terminal such as a switch
Indicators: LabVIEW output terminal such as an LED
Wires: connection between the output of one node to the input of one or more nodes; acts as a value assignment
Virtual instruments (VI): program, functions, subroutines, or object methods
Sub VI: VI contained within another VI
Dynamic VI: VI contained within a class comparable to a virtual method function
G: underlying LabVIEW programming language

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish