Labview used by the US Air Force Research Labs

[Michael Hill]

When I started my internship at Wright-Patterson Air Force Base, I noticed they were using some very familiar software to FIRST; Native Instruments Labview. I thought, WOW! FIRST is really on the right track! Admittadly, the TechnoKats don't use Labview (to my knowledge), but I just thought that it was way cool that the same software used by first teams is used by the Air Force Reasearch Labs.

[kramarczyk]

LabView is also used at the General Motors Research Labs. FIRST didn't pick it randomly.

[Qbranch]

If you learned to program in any normal language (C, C++, C#, QB, VB, J++, Fortran,...) then LabVIEW is extremely hard to learn. It runs completely non sequentially, and its code is very slow and hogs lots of memory, as it passes all variables by value instead of reference.

Code documentation is also impossible.... you can't just print it out without getting a million pages of cartoons. The 'wires' (assignments) get very complicated to understand after a bit. The 'event driven' frame must be put into a while loop which makes absolutely no sense. Finally, the arrays (clusters) in LabVIEW are not indexably writable.

However, the big draw to lab view is its ability to talk over most every communications bus quickly and easily, as well as the fact that it has drivers for most every single piece of test equipment. It can even interface with Solidworks Cosmos so that you can see software and machine running in real time simulation.

Ok i'm done.

-Q

[Danny Diaz]

I would like to chime in here a little bit, and respond to a few comments you've made:

Originally Posted by Qbranch

If you learned to program in any normal language (C, C++, C#, QB, VB, J++, Fortran,...) then LabVIEW is extremely hard to learn.

LabVIEW IS a normal language. But realize LabVIEW is NOT a procedural language like C and C++, it is a dataflow language. The paradigm change is sometimes difficult for inexperienced programmers who first learn a procedural language (actually a dataflow language is one of the easiest to learn) but once you learn the programming concepts and understand how to use it, you may find dataflow languages to be much easier to use than others in many use-cases.

Originally Posted by Qbranch

It runs completely non sequentially, and its code is very slow and hogs lots of memory, as it passes all variables by value instead of reference.

This is not correct. LabVIEW is absolutely sequential, but LabVIEW follows the flow of data. LabVIEW doesn't pass everything by value, but often it does seem that way (you don't see what's going on under the hood). Again, inexperienced programmers to dataflow languages are often confused by it - please read the wonderful Wikipedia document on Dataflow Languages and on LabVIEW for a different perspective on the theme.

Originally Posted by Qbranch

Code documentation is also impossible.... you can't just print it out without getting a million pages of cartoons.

You're correct, it's not meant to be printed out like most text-based languages. However, code documentation is incredibly easy and LabVIEW provides a myriad of very powerful tools to help you with source control, documentation, hierarchy analysis, and others.

Originally Posted by Qbranch

The 'wires' (assignments) get very complicated to understand after a bit.

Anyone can write code that a computer can read, programmers write code that people can read. LabVIEW (and dataflow programming in general) requires different coding styles than other programming paradigms in order to keep your code understandable - realize it's just as easy to obfuscate C++ code as it is LabVIEW code. Most people find, however, once they actually learn how to properly write programs their code becomes much more efficient and readable - go figure!

Originally Posted by Qbranch

The 'event driven' frame must be put into a while loop which makes absolutely no sense.

It makes perfect sense, but you have to consider the use of that event frame in a dataflow language. An event frame is actually *not* strictly a dataflow object (much like local variables aren't strictly dataflow) - the event frame catches an event, and allows you to process code based on that event. You can use that processed data in your code by passing data outside the event frame. Realize in order to process multiple events, you must put the event frame into a loop so you can process subsequent events (events are queued, by the way). You probably just never realized that events work the same way in other languages, it was just hidden from you.

Originally Posted by Qbranch

Finally, the arrays (clusters) in LabVIEW are not indexably writable.

This is actually not correct. Arrays of clusters (arrays and clusters are completely different, the same way arrays and structures are different in C) ARE indexably writable, the easiest method involves using the "cluster to array" primitive which allows you to use any array primitives you want (for indexing). Understand that National Instruments provides extremely knowledgable developers on its Developer Zone and LabVIEW Forums. If you have a question about how to do something in LabVIEW, please take full advantage of these resources, they're FREE!

Originally Posted by Qbranch

However, the big draw to lab view is its ability to talk over most every communications bus quickly and easily, as well as the fact that it has drivers for most every single piece of test equipment. It can even interface with Solidworks Cosmos so that you can see software and machine running in real time simulation.

That's very true, LabVIEW 8.0 shipped with wizards with the ability to write and customize drivers in LabVIEW to connect to almost any IVI-capable device. LabVIEW has soooo many features and abilities, it sounds as if you've only scratched the surface! Game on!

-Danny