Thinking in G » National Instruments

Vote for LabVIEW features at ni.com

Jim Kring — Mon, 01 Jun 2009 15:55:41 +0000

I’m excited about the new LabVIEW Idea Exchange where users can share and vote on ideas for LabVIEW features. In fact, I’ve already posted an idea, Option for Disabled Structures to Not Use Default Value for Unwired Output Tunnels, which was taken from a previous post (a rant, really), here at Thinking in G.

I’m thankful that NI is giving users ways to communicate ideas for how to improve LabVIEW, and I’m certain that this will really help in giving users a voice about pain points in LabVIEW that might not be readily apparent to NI. This is yet another example (here are a couple more) of how NI is working hard to open up LabVIEW and let the community participate in making LabVIEW better.

Kudos to NI and the great feature ideas that are already showing up on this powerful, new community tool.

A Challenge to NI: Use your Application Builder

Jim Kring — Tue, 27 May 2008 07:00:51 +0000

I'd like to challenge developers at NI to find more ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes.

One of the major pain points in my day-to-day use of LabVIEW (which I love) is building stand-alone applications. I suspect that the reason this is so painful for me is that (in addition to my use cases being fairly advanced) most of the developers at NI who are on the LabVIEW development team probably don't build applications using LabVIEW -- they are not eating their own dog food.

For example, LVOOP (native LabVIEW Object Oriented Programming) dynamic method overriding requires VIs of the same name, but it is impossible to store two VIs of the same name inside an EXE? How could this feature conflict possibly happen? I suspect that nobody actually tried to build an application that used LVOOP until well after the feature was implemented. What's even crazier is that NI was working on this feature for many years, before it was released.

As time goes by, more people within NI are developing code in LabVIEW on a daily basis. However, I'll bet that most of them never actually use the application builder to build stand-alone applications, since most LabVIEW code is shipped in source form and never gets "built" -- it's just one big, monolithic reuse library.

So, I'd like to challenge developers at NI to find ways to incorporate stand-alone (built) LabVIEW applications into their internal systems and processes. It will make a huge difference to your customers.

I'll have you know that I'm committed to eating my own dog food, too. At JKI, we work very hard to use our own products in a variety of ways:

EasyXML is being used inside VI Package Manager (and other JKI products and projects), for reading and writing XML files.

VI Package Manager (VIPM) is used to install EasyXML, as well as manage the LabVIEW configuration needed to develop and build EasyXML (and every other JKI product and project).

I'm only telling you this, because I'm committed to practicing what I preach. And, we're working on a new version of VIPM that is going to take this concept to a whole new level -- more on that, later.

I should close by saying that I know some of the people who work on the LabVIEW application builder and LVOOP and they are all very nice/smart people who are very competent LabVIEW developers and software designers. The only problem is that they are probably not eating their own dog food. NI has stated that they are committed to this, so I want to make sure that this is one area they do not neglect

Did National Instruments forget about Virtual Instruments?

Jim Kring — Wed, 23 Jan 2008 03:00:53 +0000

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.