LabView: Graphical Programming

Oct. 22, 2006
LabView is a great tool for developing embedded applications, but it has been a relatively well-kept secret. Embedded Technology Editor Bill Wong takes a look at a package that combine Analog Device's Blackfin DSP development tools with National Instrumen

I looked at LabView more than a decade ago, and was very impressed, but I put it aside as test and measurement (T&M) was not at the top of my list of things to do. In the meantime, LabView has become a more impressive platform that has moved from its T&M roots into a programming environment suitable for a wider range of applications, including FPGA and embedded programming.

LabView is a bit like Java in that LabView is an environment or framework, not just a programming language. In fact, its graphical G programming language is just part of the puzzle. LabView also supports text-based programming languages like C and Mathscript. On the T&M and development side, LabView is also part of a larger enviroment that includes National Instruments' hardware products as well as those from a wide range of third parties.

LabView is an extremely large and robust environment. A fuller coverage of LabView requires a substantial book like LabView for Everyone, 3rd Edition (ED Online ID 13842) by Jeffrey Travis and Jim Kring. This article is a quicker overview for those unfamiliar with LabView.

What is LabView

LabView 8.20 is the latest incarnation from National Instruments. It marks the 20th anniversary of LabView that started on the original Apple Macintosh. Windows is now the most popular LabView host platform but not the only one.

LabView is essentially three things: a programming system, a development environment and a target environment. It can be used for purely computational chores, but it really shines when it interfaces with the real world: user and machine.

Its development environment matches the user interface that applications can present (see Fig. 1). LabView's control panel is one of two views of a LabView Virtual Instrument (VI). A VI is essentially a graphical subroutine. Its graphical programming component is called the G language. The G language complement of Figure 1 is shown in a flow diagram consisting of components and the wires that connect components together (see Fig. 2)). The color and line style in the diagram provide an indication of the type of data being sent between objects.

A VI operates much like a subroutine in C/C++ or Java. All have inputs and outputs that can be a range of types from boolean and integers to arrays and structures. A VI starts when all its inputs are available and generates its output values when the VI is done executing. Values logically flow through connecting wires to other VIs.

The process is actually a little more complex because LabView's dataflow architecture differs from sequential programming languages. For example, VIs are more like tasks that can run in parallel. This is true for graphical VIs that are shown on the control panel as well as non-display constructs; but more on the programming aspects later.

Another important aspect of a VI is its configuration screen or dialog box (see Fig. 3)). The ability to configure a VI varies depending upon the properties of a particular VI, so the sample dialog box only indicates what can be made available to a developer, not what each VI has.

The ability to easily configure a VI using this kind of interface is key to LabView's success with non-programmers, or at least those not using conventional programming languages. It allows complex VIs to be used, often with the initial defaults, in a simple LabView program that does some impressive work. Usually all the VI options can be wired for programmatic manipulation but more often only a few VI input and outputs are manipulated directly.

LabView's interface consists of a number of windows such as VI palettes and right mouse button menus (see Fig. 4)). This interface can be arcane to novice or non-LabView users but the environment's operation tends to become second nature to regular LabView users. This includes the use of control constructs (see Fig. 5)) such as while and for loops.

Parallel Programming

Although LabView has many of the same control constructs (see Fig. 6)) as sequential programming languages, even these are at odds with a sequential paradigm because LabView applications are inherently parallel, as in a simple producer/consumer example (see Fig. 7)). The producer and consumer loops can operate in parallel but to the programmer's eye the LabView program looks like any other.

Internally, a VI executes from a queue of VIs with all their inputs satisfied. This means any number of VIs can be operating in parallel. There are explicit constructs for handling events and VIs like buttons employ this type of action inherently.

The parallel nature of LabView has benefited the T&M space that naturally has data being created and consumed simultaneously from any number of devices. It is a generally useful programming technique that maps well to new target environments for LabView, such as FPGAs. The dataflow aspect of LabView also maps well to FPGAs where VIs often translate into logic, and wires into real connections.

Parallel programming often has to deal with time, so it is not surprising that LabView addresses this in a number of ways from time-oriented loops to time related and configurable VIs. LabView 8.20 adds some new features for real time support as well as brand new support for object oriented programming.

Graphical Object Oriented Programming (GOOP)

VIs are comparable to subroutines but they are also similar to objects because they have state. The big difference in the latter case is that a VI alone has only one callable method. Bringing object oriented programming (OOP) to LabView took a little thought by its designers. The result is both elegant and a little cumbersome (LabVIEW Embraces Graphical Object-Oriented Programming, ED Online ID 13478).

A LabView class is actually a collection of VIs and controls. A control essentially maps to a variable in other programming languages. The VIs have access to the controls providing the commonality of a class as well as an identifiable object. Any of the defined VIs can be applied to a matching object, and objects can be created as necessary.

The first thing to understand about LabView's GOOP is that objects do not show up as VI-style icons but are rather values that flow across a wire. The method VIs are what will be wired up in a program. The one common item among a class' VIs will be an input and output for the object.

This approach actually makes LabView's VIs (methods) similar to CLOS (Common Lisp Object System) generic functions. In CLOS' case, the function called is the one that most closely matches the types of each input parameter, including objects. LabView's approach is not as generic as CLOS but it does share much of its flexibility.

Still, LabView's GOOP is rooted in a conventional class hierarchy. VIs are inherited in subclasses and they can redefine superclass VIs.

The one thing I did find cumbersome was LabView's one-to-one mapping of VIs to files. This is repeated with GOOP classes that are actually just directories containing the VIs, class info, and controls. It makes sense from an implementation standpoint. It is not bad once you get used to it though. It does have the advantage that new classes can be created by copying an existing set of files rather than cut-and-pasting text class definitions in a conventional integrated devlopment environment (IDE) for languages like C++ and Java.

The Embedded Connection

LabView can create standalone programs that run on PC. Of course, they can also be run from within the LabView environment, and this is one reason why LabView development can be so productive. The interactive nature is great for development and learning purposes.

Still, one of LabView's recent benefits is the ability to target non-PC platforms. This is something relatively recent for a 20-year old environment. It is also one of the more interesting aspects, since LabView can be used with a range of targets — even within a single application. As mentioned earlier, LabView can generate code for FPGAs. It can also generate conventional source code such as C that can run on most microcontrollers.

Two significant uses of this feature include National Instruments' own Compact RIO (Reconfigurable Backplane Eases Process-Control Design, ED Online ID 8942) and Analog Devices' Blackfin (EiED Online>> A Tale of Two Blackfins, ED Online ID 14021). Compact RIO has an FPGA for a backplane. LabView is used to program the Compact RIO's processor, FPGA and interfaces to the modules that plug into a CompactRIO system.

The Blackfin DSP support is more as a standalone programming target. LabView can generate code for the DSP that is downloaded to most of Analog Device's Blackfin development boards. VIs are available for a range of filters that are optimized for the Blackfin and interfaces that exist on the chip or the development boards. The entire package is integrated with Analog Device's VisualDSP++ IDE. Developers normally use this with assembler, C and C++ programming languages.

LabView developers can completely bypass VisualDSP++ and work solely in LabView. Given the way LabView supports a high level of productivity, the latter is often very desirable. As noted earlier, LabView can handle the entry of C code, and other scripting languages, in a LabView program so developers can choose the most appropriate method of algorithm entry. Likewise, LabView VIs can call or be called by C — or other languages' — code developed using other environments like VisualDSP++.

These two examples highlight LabView's capability but they are by no means the only way developers can target non-PC platforms.

LabView Musings

So far I have been waxing mostly on LabView's many advantages. Given the number, it is not surprising that LabView has such as large following. In closing I want to touch on some of the cons along with some of the pros I have not already mentioned.

LabView is a proprietary language and development environment. In many ways it matches another successful, although more conventional environment: Microsoft's Visual Studio. The big difference is that there are no compatible compiler alternatives to LabView's G language. The impact of this can be noted by how long it took to get GOOP into LabView.

There is a learning curve with LabView. It can sometimes be harder for programmers than non-programmers since the former will almost always need to unlearn techniques that are different in LabView. This is especially true when trying to take advantage of LabView's features. I find similar problems when programmers transition to other languages such as C++, Matlab, APL, Lisp, or PHP. Old habits are forced onto newly available features, so things like array manipulation are done using for loops.

Optimization is another issue, although National Instruments has done an amazing job when targeting native code. Still, understanding the environment and compiler can be more difficult since the user is far removed from the underlying system. This is similar to Java, but even there the quality of the system has essentially made the issue moot.

On-screen code density can be another issue. Graphical programs take up lots of space and the lack of zooming makes it imperative to implement a hierarchical structure of VIs. Double clicking a VI opens up that VI to reveal the child VIs and wiring used to construct the parent. Larger screens and multiple displays can help especially with the advent of lower cost displays and availability of multiple display video adapters. Text code can be denser on-screen, but a graphical representation is often easier to evaluate quickly.

The presence of source code manipulation tools is one advantage of the non-graphical programming solutions. Tools like grep and awk as well as refactoring support in environments like Eclipse allow developers to make massive contextual changes that cannot be done in a graphical environment simply because this type of search and replace tool has yet to be developed. Some UML tools now support graphical difference tools that are very handy when combined with source code management tools, but graphical tools in general tend to be lagging their text-based counterparts. Still, there has been little new in the text arena along these lines, either.

The final item is essentially related to the proprietary nature of LabView and its closed nature. LabView lacks many of the third party optimization and diagnostic tools found with other programming languages and development environments. Part of the reason this is not a major issue is that LabView's tools are quite advanced. Its debugging environment is one of the best. Another reason is that lower level environments such as C do not have these kinds of tools as part of the language, but rather the approach is designed for this type of add-on approach. One other item is that National Instruments is slowly opening its system to a limited number of academics.

Closing on a more positive note, I think that LabView has a significant number of things that other environments should start to incorporate. Its debugging environment is better than most alternatives. Its program execution animation lets you find bugs visually. This can be especially handy for finding race conditions or other parallel programming problems. The configuration dialog boxes and default settings for VIs and objects has already been mentioned, but this is related to the high productivity when using LabView. In this day and age where time-to-market is critical, it could be the one thing that makes LabView your platform of choice.

Related Links Analog Devices

National Instruments

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!