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.
communicate with other software and instruments
— TCP-IP, RS-232, GPIB, etc. via SCPI, LXI, or other protocols.
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:
- Asynchronous processing of tasks
- Multiple named instances
- Ability to communicate with client software using industry standard protocols such as SCPI, LXI, etc.
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.