It’s been over 20 years now that National Instruments has been refining LabVIEW as a powerful test, measurement, and automation platform, as well as a general purpose graphical data flow programming language. For many years, LabVIEW’s slogan was "
the software is the instrument
". NI even named the basic building block of LabVIEW programs the "virtual instrument" (or "VI" for short). But, after using LabVIEW now for well over a decade, I have to wonder…
Why is it so hard to create virtual instruments in LabVIEW?
Just to be clear, when I say it’s difficult to create virtual instruments, I’m not taking about VIs (the basic building blocks of LabVIEW programs) with their Front Panels and Block Diagrams. I am talking about
software that
behaves
like a instrument
. Let’s take a step back and look at what I mean by this.
A traditional instrument is a physical device that sits on the lab bench or in a rack. The traditional instrument:
-
has
statefulness
— it remembers whether it’s turned ON or OFF, it knows its active configuration settings, etc.
-
can do
work asynchronously
— you can ask it to reset, acquire some data, perform analysis, etc. You can ask it when it is finished with the asynchronous work and then ask it to send you the data.
-
can have
multiple instances
— just order another one from the catalog and set it on the lab bench, right next to the first. You can give each physical instrument a name, such as "multimeter 1" and "multimeter 2" — you might even choose to use a label maker to print the name and stick it onto the front of each instrument, so that you never forget which one is which.
-
can
communicate with other software and instruments
— TCP-IP, RS-232, GPIB, etc. via SCPI, LXI, or other protocols.
OK, you get the point — you know all about traditional instruments.
Now, let’s say that you want to create a
virtual
instrument — meaning, you want to create software that uses modular hardware that can do everything that a bench-top instrument does. You want to use a data acquisition (DAQ) device as modular I/O and then write some software that uses the DAQ device to implement the functionality and behavior of a traditional multimeter. Where do you get started? First, let’s take inventory of the requirements:
-
Statefulness
-
Asynchronous processing of tasks
-
Multiple named instances
-
Ability to communicate with client software using industry standard protocols such as SCPI, LXI, etc.
Hmmm, it’s starting to sound like we need some kind of by-reference object-oriented framework…
Now, I’m not going to get into the whole
by value
vs
by reference
OOP debate. All I’m saying is that almost every LabVIEW developer who creates a non-trivial automation or control system application will want to create a virtual instrument with all of the features that I’ve identified above and that these features sound a whole lot like by reference objects.
Where did NI drop the ball with virtual instrumentation?
Did the concept of a VI as a Front Panel and Block Diagram distract them (and us) from what we really need from a virtual instrument? Does NI’s marketing mantra shift away from "the software is the instrument" to "design, develop, deploy" imply that they aren’t really concerned with the developers ability to emulate pysical hardware using software (after all, NI does want you to buy
their
hardware)? Is NI simply out of touch with the types of large systems that software developers create using LabVIEW? Or, is NI working on a by-reference framework that will allow us to create our own, stateful, asynchronous, multi-instance, by reference virtual instruments that can communicate using a variety of protocols and physical transport layers?
In a future article, I’ll describe more about the features that I’m looking for in a virtual instrumentation framework and how NI could stand to benefit from implementing something like it.
PS - After writing this, I did happen to find somebody at NI talking about the
Growth of Software-Defined Instrumentation
. Hopefully that’s a good sign.