Comments on: Did National Instruments forget about Virtual Instruments?

By: Jim Kring

Jim Kring — Tue, 12 Aug 2008 16:12:06 +0000

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

By: Darryl Phillips

Darryl Phillips — Tue, 12 Aug 2008 08:17:57 +0000

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.

By: Alex

Alex — Wed, 30 Jan 2008 08:13:03 +0000

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)

By: CBL

CBL — Fri, 25 Jan 2008 17:50:15 +0000

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

By: Bob Young

Bob Young — Fri, 25 Jan 2008 16:48:39 +0000

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

By: Shane

Shane — Thu, 24 Jan 2008 14:45:25 +0000

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.

By: Tomi Maila

Tomi Maila — Thu, 24 Jan 2008 12:25:39 +0000

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.