I believe that we are currently laking a lot of features that would enable users to easily create Virtual Instruments and I've written an article about it here:

• Did National Instruments forget about Virtual Instruments?

What are your thoughts? What does software-defined instrumentation mean to you? What gaps exist in LabVIEW that need to be filled?

[cross-post]

Great trigger for a hopefully enlightening debate, Jim!

I fully agree with what you've said!

-Franz

Very nicely formulated Jim ! I am missing that vision on the future of virtual instrumentation from NI. There may be other points where NI is ahead of competition, but not in the area of big systems. There is no commercial reason not to go there, there's a lot of profit to make.

With the requirements you hit the nail on the head. Let me add one requirement, already present in "old" LabVIEW but also required for "bigger" virtual instrumentation:

• Have a user interface system that can also display/manipulate internal data, allowing you to test a newly created function right away, without the need to develop an entire test program for the function (required in C).

No rapid development without this. But maybe, with this requirement, I am getting too far from your comparison with real instruments.

Joris

This post has been edited by robijn: Jan 24 2008, 04:30 PM

Jim, I agree that your list of what is missing most in the development of virtual instruments in LabVIEW. If NI would streamline the development process for these items my tasks would be a lot easier!!!

nice Article Jim!

(sorry AQ!) I think NI is currently spending to many resources in the development of LVOOP and has forgotten, that there are may developers who use LabVIEW for their daily business and would like to see smaller improvements now rather then the big ones somewhen later. There is big gap between the marketing hype which is made around LVOOP and the improvements for my all day work. Maybe NI should fire a couple of the marketing vice presidents and hire some more enginerds / developers instead I don't want to say that LVOOP is good or bad, but I think there is too much pressure behind this topic. Sometimes I think a real competitor to NI would be helpfull

I've always thought that the term "virtual instrument" referred to the fact that the front panel actually looked like a desktop instrument. That is, that the UI widgets were buttons, knobs, switches, dials and graphs. You know, all the things we were used to seeing on physical instruments, now displayed on a computer monitor. I imagine in 1988 that was a pretty big deal. Now that every program apparently has to look like every UI widget is made of 3D shiny wet plastic buttons on it or is made of brushed aluminum, it's not. (Don't get me started.)

Most of the characteristics (statefulness, multiple instances, communicate with other software and instruments) you cite for virtual instruments actually seem to me to be more applicable to by-value objects than by-reference. The instrument is the wire and the wire is the instrument.

Asyncronous communications doesn't seem to me to be part of the paradigm of an instrument. I mean, I don't sit down next to my oscilloscope and fiddle with the knobs asynchronously.

That being said, and having only dabbled with them, I think the utility of by-value objects is somewhat limited. By-value objects fit perfectly into the LabVIEW paradigm, but I think the addition of by-reference objects would be immensely helpful, and I hope LabVIEW will have them at some point in the future.

FWIW, I agree with all of this except for the last paragraph. Yes, it would be NICE to have by-ref included in a more comprehensive and facile way but I really am not interested personally in LF become the picture-IDE for C++/Java. I agree also with a prior commentor who pointed out that perhaps LabVIEW has placed too much emphasis recently on by-ref constructions/implementations and that there are some more pressing and important points to follow on. Having used LabVIEW as much as I have for as long as I have, I really wnat to maek certain that the original core concepts and functionality remain intact even while other constructs, are added to LV.

Really? You may not think of it as asynchronous, but on most scopes, you can adjust any of the knobs while the acquisition is running, and in just about any state, the instrument will handle it gracefully. The scope doesn't have to exit out of its measurement mode or wait until a scan is finished, and making the change won't erase your most recently acquired waveform. The instrument can do all that because the adjustments are asyncrhonously applied.

I think part of Jim's thesis is that achieving this grace in a LabVIEW VI is much trickier than most of us would like.

This post has been edited by jdunham: Jan 24 2008, 11:36 PM

Hi All,

Thanks for the feedback on the article. My main point is that while many of us have (for years) been asking NI to give us by reference object-orientation, the main class of problems that we have been trying to solve with such frameworks is the creation of software-defined, "virtual" instruments. By calling this construct a "virtual instrument", I think that we can convince NI that it is important and worth thier while to address.


Actually, I did forget to mention this and it's a very important concept. In my by reference (er... virtual instrumentation) frameworks user interfaces are integral first class citizens. I'll expand on this in follow-up articles.


Actually, by value OOP is critical for implementing by reference OOP, since references are values. The framework that I use is actually implemented with Tomi's OpenG Reference Object framework, which is built upon LVOOP. That said, much of what I want in a virtual instrumentation framework does not necessarily require language-level native OOP. For example VISA and IVI are not pure OOP, even though they provide nice instrumentation abstraction layers.


No, a physical instrument is on object on the bench. If you fork an instrument (for example, with a axe), well... it's forked. When you reference a physical instrument, in LabVIEW, you carry a communication session handle (e.g., VISA reference, TCP connection handle) in the wire.



Regardless of whether you use the knobs on the instrument or you send a SCPI command to the instrument over GPIB, the instrument can do work asynchronously. For example, if you ask it for data before acquisition is complete, then it might return an error message. My point is that the embedded processor on the instrument is running a software loop in parallel to (asynchronously from) the loop in your software that's sending the instrument commands from LabVIEW.

In closing, this is a fun topic. I'm excited by all the responses. And, I'm looking forward to expanding on these concepts and discussing more with you all.

Thanks,

-Jim

Good Topic Jim!

Perhaps another aspect of most (but to be fair, not all) physical instruments is that:

• they are self contained in a single box.

When I fire up my Tektronics 2024, I just have to have that single box on my desk and powered up. I don't have to power up a separate box to configure device name, channel names or gains-- In an analogy to DAQmx/nidaq.

Not that I object to these tools, but I seem to recall in the past being able to use NI gear in the past entirely from LabVIEW without first separately launching the Configuration utility. Perhaps I'm missing something, but I can't always seem to do that any more.

E.G. just got a USB 8451, and for the life of me I couldn't get it to work in LabVIEW without first launching MAX to give it a VISA alias-- Unless I do that, the name choice for the device that comes up when I create a constant for "device reference in" doesn't work.

Again Jim, thanks for starting a good topic...

Best, Louis

To give an idea of what bigger programs with virtual instruments can look like, this is the framework that I'm working with today.
This framework loads instruments dynamically, loads measurements dynamically and reads measurement sheets that describe what measurements to perform. It can be programmed to sweep measurements in complex ways. The loaded instrument drivers have a front panel to interact with them and they are self contained (i.e. the state they show is always the same as the state of the physical instrument (unless you fiddle with it)). The main program of the framework is visible in the back of the image and some instrument driver panels are visible in the front.

This framework is in use on a dozen systems (even worldwide) by an equal amount of users of which some also develop instrument drivers and measurement functions for this framework.

It would be very convenient if LabVIEW would be of more assistance with these kind of instrument drivers. Now, I have had to write all the data/state storage myself, which is prone to error. All commands to instrument drivers go via a functional global-like mechanism... a special method available in each instrument would have been much cleaner. Further only one instance per instrument driver is possible with this setup. This is acceptable, but only just - we make a copy of the main instrument VI if we need more than one.

I think it would be good if NI introduces new features that fascilitate a complex system like this. Using the current LVOOP would not have yielded any benefits on this system at all, actually it would have made things a lot more complex. Simplicity is what made this framework successful. Simplicity in the form of transparency and ease of use. Note that this is not in contradiction with a complex system: The total system may be complex, but each small part locally is understandable (also an important principle in OO design). Most users of the framework don't know how the system exactly works, but they can use it nevertheless. This way I am able to fascilitate many users to perform complex measurements. And very often they want things that are currently impossible so require new features in the framework. Very annoying

Joris

Ok, let's say it the other way round:
I'd like to see LabVIEW Classes which have Objects and a new operator, which means: you can design a class, like that "C++ for dummies" Class "Car", which is the parent of the (e.g.) "Chrysler" Class and you can create a lot of cars with


But (and that's my guess) it will last a while until LabVIEW is that far and maybe NI should not forget about the actual needs of their customers until they have reached their (or only my?) "big goal". I don't want to sound like the "PermanentlyRantingOldManLivingInDaPast" but the Quality of LabVIEW 7.1.1 was excellent. And NI has IMHO never reached that quality again with LabVIEW 8.x ...

BTW: I hate those f**** big Objects Blockdiagramm Icons they are totally ugly! can please anyone design something nice and small?