Why use LabVIEW? [closed]

Question

I am learning to use LabVIEW as part of my honours project, and was wondering what benefits the graphical programming language has over a textual one?

Answer 1

Its all about the equipment drivers and user capabilities. NI (Labview) has a well supported set of lab equipment drivers that are easily interfaced. A test operator (not a developer) needs a gui with a big green/red pass/fail button. I've implemented complicated automation via python in cygwin. A Labview developer was able to invoke the cygwin/python system and data mine the log files. So you can do both. The python system is portable, maintainable, extensible, usable and best of all, free.

Answer 2

To me, the benefit of LabVIEW is not in graphical vs. textual.

It's dataflow vs. imperative.

Dataflow programming lends itself to concurrency, because your execution is modeled as black boxes which execute when their inputs are valid, whose inputs / outputs are wired together. This as opposed to implicit state with a list of instructions on how to modify it. (Loosely paraphrasing 'kipedia, the article linked above is better.)

Each black box can run on a separate core/processor/node, which gives you, effectively, free concurrency if you organize your program the dataflow way.

Unfortunately (and this is a crippling downside to dataflow programming in general) the best way to visualize and edit dataflow programs is graphical, not textual. This makes using tools such as revision control and code generators very difficult.

The question is: Do the pros of dataflow outweigh the cons, for you and your project?

Answer 3

One of the main advantages to graphical programming with LabVIEW is that the source code is very similar to circuit diagrams, so it's a very easy language for electrical/electronics engineers to pick up. This is one of the reasons that LabVIEW has become so popular in the data acquisition and automation fields, where EEs are plentiful.

Another advantage that I found was raw speed of development. You assemble your GUIs from a palette of available front panel controls, very similar to how you do it in Visual Studio. The source code is written in a similar manner, with many pre-defined components that you can drop in from menus and wire together.

A third advantage is compatibility with hardware. National Instruments main business is data acquisition hardware, and they go to great lengths to make sure all of their products can communicate with LabVIEW software straight out of the box. Many other hardware vendors in the data acquisition and automation control industry are doing the same.

Answer 4

I've used labview before for calculating parameters to tune an nMRI machine. They exist because in theory it is easier for someone with little programming language experience create a program. The control flow and decision structures can be arranged graphically and they can type in their formula's where they want.

For professors and lab assistants...helpful. For real software developers...it would be easier to write in another language.

Answer 5

I've used LabView in the past, and for data acquisition, virtual instrumentation, etc - there is nothing better. The last time I used it was 10 years ago, and nothing I've seen since has matched where it was in the mid 90s.

Answer 6

Some advantages of LabVIEW in my view are:

• The built-in user interface components such as buttons, graphs etc literally require no programming whatever; you just place them on the front panel and the data terminals appear on the block diagram.

• There is a large library of drivers for data acquisition hardware and test instruments. If your task is basically about getting data to and from these and putting a user interface on it then you can achieve it with almost no programming.

• Parallel execution of multiple tasks is handled automatically - place two independent loops on the diagram and they will execute simultaneously. This is often a requirement in data acquisition and control applications.

Many people, including 'real software developers', feel that the graphical paradigm suits the way they think and visualise their software better than the textual one. There are undoubtedly things that text languages are better for than LabVIEW (covered in another discussion on this site) but where LabVIEW is suitable it's very good at getting the job done.

Answer 7

To me it comes down to what you are comfortable with, if you're comfortable in text based languages, you'll likely find that Labview just introduces another learning curve. Unless you have a specific goal to learn and use Labview I see no point for your project.

On the other hand, if you aren't particularly comfortable in text-based languages, I tend to have the opinion that Labview is easier to pick up and learn, particularly for non software engineers.

I use text based languages for test engineering as well as Labview and TestStand quite often and for me it's more about who else will use my software than it is about me. Some companies have several Labview trained individuals and others prefer to write in text based languages. Training for another language can be very costly on a company-wide scale and it changes the hiring requirements for positions within a company so some companies are virtually 'locked-in' to one paradigm or the other. I would say your best bet if you intend to work in the industry is to be versed in both, that way you are flexible. If that's the case and you have the time to learn either, I'd say work in the one you're least comfortable with and expand your breadth of knowledge, that's what school is for right?