LabVIEW

LabVIEW is a graphical programming language from National Instruments. Included in the LabVIEW distribution is an extensive development environment with many libraries and tools. The graphical language is named "G". Originally released for the Apple Macintosh in 1986, LabVIEW is used for data acquisition, instrument control, and industrial automation on a variety of platforms including Microsoft Windows, various flavors of UNIX, Linux, and Mac OS.

LabVIEW programs/subroutines are called virtual instruments (VIs). Each VI has two components, a block diagram and a front panel. Controls and indicators on the front panel allow an operator to input data into or extract data from a running virtual instrument.

"G" is a data-flow programming language. As opposed to traditional languages, program flow is not determined by sequential execution of instructions. Instead, execution commences when all input data becomes available to a node. Since this might be the case for multiple nodes simultaneously, "G" is inherently capable of parallel execution. Multi-processing and multi-threading hardware is automatically exploited by the built-in scheduler. It multiplexes multiple OS threads over the nodes ready for execution. As with any parallel-programming system, the downside is that the code is prone to race conditions. Also, the flow of execution is harder to reason about than is the case for traditional sequential execution languages such as C, Visual Basic, or Python.

The major advantage of data-flow is that it can be represented with a graphical metaphor: nodes are graphical icons, data flows along wires from one node to the next. To the extent that diagrams fit on a single screen, the 2D graphical representation makes better use of the bandwidth of the human visual system. The lack of a textual representation is a boon for dyslexics. The major disadvantage of the graphical metaphor is when the data-flow being described is no longer a direct route, as in the programming of events. The "wire" with your event data goes to a "transmitter", which is in turn outputted by all of the "receivers" that are registered for that event. These receivers could be anywhere within the project, with no sane method of finding them.

LabVIEW goes further by intimately tying the creation of user interfaces (called front panels) into the development cycle. User interfaces can do double duty as programmatic interfaces: a virtual instrument can be run as a program, with the front panel serving as user interface, but, when dropped as a node onto the block diagram, the front panel serves as the definition for the inputs and outputs of that node. This implies that VIs can be easily tested, as a little program, before being embedded as a subroutine into a larger program.

The graphical approach allows non-programmers to construct programs by simply dragging and dropping virtual representations of the lab equipment that they are already used to. The graphical programming together with the included examples and documentation makes whipping up a small application easy, also leading many non software developers to believe that programming of "G" is simple. However, for complex algorithms or large-scale code, the limited abstraction capabilities and static nature of the language ("G" is equivalent to C with memory management, but without pointers) quickly become a constraint. The direct tying of user interfaces to code encouraged by the development environment also causes scalability problems. Maintanance of these programs becomes a herculean effort on the part of even the person who originally programmed it, let alone a different developer.

The main benefit of LabVIEW over other development environments is the extensive support for accessing instrumentation hardware. Drivers and abstraction layers for many different types of instruments and buses are included or available. These present themselves as easy-to-use graphical nodes. The abstraction layers allow isolation between hardware implementation and software solution. Without the provided software driver interfaces, this would be extremely time consuming. The sales pitch of National Instruments is therefore that people with little or no coding experience can write programs and deploy test solutions in a reduced time frame when compared to more conventional or competing systems. The main competitor for instrument control and data acquisition is perhaps Agilent VEE. An alternative driver framework for Linux is the Comedi driver library. TCL with the TK add-on is also used for the same applications as Labview, on both Linux and Windows platforms.

In terms of performance, LabVIEW includes an actual compiler that produces native code for the CPU platform. The graphical code is compiled, rather than interpreted. Compilation occurs on-the-fly, as the graphical code of a VI is being edited. The generated code is somewhat slower than equivalent compiled C code. However this is considered a small price to pay for the increased productivity offered by the unique patented graphical code design system.

The latest version of LabVIEW is version 7.1.1.

External links

• Info-LabVIEW (http://www.info-labview.org/) - An internet mailing list for the discussion of LabVIEW.
• http://www.LabViewForum.com - The Europe Forum for LabVIEW Developer
• http://wiki.LabViewForum.de - Wiki @ LVF The Wiki meets LabVIEW...
• ILVG.it (http://www.ilvg.it/) - The Italian LabVIEW user Group.
• LAVA (http://lavausergroup.org/) - LabVIEW Advanced Virtual Architects (news and discussion forums).
• OpenG (http://openg.org/) - An open source LabVIEW community (downloads and discussion forums).bg:LabVIEW

de:LabVIEW fr:Labview nl:LabVIEW pl:LabVIEW pt:LabVIEW ja:LabVIEW