National Instruments’ LabVIEW graphical development environment for measurement and control shares two distinctions with the Broadway play “The Phantom of the Opera”: One, both have been boffo hits for more than a couple of decades now and show no signs of slowing down. LabVIEW, however, has evolved while the book on “The Phantom” is set. Twenty years from now the only thing that will have changed with “The Phantom” is the cast. It’s a sure bet that in 20 years LabVIEW will have advanced with technology again and time again, remaining the go-to environment for whatever measurement and control applications are on the leading edge.
The second distinction that “The Phantom” and NI LabVIEW have in common is that both have had such a long, successful run of it that a whole new generation is just now getting to know them. LabVIEW was first released for the Apple Macintosh in 1986 — two years before “The Phantom” and the new hire working next to you made their debuts. That means more than just you’re getting up there, pal. It means that the kid, no matter how much LabVIEW training, has none of your scars from experience. Today’s Check it Out link offers a little extra LabVIEW training for them. And for you because, face it, some of you old pros missed a thing or two over the years, and the older you get, the more bad habits you come up with.
The “Top 5 LabVIEW Rookie Mistakes” is a web page that, it appears, was developed for one of NI’s newsletters you can subscribe to. There’s no PDF to download, but there are buttons to bookmark it or to share its link through social media. Each discussion has a click-to-enlarge image so that you can see exactly what the author is trying to get across, and each discussion concludes with a link to a self-paced online tutorial on the subject at hand.
The raison d’être for this “web-paper” is to pass on to you some LabVIEW programming best practices, so it really does not matter if you’re making mistakes because you’re a newbie, you don’t get something or you missed that rule along the way. The top five mistakes are:
1. Overusing Flat Sequence Structures
2. Misusing Local Variables
3. Ignoring Code Modularity
4. Creating Massive Block Diagrams
5. Disregarding the Need for Documentation.
Here are thumbnails of each.
Overusing Flat Sequence Structures looks at the concepts that underlie dataflow execution. The specific problem is an overreliance on flat sequence structures to force the serial execution of code on a block diagram. LabVIEW sets up independent processes to run in parallel natively. Serial execution of code loses you the benefits of parallelization. NI explains what to do to avoid that conflict.
Misusing Local Variables explains how an overuse of local variables can lead to lost data and what you can do to prevent that from happening. Ignoring Code Modularity is all about code reuse. It tells you how to take portions of your code and make small modular sections of codes (subVIs) that you can reuse in other applications.
Complex applications will always result in humongous block diagrams. The Creating Massive Block Diagrams discussion, however, is for those LabVIEW users who seem to build huge block diagrams for the simplest of jobs. The culprit here is often a poorly implemented underlying program architecture. This section looks at the templates introduced in LabVIEW a couple of versions back, how they describe different architectures and when you should use them.
Disregarding the Need for Documentation. … You’ve been there and done that. Trying to figure out what somebody, including yourself, was doing when they wrote a program is maddening. This section has a bunch of tips and tricks that LabVIEW can do that can make your documentation understandable by mere mortals.
A lot more is going on in each of the segments than these quick sketches indicate, and everyone reading the web-paper should benefit by learning a little something that they just didn’t know. Hit today’s Check it Out link and spend a few minutes going over the best practices offered in the “Top 5 LabVIEW Rookie Mistakes.” You don’t have to admit to anybody that you didn’t know this or that. But when somebody notices that the quality of your NI LabVIEW code has improved, just say a phantom programmer did it.
Thanks, Pal. – Lockwood
Anthony J. Lockwood
Editor at Large, Desktop Engineering