Top 5 LabVIEW Rookie Mistakes

Publish Date: Nov 03, 2014 | 88 Ratings | 4.84 out of 5 | Print | 14 Customer Reviews | Submit your review

Table of Contents

  1. Overusing Flat Sequence Structures 
  2. Misusing Local Variables
  3. Ignoring Code Modularity
  4. Creating Massive Block Diagrams
  5. Disregarding the Need for Documentation

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.

This article reviews the most common programming mistakes made by inexperienced LabVIEW programmers, along with recommendations on the correct LabVIEW programming approach to use instead.


Figure 1. Code full of LabVIEW “rookie” mistakes

1. Overusing Flat 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.

Figure 2. Users often rely on flat sequence structures rather than developing a full understanding of dataflow programming concepts.

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.

Figure 3. Using flat sequence structures and tick count VIs is useful for benchmarking code.

For more information on dataflow programming, access the self-paced online 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 (


Read more about LabVIEW Rookie Mistake No. 1.


Back to Top

2. 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.

You can safely pass data from one part of a LabVIEW program to another using a variety of methods, including wires, queues, events, notifiers, functional global variables, and more. These mechanisms are each designed for a specific use case, but all have the advantage of eliminating race conditions.

For more information on proper techniques for moving data within a LabVIEW program, access the self-paced online training ( for LabVIEW Core 1 on Local Variables and LabVIEW Core 2 on Notifiers, Queues, and Events.


Read more about LabVIEW Rookie Mistake No. 2.


Back to Top

3. Ignoring Code Modularity

Often, new LabVIEW users create “fire and forget” applications to accomplish simple tasks and don’t think about how they can use that code in the future. As users start to program more often, they can find themselves rewriting the same piece of code over and over again. You can save yourself a lot of development time by creating modular subVIs out of portions of your code that can be reused within other applications.

If you know that a particular part of code will be reused again within the same application, or have a hunch that it might be reused in a future application, then take the extra time to turn it into a subVI. To prepare a portion of code to be a subVI, the main things that you need to do are add documentation, use the connector pane, and disable some VI properties. One of the easiest ways to start creating a subVI is by highlighting a portion of code on a block diagram and then selecting Edit>>Create SubVI from the menu bar. This scripts the process of putting that portion of code into a separate VI and using the connector pane. You will still need to edit the icon to something that makes sense, add documentation to the block diagram and VI Properties, and turn off some VI settings, but Edit>>Create SubVI is a great starting point to code modularity.

Figure 4. You can save yourself a lot of development time by instituting proper LabVIEW code modularity practices.

The one VI setting that you should make sure to turn off when preparing code for reuse is Allow Debugging. This option is found within the VI Properties (File>>VI Properties) under the Execution category. After your code is completely functional and no longer needs debugging capabilities, like Highlight Execution, turn off Allow Debugging in the execution settings and run your VI again. This is beneficial because more optimizations take place during the compilation process so your application may run faster and the VI will have a marginally smaller physical size on disk because the extra code that enables debugging is taken out.

For more information on code modularity, access the self-paced online training ( for LabVIEW Core 1 on Understanding Modularity.


Read more about LabVIEW Rookie Mistake No. 3.


Back to Top

4. Creating Massive Block Diagrams

Many new LabVIEW users have block diagrams that can become huge. Some applications are complex and you can’t avoid having a large diagram, but it also can indicate lack of a programming architecture. Without an underlying architecture, it’s difficult to maintain a program over time and it can be costly to add new functionality later. Just like constructing a proper frame builds a structurally sound house, a good programming architecture provides a safe and secure framework to build your application from.

Software architectures are common frameworks that almost all programmers find useful. Many of the architectures within LabVIEW, such as producer/consumer and state machines, are similar to those found in other programming languages.

Understanding LabVIEW architectures reduces development time and improves application scalability. LabVIEW 2012 made understanding architectures even easier by including templates and sample projects in the release. Templates explain different architectures and when they should be used. Sample projects are larger applications built on top of the templates and demonstrate how templates can be used to meet real-world challenges. You can plug hardware into a sample project and use it as a turnkey application if needed, but it’s still open and well-documented so you can customize it for your specific application.

Figure 5. Templates and sample projects available in LabVIEW 2012 make understanding software architectures easier than ever.

For more information on LabVIEW architectures, access the self-paced online training ( for LabVIEW Core 2 on Design Patterns.


Read more about LabVIEW Rookie Mistake No. 4.


Back to Top

5. Disregarding the Need for Documentation

Trying to discern what a program written by someone else does is 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. Instead, time should be carved out during development to start the documentation process. Documentation greatly benefits the person who wrote the code when they revisit it later and can’t remember what mindset they were in when choosing certain code aspects. Coffee and late night programming, a common trait in programmers, can lead, jokingly, to temporary memory loss. Documentation can help programmers get those memories back.

In general, the graphical nature of LabVIEW makes reading code easier than text-based programs, but good documentation can reduce the time needed to “decode” a program even more. The easiest way to add documentation to your block diagram is by using free labels. You can add these by double-left clicking in an empty space on the block diagram and entering some text. Then use an arrow decoration to point to the specific code referenced by the free label. Add pictures by copying them onto the clipboard and pasting them onto the block diagram. Images of physical systems or math formulas can help users formulate code context within the block diagram.

Figure 6. Properly architected and documented code helps others using your code, but also helps you better understand your own code.

Documenting code is not just for reuse libraries, it should be done for every program. Humans learn a lot more about a subject when forced to teach it to others. Writing documentation essentially forces this teaching process and can help programmers understand their own code better.

For more information on code documentation, access the self-paced online training for LabVIEW Core 1 on Documenting Code.


Read more about LabVIEW Rookie Mistake No. 5.


LabVIEW was built to make engineers and scientists more successful at tackling the world’s tough challenges. The benefit of having a large programming community of engineers and scientists is that they like to share their knowledge with others. If you have your own LabVIEW rookie mistake that you would like to share, please add your voice by visiting

For a more in-depth look at each of these LabVIEW rookie mistakes in future articles, stay tuned to NI News.

Back to Top

Customer Reviews
14 Reviews | Submit your review

performance issues should be discussed better!  - Jul 7, 2016

It is easy to criticize a large diagram or flat sequence over usage but for some people it might a convenient way to work. Our brains do not percept visual information in the same way and that's what making us unique and different from each other ;-) Many LV projects are small "a single author creations" and there might be no need to correct any of the mentioned mistakes. Moreover, in high performance applications involving high data-flow rate the suggested multi-VIs structure is very questionable. The queues (and some other elements) in LV are very useful, however, there are serious issues (bugs and poor implementation inside LV) with performance in LV and maybe that's why some people prefer to use local variables instead for example? In summary, this is a good article but please do not take it very serious because when you will deepen into the LV world trying to tackle performance issues then many of these "Rookie Mistakes" will be "The Only Way It Works". The authors should spend a paragraph (or perhaps link to another article) discussing the high performance applications because there the rookie rules might differ from a nice-looking diagram.

Stick to dataflow as much as possible.  - Mar 21, 2016

Rookie mistake #6? Not reading the docs. There is another comment here giving bad advice and saying not to wire error wires to the TCP Close Connection VI (in his example). His statement is incorrect and in fact most "cleanup" VIs in LabVIEW will run anyway if an error is passed in. When looking in the help for this and many other VIs with similar behavior (Close Reference) the error in terminal description will state whether or not the vi follows standard error behavior and will describe the exceptions to the behavior.

Using error wiring can be troublesome   - Oct 13, 2015

Perhaps I'm wrong about this when it comes to NI generated code, but in my experience using error wiring can cause undesirable results and care should be taken. Consider opening a TCP connection, performing a failed write, and then closing the connection, with all error ins and outs between Open, Write,and Close VIs connected. The Close vi will not close the connection due to the error condition from the write vi,yet style wise the code looks perfect. In my experience a vi which closes a connection, destroys an object, image, etc, should never have error inputs wired. This can be particularly problematic when using third party code, eg,SDK produced in an MS visual language and "wrapped" for Labview. I humbly confess that I do use sequence structures and in the last frame do the housekeeping, ie, close or destroy all objects, etc. This learned from bitter experience.

Write easy to understand code..Not comments  - Dec 8, 2014

I'll be a little bit controversial about comments in that I agree with the following quote "Every comment is a lie waiting to happen...". The point being that the only thing guaranteed is the code, and comments will need maintaining. A better approach surely is to write simple, clean and tidy code, employing all of LabVIEWs great readability features, confining comments only to areas that really need clarification. Valuable article Grant!

Requirement and Specification and Pseudo-Code  - Dec 2, 2014

All the points are good advice but I would add that before any lines are drawn on the block diagram that the Requirements (what it has to do, at what rate, and so on)and Specifications (in what manner, with what kind of equipment, what operating system, and so one) should be determined and written first. They do not need to be written a formal documents (but they often are) but it help the programmer think about what functions the program should perform and how it should do them. From experience, defining and discussing the Requirements and Specifications with my lead programmer (or by myself for that matter :-)) has always been worth the time and effort, no matter how pressed for time we were. It is often a iterative process where the the Requirements and Specifications often evolves as the project progresses and there is a better understanding of the issues, problems and challenges to the program/system. The use of pseudo-code can also be very helpful prior to any real programming because it helps in determining what type of code structure/design is appropriate. (The use of pseudo-code would make for an interesting article.)

Number 5 should be number 1.   - Oct 7, 2014

Or perhaps every other number. I suffer from inadequate documenting, usually due to time constraints. You need to force yourself to do it. IT helps significantly later on if you or someone else needs to understand your code.

More detail to the article  - Mar 5, 2014

Will you be adding more details soon?

  - Jan 11, 2014

This is my favorite part "Humans learn a lot more about a subject when forced to teach it to others. Writing documentation essentially forces this teaching process and can help programmers understand their own code better."

  - Sep 17, 2013

I think when moving from CLAD to CLD ,these are the few areas where you Score

More to come  - Apr 4, 2013

I'm going to be diving deep on each of these topics over the coming months. There wasn't enough space in one article to cover every caveat and best practice. Stay tuned to NI News for the future articles!

Well written article  - Apr 3, 2013

Thanks for a good programming article. So many articles are just marketing, although I realize that is necessary too. It might have meritted a comment that the flat sequence structure in figure 2 could be eliminated without having to make any changes. Looks like a silly example, but we've all done it (used a sequence when not necessary). Mentioning the tick counts was a nice alternative to the usual "never use this feature" admonition. Lastly, it would have been interesting to have seen at least one screenshot of a re-structure of the mess in figure 1.

doesn't the last picture show everything GOOD that the article was talking about?  - Apr 2, 2013

  - Apr 2, 2013

That first picture is EPIC. Is that somebody's actual code?

Wheres the rest?  - Apr 2, 2013

there were samples of what not to do, but would have like to have seen the preferred method documented as well

View more reviews

Bookmark & Share


Rate this document

Answered Your Question?
Yes No