Lab View

LabVIEW is a system targeted mainly at data acquisition and control systems, based on a graphical language called "G" [GeeLanguage, GraphicalProgrammingLanguages]. There is a RealTime version of LabView as well as versions for the Mac, Sun/Solaris, Linux, Windows, and several other OperatingSystems. You can find a description at http://www.ni.com/labview To eavesdrop on what is occurring amongst users, you might try several blogs accessed via http://zone.ni.com/devzone/conceptd.nsf/webmain/D6275C07C1FE82C586256FFE006B1300

I have used it for data recording through several data acquisition sources, including regular data entry.

Although it is not very OO in nature, LabView allows a visual way to build software. It is based on a "chip" metaphor where chips represent subroutines and things like loop blocks, and wires represent parameters. It tends to target the electronics engineering crowd. It is pretty cool, regardless of whether it is better than textual code or not.

For a quite detailed discussion with JimKring?, with some cool diagrams, see also http://www.jpaulmorrison.com/cgi-bin/wiki.pl?LabView.

Actually it is implementing all the structured programming paradigm. It is as powerful as C, one can integrate C modules and it is easy to learn. I wish Sun, Borland or Microsoft created something similar, but they are failing short. Using LabView one will understand the power of structured programming and see that Object Oriented doesn't add much on top. Programming skills that take years to learn in C++ or Java or any traditional programming language, take just a few weeks with LabView. After using LabView no programmer will think C++ or Java are great. LabView is the best programming language to date because it shows the structured programming way in very short time. How do I know? What I was doing in LabView after 2 month of using it, took me 10 years to learn in C++ and JAVA. Anyway the runtime costs probably over 7,000 US$ and you can't distribute programs to people who don't have the runtime. Or you have to distribute some 25 Mb but I don't believe it works. Therefore the LabView environment and language are only for big companies. I wish it was available for kids, because it is easy to use and it shows the real structured programming way of programming (I said that before). Microsoft has a similar programming language for dealing with Robots, but I don't have a link to it. If interested, try microsoft web site and look for robots. Try to download a demo from ni.com to convince yourself. There is a student version as well.

My little brother got certified as an official lab view developer a year after being introduced to it through the "FIRST robotics" thingy. He didn't have any prior experience in programming but it has integrated documentation that allowed him to pretty quickly become proficient. When I try using it the one thing I notice is that it has some very excellent libraries for most things I wanted to do.

One of the interesting things about LabVIEW is the "virtual instrument" metaphor. The basic unit of reuseability is a .vi file, which you can create and then "call" from other places in your code base. However, when they mean "virtual instrument," they mean it--the default way to compile a .vi file gives it static storage, with locks to ensure that it can't be called in more than one thread at the same time, giving the impression that each .vi really is a physical circuit dedicated to a certain subtask. Fortunately, you can set .vi files to compile so that space is allocated either statically at the site of each call, or dynamically, instead.

Continuing the circuit metaphor, the LabVIEW concept of loops is somewhat overloaded. Because it is a visual dataflow language, there are very few named variables--there are the input wires and output wires to a .vi, and that's about it; in fact, creating a local or global named variable is a complicated process, likely to discourage the un-LabVIEW-like style. Unfortunately, LabVIEW does not allow more than one wire to flow into the same data node like most dataflow languages do. Instead, they have loop structures which evaluate the code inside them repeatedly. To store information between loops, LabVIEW instead offers something called a "shift register," which acts as a persistent store between loop iterations. It is always read from at the beginning of the loop and written to at the end of it. Normally, a shift register is initialized at the beginning of a loop. However, it also may be intentionally left un-initialized; if this happens, thanks to the .vi's static storage, the shift register becomes static storage space. (Usually if this is done, the loop is set as a while(0) loop; in LabVIEW, all "while" loops are actually do...while loops, because the sentinel is calculated in the body of the loop.) If the .vi is compiled so that it's allocated in the caller's static space, the shift register will still become a static variable, but only if the function in the same place is called more than once. If anyone who's better at explaining LabVIEW than me is willing to RefactorMe, go right ahead. Anyway, the practical upshot of this is that rather than instantiating a PID-controller object and telling it what to do, we do the equivalent of while (true) control_variable = PID(signal, target, {p, i, d}), and the VI Does What We Mean.

The other thing which LabVIEW has to recommend it is that uncreative developers will not have to think of good names--when ever wire can be visually traced to its origin, a comment describing function is all that's needed, if anything; parameter names can afford to be long, since nobody has to type them out; and though you do have to name the .vi files, they're represented in code by icons, meaning that you can "name" your function a pretty picture.

CategoryControlSystemsSoftware