What's the real advantage to LabView?

[tarchon@imap2.asu.edu]

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

[Greg_McKaskle2]

> 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

[Tariah]

tarchon@imap2.asu.edu wrote:
>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




Hi Ben...With LV you get to go home at night and have a life. You can program,
debug, and then implement LV code quicker than any of the text-based languages.
You have to focus on data-flow thinking, but once you do you can never go
back.
Tariah

[helix_r@my-deja.com]

In article <8ajk8j$98b$1@news.asu.edu>,
tarchon@imap2.asu.edu wrote:
[...]
> 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?
[...]
I agree. I really hope that this limitation is addressed in
future versions of LabVIEW (any word on when, Greg M.? 🙂 ).
Labview has really crossed over to being a powerful general
purpose language. If this "event-driving" issue were solved,
there would be *nothing* to hold back labview from becoming a
mainstream langu
age for small quick tasks (in addition to
its role of being the language of choice for data acquisition).
-H.


Sent via Deja.com http://www.deja.com/
Before you buy.

[Greg_McKaskle2]

> > 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?
> [...]
> I agree. I really hope that this limitation is addressed in
> future versions of LabVIEW (any word on when, Greg M.? 🙂 ).
> Labview has really crossed over to being a powerful general
> purpose language. If this "event-driving" issue were solved,
> there would be *nothing* to hold back labview from becoming a
> mainstream language for small quick tasks (in addition to
> its r
ole of being the language of choice for data acquisition).

The technical challenge to adding event notification isn't that
great, but making it simple to use and well integrated is a bit
more difficult.

Assuming that events were well integrated, LV may become a great
language for general tasks, but that doesn't necessaryily mean that
it makes business sense for NI to make sell it that way.

Only time will tell.
Greg McKaskle