What's the real advantage to LabView?

Question

Hi
I just started working with LabView to evaluate it's potential for
controlling an experimental apparatus I'm building, and I'm trying to
decide between it and C++. I've heard many recommendations of LabView,
but I've been disappointed with it so far.
My chief objection is program control. LabView to be sure does have nice
GUI control objects that are easy to implement, but the lack of
event-driven control structures is frustrating. After looking things over
and experimenting a lot, I figured out a way to do GUI events with
Synchronization VIs and a Case Structure, basically building my own
message loop, but then I started to think - isn't this what I used have to
do 10 years ago before the days of C++ class
libraries? Sure, I'm saving
a little time with my basic GUI controls, but to really customize controls
I have to use ActiveX (LabView's "custom" control facility is pretty
weak) too ,and if I used C++ I could get away with plain old child
windows. I know LabView couldn't be as popular as it is if it didn't
offer more advantages, so what is it I'm missing here? Is it just that
LabView is easier for non-programmers?
I'm also a bit shocked that the only While Structure (which perhaps should
have been called the "Until" Structure) is execute-and-test. There's a
reason why most other programming languages give you both
execute-test-loop and test-execute-loop control structures. That seems
like a big oversight that should have been easily correctable. I know I
can fix it by adding some more logic to it, but once again I find myself
paying for slightly easier GUI control object implementation by having to
jump through all sorts of program control hoops.
Thanks,
Ben Buckner

Answer 1

> I just started working with LabView to evaluate it's potential for
> controlling an experimental apparatus I'm building, and I'm trying to
> decide between it and C++. I've heard many recommendations of LabView,
> but I've been disappointed with it so far.
>
> My chief objection is program control. LabView to be sure does have nice
> GUI control objects that are easy to implement, but the lack of
> event-driven control structures is frustrating. After looking things over
> and experimenting a lot, I figured out a way to do GUI events with
> Synchronization VIs and a Case Structure, basically building my own
> message loop, but then I started to think - isn't this what I used have to
> do 10 years ago before the days of C++ class libraries? Sure, I'm saving
> a little time with my basic GUI controls, but to really customize controls
> I have to use ActiveX (LabView's "custom" control facility is pretty
> weak) too ,and if I used C++ I could get away with plain old child
> windows. I know LabView couldn't be as popular as it is if it didn't
> offer more advantages, so what is it I'm missing here? Is it just that
> LabView is easier for non-programmers?
>
> I'm also a bit shocked that the only While Structure (which perhaps should
> have been called the "Until" Structure) is execute-and-test. There's a
> reason why most other programming languages give you both
> execute-test-loop and test-execute-loop control structures. That seems
> like a big oversight that should have been easily correctable. I know I
> can fix it by adding some more logic to it, but once again I find myself
> paying for slightly easier GUI control object implementation by having to
> jump through all sorts of program control hoops.
First off, note that I'm not the typical user as I work for NI, on LV. One
of the biggest advantages to LV is that it is a dataflow language that works
largely by value. This means very few side-effects in a language that
supports fine grained parallelism. The other features that stem from these
are garbage collection, easy to build/test code modules, and lots of public
domain SW in the instrumentation and analysis areas. Also, LV is very open.
Since most of its driver integration is done through DLLs and CINs, that
means that you can too. You can call DLLs, automation servers, integrate
ActiveX controls, communicate over TCP, and lots of other protocols; so your
hands are rarely tied to just what NI ships with LV.
The UI elements make many instrumentation programs easy and simple to write.
They don't give as much flexibility as a framework written in C++, but they
perform the 80% case with much less effort.
If you are comfortable with C++, and aren't looking to simplify your
programming tasks, then you might want to look towards the Visual Studio
plug-ins NI sells like Componentworks or Measurement Studio. NI doesn't
attempt to limit your options to just LV. They will offer more flexibility
than LV, but will not have some of the advantages that LV brings to the table.
As for how many loop types are built in, again, the goal was more one of
simplicity than of flexibility. In reality, I almost never use a do loop
or a while loop in C/C++. I also rarely need to add anything to a LV
loop to make it pre-test. I also don't write very complicated UI's in LV.
If I do, I build a state-machine that takes care of UI transitions. True,
LV could build this stuff in, and it probably will in a future release, but
in the meantime it has lots to offer. Is it what you are looking for?
Greg McKaskle