Thoughts on LabVIEW

NI LabVIEW is a graphical “programming language” oriented toward experiment and data acquisition automation. It’s useful in a lot of situations, and fairly easy to pick up. I’ll even give LabVIEW a pass for being a proprietary vendor-specific tool (and not an open-standard language like C). Proprietary tools are often useful, and even with the best of intentions, open-source communities don’t always have the resources to provide slick, easy-to-use tools.

For certain tasks, mostly involving data capture and analysis, LabVIEW is a very useful and intuitive way to create software for laboratory automation. If an experiment required the capture of a signal, outputting a snapshot of a Fourier transform whenever certain parameters were met, LabVIEW would be a good choice of software tool.

However, LabVIEW, by its nature, is unbelievably bad at certain other tasks. Specifically, basic arithmetic operations are generally done by wiring numbers to mathematical operators. To add two and four, you create “constant” objects for “2” and “4”, then run wires from each of these into an “addition” module (which looks like a miniature op-amp symbol.) This makes wonderful sense when routing signals and control lines; not so much when performing basic arithmetic.

The true nightmare, though, doesn’t appear until complex program-flow logic gets into the mix. Once an application becomes more than moderately complex, the LabVIEW schematic quickly starts to look like a psychedelic plate of alien spaghetti. One image in particular that I found on The Daily WTF illustrates the point beautifully.

*Literal* spaghetti code! (Click to see it in all its high-def glory...)

When your “program” looks like this, the language is trying desperately to tell you something. Pain, after all, is Nature’s way of saying “DON’T DO THAT!” Here, LabVIEW is doing its best to tell the programmer that it just doesn’t naturally bend in that direction. It’s like trying to implement linked lists in BASIC or writing a flight simulator in LISP. It might be possible, but that doesn’t mean it’s a good idea.

A while back, I buttonholed a NI rep at one of their local “hands-on” seminars. (One thing NI does very well is customer relations and training.) I eventually got him to admit that yes, there is an actual language behind the scenes that all these graphical connections are eventually compiled into. He mumbled something about it being for NI developers only right now and not-really-ready-for-prime-time and so on.

Even if that’s so, having the option to code in actual code would be very helpful. LabVIEW could retain the graphical interface for signal-flow applications, while offering a C-like text interface for applications that work better with more complex control structures. There are even ways to do concurrency (one of LabVIEW’s selling points) in textual languages — and in fact, this has probably already been solved in NI’s behind-the-scenes language.

Why not let the man behind the curtain out to meet the customers? I’m sure a lot of good would come from it. I know a lot of LabVIEW applications would become a lot easier to understand if this could happen.

 

This entry was posted in Coding, Electronics, Tools and tagged , . Bookmark the permalink.

2 Responses to Thoughts on LabVIEW

  1. Grant Heimbach says:

    For every task there is a proper tool. The great thing about LabVIEW is that you can use other tools that have different strengths inline with your LabVIEW code.

    If you would rather type out your math formula, then try the Formula Node. If you already have a huge .m algorithm and don’t want to refactor it, then use the MathScript Node. Want to type (not call built libraries) in C? Try the Inline C Node. All of these things can be used in combination with LabVIEW’s graphical techniques and engineering analysis libraries to make it easier and better. LabVIEW doesn’t close out other approaches to programming but actually embraces them because each one has their own strength and engineers and scientists are better when they use them properly.

    As far as the “spaghetti code”, I have shown this slide many times to new LabVIEW developers to stress training and programming experience to master LabVIEW just like any other programming language.

    I have seen many text based applications that are just as complex as the Block Diagram you are showing but the complexity is hidden. It’s not till you start reading the lines of text do you really see how interwoven and dependent the code is. LabVIEW just makes it easier to see the complexity of an application. The scary thing about the “spaghetti code” you are showing? It works!

    I love LabVIEW and its graphical nature. I would never switch back to text based development only. Especially with the new tablet form factors trending up and touch screens. I don’t want to be using a virtual keyboard to develop with. Talk about lame.

    I agree that this Block Diagram makes you want to hurl but so would some of the text based applications you’ve seen if you tracked their dependencies and execution flow.

    LabVIEW can be a powerful tool when treated like any other programming language that requires training and experience to properly master. You can have quick turn around applications that look like this and work, you can also have students and my 8 year old niece understand it and use it, and you can also have trained programmers use it for the next generation of spaceflight.

Leave a Reply