LabVIEW vs Visual Basic

[TNT News]

I am looking for some comparisons of why LabVIEW is a better or worse than
Visual Basic for test and measurement applications. I have a customer who
wants to standardize on one or the other and I don't have enough experience
with VB to make a good comparison. Their applications mostly involve test
and measurement using GPIB and NI-DAQ boards.

Another request they had is to do a benchmark experiment that might compare
both the time to create an application and the efficiency of the application
after it has been created. Any ideas?

Thanks,

Neal Pederson, President, VI Control Systems
1923 Mendius Lane, Los Alamos, NM 87544
TEL: (505) 662-1461, FAX: (603) 388-4969
np@vicsys.com, www.vicsys.com

[RICHARD EVJE PETTERSEN]

TNT News skrev i
meldingsnyheter:392ea10c@newsgroups.ni.com...
> I am looking for some comparisons of why LabVIEW is a better or worse than
> Visual Basic for test and measurement applications. I have a customer who
> wants to standardize on one or the other and I don't have enough
experience
> with VB to make a good comparison. Their applications mostly involve test
> and measurement using GPIB and NI-DAQ boards.
>
> Another request they had is to do a benchmark experiment that might
compare
> both the time to create an application and the efficiency of the
application
> after it has been created. Any ideas?
>
> Thanks,
>
> Neal Pederson, President, VI Control Systems
> 1923 Mendius Lane, Los Alamos, NM 87544
> TEL: (505) 662-1461,
FAX: (603) 388-4969
> np@vicsys.com, www.vicsys.com
>
>
Hello
Visual Basic is not a very fast program, so if the system runs on a high
speed, it is almost imposible
to use VB. Another good reason to use LabVIEW, is that it is compatible with
all the cards from National Instruments. If their applications uses GPIB and
NI-DAQ, you can tell them to use the cards from NI, and that
it is best to use LabVIEW in applications like this.
I have personaly used Visual Basic a lot, and I think it is great, but not
for these type of application.

Richard Pettersen

[CraigGraham]

TNT News wrote in message
news:392ea10c@newsgroups.ni.com...
> I am looking for some comparisons of why LabVIEW is a better or worse than
> Visual Basic for test and measurement applications. I have a customer who
> wants to standardize on one or the other and I don't have enough
experience
> with VB to make a good comparison. Their applications mostly involve test
> and measurement using GPIB and NI-DAQ boards.

I'm more Labview than Visual Basic, so I may think unfairly of VB, but in my
view Labview was designed for test and measurement applications, and is
slowly gaining functionality in the "quickly authoring general applications"
field. Visual Basic on the other hand was designed to quickly bodge together
the user interface of an application, and to write the application if it's
simple enough not to warrant C++ code modules, but isn't going to have the
same level of integration with DAQ and GPIB hardware. If you have an
arbitrarily picked GPIB or serial based instrument, you're more likely to be
able to find an available Labview driver for it than a VB driver.

> Another request they had is to do a benchmark experiment that might
compare
> both the time to create an application and the efficiency of the
application
> after it has been created. Any ideas?

Get a simple GPIB instrument- a multimeter for instance- and write a program
to graph a slowly varying input voltage against time. That'll test the
development time. Testing application efficiency isn't worth the hassle as
far as I'm concerned- given the availability of computing power nowadays if
you're even considering programming at as high a level as Labview or Visual
Basic, then development speed and maintainability is king.

If you really want to compare efficiencies, you'll have to put a lot of
effort into it. You'll have to identify the most processor intensive parts
of your program- it could be feeding a huge many megabyte data array into a
set of formulas for example- and you'll have to code something similar in
both languages that does the same job. However, the way you write such a
piece of code in the two languages is probably going to have more of an
impact than the inherent efficiency, so it's more a comparison of your
fluency with the two! So perhaps you'll then have to farm out this stage to
a Labview expert and to a VB expert; though again there's no guarantee the
two people can write equally efficiently!

[daniel sox]

"Craig Graham" wrote:
>>TNT News wrote in message>news:392ea10c@newsgroups.ni.com...>>
I am looking for some comparisons of why LabVIEW is a better or worse than>>
Visual Basic for test and measurement applications. I have a customer who>>
wants to standardize on one or the other and I don't have enough>experience>>
with VB to make a good comparison. Their applications mostly involve test>>
and measurement using GPIB and NI-DAQ boards.>>I'm more Labview than Visual
Basic, so I may think unfairly of VB, but in my>view Labview was designed
for test and measurement applications, and is>slowly gaining functionality
in the "quickly authoring general applications">field. Visual Basic on the
other hand was designed to quickly bodge together>the user interface of an
application, and to write the application if it's>simple enough not to warrant
C++ code modules, but isn't going to have the>same level of integration with
DAQ and GPIB hardware. If you have an>arbitrarily picked GPIB or serial based
instrument, you're more likely to be>able to find an available Labview driver
for it than a VB driver.>>> Another request they had is to do a benchmark
experiment that might>compare>> both the time to create an application and
the efficiency of the>application>> after it has been created. Any ideas?>>Get
a simple GPIB instrument- a multimeter for instance- and write a program>to
graph a slowly varying input voltage against time. That'll test the>development
time. Testing application efficiency isn't worth the hassle as>far as I'm
concerned- given the availability of computing power nowadays if>you're even
considering programming at as high a level as Labview or Visual>Basic, then
development speed and maintainability is king.>>If you really want to compare
efficiencies, you'll have to put a lot of>effort into it. You'll have to
identify the most processor intensive parts>of your program- it could be
feeding a huge many megabyte data array into a>set of formulas for example-
and you'll have to code something similar in>both languages that does the
same job. However, the way you write such a>piece of code in the two languages
is probably going to have more of an>impact than the inherent efficiency,
so it's more a comparison of your>fluency with the two! So perhaps you'll
then have to farm out this stage to>a Labview expert and to a VB expert;
though again there's no guarantee the>two people can write equally efficiently!>>

Give them the best of both worlds, the power of C++ and the ease of Visual
basic, namely Inprise Delphi. Just a thought, Delphi with NI-DAQ is easy,
fast, and powerful.

[Y3G]

If it is still relevant (5 years ago...)

What was the outcome? Who got the project VB or LV?

[Ray.R]

Hi yariv,

You are right... this is a 5 yr old thread.

My guess is that you'll never get that outcome.

If you are curious over which one to choose, I would go with LV without a doubt.

I am now programming in CVI.  Everyday, I look at how to implement something new.  Something that takes a day would take considerably less time in LV. 

If you are considering both, try an exercise.  Implement the solution in the previous post concerning taking some measurements using a multimeter and plotting the measurement over time.  Implement both solutions:  1) using LV & 2) using Visual Basic.  Look at the time it takes to do both from scratch. 

.... and let us know the outcome  😄

this is a fun exercise for anyone caught in the decision of what to choose...  The answer will be obvious..  😉

Ray

[Y3G]

Hi Ray alias JoeLabView,

It is something that I am really trying to solve and I believe it should be made a big issue out of it.

The thing is, that I am using an AGILENT ENA 5071B Network analyzer. The R&DHW guys cannot see the use of putting a PC in between when the ENA already comes with a VB interface editor and one just need to program Macros that runs it...

I need know  a very good argument to tell them that it has a limited space of disc, and running macros directly out of it would limit the possibility to expand with much complex applications.

AGILENT really did put me a stick in the legs with this option in the ENA...

If you have an argument let me know

Best Regards

Yariv

[Dennis_Knutson]

That's really a much different topic than "LabVIEW vs Visual Basic". As you say, the possibility to run some advanced analysis on the external pc is one argument in your favor. You might also want to export the data directly to a spreadsheet ot database. I don't know if the instrument is capable of doing that by itself so you might want to investigate that. Another thing to think about is whether the analyzer will always be used by itself. Are there situations where it would be used with other instruments? Unless the analyzer is capable of being a GPIB controller, an external pc would be able to setup and synchronize multiple measurements. If the instrument requires a human operator to select and run macros, it makes it inefficient for production use. Would it ever be required to run a set of tests over a long period of time? I think most people would rather have a computer doing the control instead having to sit there for several hours.

[Ray.R]

Hi Yariv,

I will add to Dennis' comments...

First of all, one needs to distinguish between actual features, simplicity of use, etc and Marketting BS.   I can provide many examples, if needed.  I've obviously "been there done that..." and learned my lesson...

The is something we need to know before providing any arguements...  >> What do they want  <<

"they" being whoever will be using the instrument..

Is this being used for R&D only?  Meaning, you write a script or a program and the designers use it to test the prototypes?  Will they be doing any measurements, analysis, trend prediction, etc?  or purely running the instrument over & over again?  If it is to run the same thing over & over again, then the VB might be the way to go.  The same applies for a debug station.

If this is to first be used in an R&D environment to be taken to a production environment in the future, then I would not go with the VB route.  No matter what the sales guys say..  you will face some obscure situation where an external PC will be required.  Even if the sales guy (or gal) says that the instrument has enough horsepower and should replace the PC, there will be a cost somewhere...  Remember... the instrument is designed as an instrument first... not a test automation industrial PC connected to a database, etc.  Also, will other test instruments be used (yes I am familiar with the product and yes there is a GPIB port)... ?   If it does go to a production area, what is the production rate (how many cards must be tested on a daily process)?  Ooops..  sorry... I first need to know waht is the intent of the test automation, otherwise I'm gonna go on a tangent to explain why you must be careful with these "added features" that are available with the instruments.  😉

The big question will be:  "is it standalone in an R&D environment" or "will it be used as part of an ATE in production" ???

The answer to the above question will orient you towards the proper impmentation choice (VB or LV).  If you have the luxury, LV is still the better choice...  But the sales guy probably convinced them of the opposite.  Of course, not many sales guys actually implement solutions!! 

Ray

[LV_Pro]

Of course the one variable not mentioned is the familiarity of the too languages to the person(s) writing the code. I'm pretty quick in LabVIEW (not as quick as Jim Kring though!) and have dabbled in VB in the past, so while I could whip up a program to do measurements with the afore mentioned DMM pretty quickly, the fact of it taking longer in VB wouldn't be entirely based on the relative ease of one vs the other. That being said, every time I change my mind in a program about something as simple as a FOR loop rather than a WHILE loop I think about how long it would take to retype one or the other in any text based language. For instrumentation, etc., LabVIEW has some many built features that it has been my choice for several years (when the choice is mine and not my customer's). I will add that for the most part older programs in LabVIEW can be loaded and compiled in the newer ones with out too many problems, something that can't be said for VB.

P.M.