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.