1.3 The Soap Box | A Software Engineering Approach to LabVIEW

What is wrong with the way LabVIEW code is written? Why is there so little material on how to use proper software engineering techniques with LabVIEW? The answers, we think, are in the way LabVIEW is portrayed. We have often complained to all those who would listen that the marketing of LabVIEW is a huge millstone. In our opinion, LabVIEW is an extremely feature-rich, mature, and robust software development environment. Unfortunately, LabVIEW is portrayed, and regarded, as an easy tool for those wishing to write applications but who have little or no software engineering or programming experience.

It is true that easy things are easy to do in LabVIEW, as indeed they are in many other comparable languages such as Visual Basic. But, go beyond a quick data acquisition (DAQ) application and often chaos ensues. Why? Because a large majority of the LabVIEW community have little or no experience in software engineering or programming. The result is amateurish applications at best. Why anybody thinks that someone with no experience can create an application in LabVIEW is beyond us. To us it's akin to giving someone with absolutely no building experience all the latest power tools and asking them to build a house. Surely it's easy with all those tools, isn't it? No, it's not!

So, here it comes, guess what? Writing software is not easy. Another metaphor we like to use is tiling a bathroom wall. If all you have to do is place one single tile on the wall, the job seems relatively simple. Okay, you still have to get the tile on the wall straight and put enough adhesive on the wall for it to stay up, but all in all quite simple. However, if you were to put up five tiles things can get a little trickier. A slight error has a compound effect on the other four tiles; you have to start considering the gaps between the tiles; you have to also ensure that every tile is square with its neighbors; and the wall may not be even so you will have to pad out some tiles with adhesive . Still it is only five tiles, so it won't be that noticeable. However, if the wall consists of 500 tiles and the first tile is one degree off center, then the 500th tile will be miles off. It should also be clear from this metaphor that the bigger the job, the more considerations come into play.

What this illustrates is why small jobs are easier than large jobs, because any errors made at the start are amplified if not spotted straight away. For instance, an ATE is going to be based around an oscilloscope connected via a General Purpose Interface Bus (GPIB). Rather than use one common interface, all the commands to the oscilloscope are scattered throughout the four corners of the application, and anytime the oscilloscope needs to be communicated with a bit of G is slapped in. Now, we get to the end of development and a fundamental flaw in the frequency of a measurement comes to light. This frequency has to change from a range of 100 Hz to 1,000 Hz to a new range of 10 Hz to 2,000 Hz. If the scope had been in a single component with a common set of interfaces then the change would be simple. However, because the software in this case wasn't written with this in mind, all the code that talks to the scope now has to be hunted down and modified. In a small application this may only be a few instances; in a large application this could be thousands.

This example is very simplistic, but it actually happened on a project one of the authors (Jon) was involved in. For months after the modification it was found that some measurements were being taken over the wrong frequency span because another call to the scope had been missed. Think what it would have been like if another change had to be made, and then another. If the whole ATE had been written with little attention to a good design, then each attempted change would manifest itself into more errors ”chaos. Sound familiar? To a greater or lesser extent this problem is common in a lot of projects, and is a fundamental cause why systems can be flaky and hard to maintain.

So, what is the cure? The strange thing about this question is the simplicity of the answer. A complete understanding of the problem domain, a good design, and well- constructed software will ensure a robust, easy to update, and maintainable application. All things considered , it will also enable the application to be delivered on time and hopefully exceed the expectations of the user or customer.

Top