Since I started using LabVIEW, I have made a lot of mistakes. I sometimes wince when I look at my early code. While most of the code works, it is often an unreadable mess. Since then, I have learned a lot of good techniques to improve the organization of my code.This article reviews the four mistakes that I personally made the most while I was starting with LabVIEW. For a more extensive list of common mistakes made in LabVIEW, please follow this link.
1. No Error Handling
If an error occurs, the code comes to a screeching halt and gives a cryptic error, leaving the operator scratching a confused head. LabVIEW can fly a plane or lead a rover across Mars, but not if you’re using Automatic Error Handling. The error cluster is easy to use! We can gracefully exit, fix, or prevent erroring applications from being a problem. The following VI snippet shows an example of an error handler structure.
2. Overusing Flat Sequence Structures
This is a mistake I personally made a lot when I first started using LabVIEW. It was because I did not fully understand the concepts behind “dataflow” execution, which is fundamental to LabVIEW programming. One indication of this is that users often overuse the flat sequence structure on their block diagrams. Users often rely on flat sequence structures to force the serial execution of code on the block diagram, instead of using the flow of data with wires between nodes. If you want to learn more about data flow in LabVIEW so you can better understand when you should and shouldn’t use flat sequence structures, check out this link.
3. Misusing Local Variables
Another common mistake in LabVIEW programs is an overuse of local variables. Local variables are a piece of shared memory used to pass data between different sections of a computer program. Commonly used in text-based languages, variables can be very empowering, but can also lead to problems when a race condition is encountered.
Unlike other programming languages where passing data through variables is essential, LabVIEW provides the dataflow method of moving data from one part of a program to another. The parallelism inherent to LabVIEW makes overusing variables problematic because shared memory is often accessed by different code locations at the same time. If this happens, one read/write operation wins the “race” and the other loses. The losing data operation is forgotten, so overusing variables in LabVIEW can ultimately lead to lost data.
4. Disregarding the Need for Documentation
Trying to discern what a program that is written by someone else does can be helped greatly by good code documentation. Unfortunately, documentation is normally left until the end of the development cycle, after the functionality is complete. This leaves little time to document code properly, and trying to understand poorly documented code can be a nightmare. Instead, time should be carved out during development to start the documentation process. I have found that making personal notes on my code as I go helps a lot too. You would be surprised how much you can forget after a few days of not looking at your code.
Thank you for reading my blog post, and for more information about common mistakes in LabVIEW, follow this link. If you are interested in trying out LabVIEW for yourself, you can purchase a copy of LabVIEW 2014 Home Edition which includes everything you will need to run LINX 3.0. Please comment below with any questions or comments you may have.
As a contractor I get the honor of trying to unscramble other people’s programs. My current project is a mix of incredible front panel control and horrible, resource hogging spaghetti code attempting to communicate with and control the customer’s product.