LabVIEW

Overview

LabVIEW (Laboratory Virtual Instrument Engineering Workbench) is a graphical, data-flow programming environment developed by National Instruments (now part of Emerson). Instead of writing lines of textual code, LabVIEW developers wire together icons on a block diagram — data flows along the wires from sources to sinks, and a node executes as soon as all of its inputs are available. The result is a program that can be read as a schematic, which is one reason LabVIEW has become a fixture of engineering test, measurement, and instrument-control work for nearly four decades.

A LabVIEW program is called a VI (Virtual Instrument). Every VI has a front panel — a graphical user interface of knobs, dials, charts, and indicators that resembles the face of a physical instrument — and a block diagram that defines its behavior. VIs are composable: a VI can be dropped onto another VI’s block diagram as a subVI, which gives LabVIEW programs a hierarchical structure analogous to functions in a textual language.

History and Origins

LabVIEW was conceived in the early 1980s at National Instruments by co-founder Jeff Kodosky, with significant input from co-founders Jim Truchard and Bill Nowlin, along with Jack MacCrisken. National Instruments had built its business selling GPIB (IEEE-488) hardware that let computers talk to laboratory instruments, but writing the software to drive that hardware in textual languages such as BASIC or C was tedious and error-prone for the engineers who were NI’s customers.

Kodosky’s insight was that engineers already think in terms of block diagrams — signal-flow charts, schematics, and process diagrams — and that a programming environment which mirrored that mental model could lower the barrier between idea and working test system. The first release, LabVIEW 1.0, shipped in 1986 for the Apple Macintosh, whose bitmapped graphics and consistent GUI made the visual approach feasible at a time when most engineering workstations ran character-mode terminals.

Early LabVIEW was interpreted, which limited performance. The major rewrite that became LabVIEW 2.0 in 1990 introduced a compiler that produced native machine code from the block diagram, reportedly narrowing the gap with hand-written C and making LabVIEW viable for production test systems.

Design Philosophy

LabVIEW’s defining idea is data-flow execution. In a textual language the programmer specifies an order of statements and the runtime executes them in that order. In LabVIEW the programmer specifies dependencies — which outputs feed which inputs — and the runtime is free to execute independent branches in any order, including in parallel. This model maps naturally onto the inherently concurrent world of instrumentation: while one loop is acquiring samples from an oscilloscope, another can be filtering yesterday’s data and a third can be updating a plot.

Several principles follow from that core:

• The diagram is the program. There is no underlying text representation that the developer edits; the graphical source is the source.
• Strong, static typing on wires. Each wire carries a specific data type (a 16-bit integer, a waveform, a cluster, an array of doubles), and the editor refuses to connect incompatible terminals.
• Front panel as first-class UI. Every VI is also an interactive instrument; you do not need a separate GUI toolkit to give a routine a usable face.
• Hardware-aware libraries. LabVIEW ships with extensive drivers and palettes for instrument control (VISA, IVI), data acquisition (DAQmx), signal processing, and analysis, reflecting its origins as a tool for working with real-world signals.

Key Features

• Graphical block diagrams with structures for loops (For, While), case selection, sequences, events, and timed/deterministic execution.
• Automatic parallelism: independent branches of a diagram run concurrently without explicit thread management, and parallel-for loops can distribute iterations across cores.
• Strict dataflow with by-value semantics for wires, which sidesteps many concurrency hazards common in shared-memory threaded code.
• Rich numeric and signal-processing libraries, including FFTs, filters, fitting, and waveform manipulation.
• Tight integration with NI hardware — PXI chassis, CompactRIO, FPGA targets, and DAQ boards — via DAQmx and FPGA toolkits.
• Real-Time and FPGA modules that target deterministic real-time operating systems and Xilinx-based FPGA hardware from the same diagram-based source.
• Connectivity to textual code via Call Library Function (C/C++ DLLs), .NET, Python nodes, and shared variables for networked systems.

Evolution

After the move to a compiler in 1990, LabVIEW expanded along three axes: platforms, domains, and abstractions.

On platforms, LabVIEW moved from Mac-only to Windows and Unix in the early 1990s, eventually concentrating on Windows while adding real-time and embedded targets. On domains, NI layered specialized add-on modules onto the core environment, including the LabVIEW Real-Time Module for deterministic execution, the FPGA Module for compiling diagrams to Xilinx FPGAs, and toolkits for control design, vision, sound and vibration, and RF.

On abstractions, LabVIEW gradually adopted features more familiar from textual languages: object-oriented programming (LVOOP) arrived in the mid-2000s, error-handling clusters became a near-universal convention, and the editor gained refactoring and source-control friendly features. LabVIEW NXG, launched in 2017, was an ambitious rewrite of the editor itself, but NI announced in 2020 that NXG would be discontinued and that future investment would return to the classic LabVIEW codebase.

In 2023, Emerson completed its acquisition of National Instruments, and LabVIEW became part of Emerson’s Test & Measurement portfolio. The product continues on its annual release cadence (e.g., LabVIEW 2024).

Current Relevance

LabVIEW is no longer the only practical way to drive lab instruments — Python with PyVISA, MATLAB, and vendor SDKs have all eaten into territory it once dominated. Even so, it remains entrenched in test engineering, industrial measurement, and academic instrumentation, particularly where NI’s PXI/CompactRIO hardware is in use. Its real strengths today are the combination of the data-flow model with NI’s hardware ecosystem, the FPGA and Real-Time toolchains that let an engineer target a CPU, a real-time OS, and an FPGA from one diagram, and a large body of existing VIs in production test systems that customers continue to maintain and extend.

Why It Matters

LabVIEW is one of the most successful examples of a visual, data-flow programming language ever shipped commercially. It demonstrated that a non-textual notation could support real engineering work at scale, that data-flow semantics could provide implicit, safe parallelism long before this became fashionable in mainstream languages, and that programmers’ tools can usefully be shaped around the mental models of a specific user community — in this case, electrical, mechanical, and test engineers — rather than around general-purpose computer-science abstractions. Its long run, from a 1986 Macintosh application to a present-day toolchain that targets multicore CPUs, real-time operating systems, and FPGAs, makes it one of the more remarkable artifacts of programming-language history.