Although NI LabVIEW software has long helped engineers and scientists to quickly develop functional measurement and control applications, not all new users follow LabVIEW programming best practices. LabVIEW graphical programming is relatively unique in that a lack of adherence to coding best practices is quickly evident with a glance at a user’s application. Some users make these mistakes because they truly don’t understand the rules behind the flow of data on a LabVIEW diagram, while others are just unaware of features designed to improve the quality of a LabVIEW program.
#1: Overusing Sequence Structures
Many new LabVIEW programmers do 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.
Dataflow programming means that a node on the block diagram (subVI, primitive, structure, and so on) won’t execute until all the needed data inputs are present. This benefits LabVIEW programmers because independent processes are natively set up to run in parallel, while imperative languages require extra setup for parallel execution. As computers continue to add more CPUs, LabVIEW automatically offloads parallel processes and gains code performance without any extra coding by its users. Forcing execution on the block diagram by overusing flat sequence structures can constrict parallelization and take away this benefit. Limiting unnecessary structures on the block diagram helps with overall readability and keeps diagrams smaller as well.
Error wires are a good way to force data flow on the block diagram, rather than relying on flat sequence structures, and they also benefit an error-handling strategy.
When Should I Use a Flat Sequence Structure?
Forcing execution with a flat sequence structure is useful for benchmarking code performance. By using a flat sequence structure with a tick count inside its frame, you can determine the time it took to execute code in between two tick counts. This cannot be achieved through normal dataflow execution.
For more information on dataflow programming, access the self-paced online training (ni.com/self-paced-training) for LabVIEW Core 1 on data flow. Self-paced online training is free with every LabVIEW purchase or for users currently on the Standard Service Program (ni.com/ssp).
Curious about the other 4 rookie mistakes? Read the full article on the NI Developer Zone.
_ _ _
This week's article was contributed by LabVIEW Product Marketing Manager Grant Heimbach.