Did National Instruments forget about Virtual Instruments?

Posted on Tuesday 22 January 2008

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. :)

10 Comments for 'Did National Instruments forget about Virtual Instruments?'

  1.  
    January 24, 2008 | 5:25 am
     

    I think NI faced a strategic choice with LabVIEW; either they support a wider range of hardware from starting FPGA all the way to mutli-processor workstations or they can make the language richer. I don’t really know if would have been forced to choose only one of these choices but we all know they chose the wider hardware support over new language features.

    Having made this choice, I’d really hope they would open up the LabVIEW development environment for developers so that third party developers could add language abstractions to LabVIEW.

  2.  
    Shane
    January 24, 2008 | 7:45 am
     

    Er, there’s quite a large logical leap from the list of requirements of a virtual instrument to “Hmmm, it’s starting to sound like we need some kind of by-reference object-oriented framework… “.

    Maybe I lack the experience, but can someone explain what these two seemingly unrelated aspects?

    Shane.

  3.  
    Bob Young
    January 25, 2008 | 9:48 am
     

    I’m with Shane. I don’t see the leap. There are ways to do each of these things that don’t require the leap to pass-by-reference. Just where are you stuck or having to do more work that you think you need to do that a paradigm shift to pass-by-reference would magically solve?

    I will freely admit that I don’t have a strong OOP background so it may be obvious to everyone else, but it is sure not obvious to me.

    Thanks,
    Bob Young

  4.  
    CBL
    January 25, 2008 | 10:50 am
     

    Thought provoking article Jim, thanks!

    It would be nice if it was easier in LabVIEW to fulfill your list of requirements. I hope NI addresses this issue of making virtual instrumentation easier to create and I don’t care too much if their solution includes by-reference LVOOP or not.

    @Bob and Shane – I don’t think the by-reference, by-value LVOOP is the issue here. Given the list of requirements for virtual instrumentation, I do think it is fair to say that a “by-reference object-oriented framework…” seems like a very reasonable solution that may make creating virtual instrumentation easier. Are there other solutions, probably, so let the dialogue continue…

    Chris

  5.  
    Alex
    January 30, 2008 | 1:13 am
     

    I’m with Maila.
    As far as I know, LV is a not popular “development enviroinment” for general use, like Visual Studio .NET. LV was focused on the concept “virtual instrument” and easy deployment with NI hardware. Maybe they are puching now the “language” aspect more to shorten the gap with general pourpose enviroinment.
    Example: you must make a graph of a signal. In LV is trivial, you already have the indicator by default. In Visual Studio, there is not a “graph” object, so the way is google for some free components (open source, etc…) or develop your own (very difficult for beginners).
    By the way they are faaaaar from recover the gap with traditional languages (see for example how LV treat XML compared to visual studio….in VS it’s completely natural and integrated, in LV is so weird and clunky)

  6.  
    Darryl Phillips
    August 12, 2008 | 1:17 am
     

    Huh? I use virtual instruments all the time. Of course, there’s the secret sauce that makes my implementations better than yours but we won’t talk about that. ;-)

  7.  
    August 12, 2008 | 9:12 am
     

    Darryl: In your answer you imply that you agree with at least some of my definition of virtual instrumentation and you hint that you have some (object oriented?) framework that allows you to achieve the goals of virtual instrumentation. Do you want to share more? It sounds to me like you want everyone to know about your solution ;)

  8.  
    Alex
    December 19, 2008 | 7:35 am
     

    Now Visual Studio .NET has a free library for Charts (MS .NET chart control) that is superior to the Chart control shipped with labview.
    Bad times for LV addicted ;)
    MS Chart controls provides features that are unreacheable for even exeperienced LV programmers at it’s so easy to use.
    People, forget LV for general use, switch to VS! USA is in recession, it’s suicide to spend time in a obsolete techonoly like LV.
    VS is AS EASY AS labview, and far more powerful

  9.  
    December 19, 2008 | 11:29 am
     

    Alex,

    You sound like you might share a lot of the same opinions as
    American subprimes
    and you are both from Italy. You two should become friends! :)

    Happy Holidays!

    -Jim

  10.  
    March 13, 2016 | 7:20 pm
     

    Make certain you follow to the letter the reimbursement necessities for
    your mortgage. If you do not repay the loan as required, the money you borrowed might
    be thought-about a taxable distribution.

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 1123 access attempts in the last 7 days.