LabVIEW Programming

Patterns and Frameworks

Objective: Introduce LabVIEW programming patterns and
frameworks 

A. Introduction to LabVIEW Design Patterns and Frameworks

B. Error Generation and Propagation Best Practices
C. Code Smells

Darren Nattinger, CLA

Principal Technical Support Engineer, NI
Before we get started…

This presentation is part of my LabVIEW Troubleshooting series:

bit.ly/dnattlvtroubleshooting
• Link to video recordings on YouTube
• Link to download slides and demos
• Slides contain links to additional resources
• Links to other presentations in the series

ni.com
Introduction to LabVIEW Design Patterns
and Frameworks

Some of the content in this section was borrowed from a design patterns presentation by
Andreas Kreiseder
ni.com
LabVIEW Design Patterns and Frameworks

What do Design Patterns have to do with troubleshooting?

• LabVIEW programmers often have to look at code written by others
• It is helpful to be able to open code and immediately know what
pattern/framework was used…
• …or if no framework was used at all!
• For established frameworks, you can start off assuming that basic
operations are being handled properly
• Module start, module stop, communication between modules,
panel display, error reporting, etc.
• And if basic operations are *not* happening properly, it’s more likely
the fault of the developer and not of the framework.
• For code written without an established framework, all bets are off.
LabVIEW Design Patterns and Frameworks

LabVIEW Design Patterns

What is a Design Pattern?

Definition: A general, reusable solution to a common software design problem.

Why Should I Use One?

No need to reinvent the wheel when it comes to accomplishing common
programming tasks.
LabVIEW Design Patterns and Frameworks

LabVIEW Design Patterns

How are LabVIEW design patterns related to
patterns in other languages?
The “Gang of Four” book is the most well-known resource for
(general) design pattern information.

Blog post on the relationship between Gang of Four patterns

and LabVIEW patterns:
https://www.sasworkshops.com/gang-of-four-patterns-in-labview/
LabVIEW Design Patterns and Frameworks

State Machine
Execute a sequence of events. The order is determined programmatically,
which means code can be skipped or executed multiple times in a row.
LabVIEW Design Patterns and Frameworks

Event-Based State Machine

Available as a project template: File > Create Project > Simple State Machine
LabVIEW Design Patterns and Frameworks

Producer / Consumer

In this pattern, one loop generates data that is consumed by another loop. The
communication mechanism between loops is usually a queue.

This pattern requires that the consumer process the data faster than the
producer generates it. Otherwise the queue grows without bound, or the
producer loop gets throttled by a maximum queue size.

The most common producer/consumer involves a producer loop that is

registered for events on the user interface, and data is sent to the consumer
loop when those events fire.
LabVIEW Design Patterns and Frameworks

Producer / Consumer
LabVIEW Design Patterns and Frameworks

LabVIEW Frameworks

What is a Framework?
Definition: A starting point for an application. Based on one or more design
patterns, and usually including tooling to improve developer experience.

Why Should I Use One?

Already solves all the issues and corner cases you’d have to identify yourself
if you started from scratch. Often provides tooling to automate tedious tasks
related to the framework.
LabVIEW Design Patterns and Frameworks

Popular LabVIEW Frameworks

• NI Queued Message Handler (ships with LabVIEW)
• Actor Framework (ships with LabVIEW)
• Delacor Queued Message Handler (DQMH) (third-party)
• JKI State Machine Objects (SMO) (third-party)
• Messenger Library (third-party)
• Top-Level Baseline Prime (TLB’) (third-party)
Demo
Browse AF and DQMH Project Templates
and Shipping Examples
LabVIEW Design Patterns and Frameworks

Watch out for design pattern misuse!

• State Machine
• Not designed for parallel loop execution
• NI QMH
• Not designed for dynamic instantiation of parallel loops
• DQMH
• Use Helper Loops instead of cramming state machine-like behavior in
the Message Handling Loop
• All of the above (Actor Framework, DQMH, NI QMH, etc.)
• Stuffing multiple modules’ worth of responsibility in a single module
LabVIEW Design Patterns and Frameworks

Is there a design diagram of the project?

Design diagram of the NI Continuous Measurement and Logging sample project

(based on the NI QMH)
LabVIEW Design Patterns and Frameworks

Tool for project design documentation

AntiDoc by Wovalab:
https://www.vipm.io/package/wovalab_lib_antidoc/
LabVIEW Design Patterns and Frameworks

Getting Started with Frameworks

• NI QMH – QMH Project Template Documentation
• Actor Framework – LabVIEW Actor Framework Basics
• DQMH – How to Learn DQMH
• JKI SMO – Intro to JKI SMO
• Messenger Library – Messenger Library on the LabVIEW Wiki
• TLB’ – TLB-Prime GitHub repo
Best Practices for Error Generation
and Propagation

What is “Error Handling”?

Error Generation
Error Propagation

original author: Darren Nattinger – http://bit.ly/dnatterrors

ni.com
Best Practices for Error Generation and Propagation

What is “Error Handling”?

There are FIVE distinct aspects of “error handling” in LabVIEW:

Error Generation
Error Propagation } The focus of this section

Error Response
Error Display
Error Logging
Best Practices for Error Generation and Propagation

Error Generation - the creation of an error value at the point that something
goes wrong in your LabVIEW code.

There are two ways errors are generated in LabVIEW:

1. Built-in Nodes
• Functions like File I/O, Queue, VISA, Property Node, etc.
• Call Library Nodes
2. G code that creates an error value
• Error Cluster from Error Code.vi (often used alongside Call Library Nodes)
• Error Ring

Don’t build the error cluster yourself!

Best Practices for Error Generation and Propagation

Error Propagation - the act of moving an error value through your LabVIEW code.
• There are many aspects to error propagation:
• Forking an error wire to parallel code paths
• Merging errors from parallel code paths
• Skipping execution of some nodes when an error occurs
• etc.
• There are many tools to facilitate error propagation:
• Case Structure
• Merge Errors function
• Shift registers
• etc.
•
But there is one overarching rule for error propagation…
Best Practices for Error Generation and Propagation in LabVIEW

Don’t break the error chain

• When a subVI or function generates an error, it has faith that the programmer
will shepherd that error to its final resting place
• General Error Handler.vi, error logging scheme, an error indicator on a front panel, etc.
• All it takes is one place in a VI hierarchy that breaks the error chain to cause
any node’s upstream error generation to be lost forever
• Or until your hours-long debugging session finds the place where the chain is broken
• There are several ways you can break the error chain in your LabVIEW code
Best Practices for Error Generation and Propagation in LabVIEW

Ways to Break the Error Chain

1. Neglecting to wire an error output that is part of the error chain

2. Zero-iteration For Loops

3. Sloppy Merge Errors Ordering

 Exercise

What if you want your loop iterations to run independently, regardless of error?
B. Best Practices for Error Generation and Propagation in LabVIEW

Ways to *Avoid* Breaking the Error Chain - Summary

• Run the Error Cluster Wired test in the VI Analyzer Toolkit
• Detects subVIs and functions with unwired error outputs
• Provides options to ignore certain objects
• Run the Unused Code test in the VI Analyzer Toolkit
• Detects unwired output tunnels of structures
• Run the For Loop Error Handling test in the VI Analyzer Toolkit 2018 or later
• Detects loop-related error propagation issues described earlier
• Detects Merge Errors ordering issues on loop error output tunnels
• Enable automatic error handling during development
• Assumes all error conditions are tested during development
• Requires tooling to enable/disable on an entire codebase
• Unless you’ve wired every error output by the time you’ve finished development
Best Practices for Error Generation and Propagation in LabVIEW

Summary on Error Generation and Propagation

• Make a conscious decision about every error wire you create (or don’t create)

• You should be able to look at a block diagram and know exactly how that diagram
will function with an error condition
• Patterns described in this presentation
• Good code documentation

• With auto error handling, there’s no way to know if the VI is going to pop up error
dialogs or not without viewing the VI Properties

• The error chain should be immediately obvious on every diagram

Code Smells
What is a code smell?
Common Code Smells
What can we do?
Demonstrations
Tools to Help Eradicate Code Smells

original author: Mark Ridgley

(https://
education.ni.com/center-of-excellence/resources/177/code-smells-part-1-basic-code-smell
s-from-the-real-world
ni.com
)
A. Code Smells

What is a code smell?

Definition

Code Smell – A symptom in the source code that possibly indicates a

deeper problem
A. Code Smells

Common Code Smells

 Poor naming  Breaking dataflow

 Overly complex  Outdated practices
 Contrived complexity  Too many parameters
(i.e. “cleverness”)  Excessive use of constants
 Too many modules  Cyclomatic complexity
 Duplicated code
 Disorganization
What can we do?

• Be vigilant – Code smells are all around us

• We just have to look for them
• Can be in any code (LabVIEW, TestStand, .NET, etc.)
• Don’t look the other way when you discover a code smell
• Take the initiative and time to refactor the code
• A common recommendation when troubleshooting smelly code
• If you don’t, who will?
Refactoring

Definition
Refactoring – The process of redesigning software to make it more
readable and maintainable so that the cost of change does not increase
over time

Usually does *not* involve adding new features, so it’s sometimes hard
to justify to managers.
Refactoring Poor Variable Naming
Excessively short names
Excessively long names

See the LabVIEW Style Checklist for file and parameter naming guidelines:
https://zone.ni.com/reference/en-XX/help/371361R-01/lvdevconcepts/checklist/
Refactoring Duplicated Code and/or Complex Code
Refactoring Unnecessary Complexity

Can you easily

determine the
functionality of
the code in the
while loop?
Refactoring Unnecessary File Propagation
Refactoring Spaghetti Code
Refactoring variable-heavy code
Refactoring Huge Connector Panes
Exercise
Cyclomatic Complexity

Function or method has too many branches or loops

Complicates testing and troubleshooting
Indicates that the code should be simplified
How to Reduce Code Complexity

• Remove decision points when possible

• i.e., Error case structure surrounding diagram contents
• Modularize complex code
• SubVIs can be more easily tested in isolation
• Reduce local/global variable usage
• Reduces chances of race conditions when data is passed by wire
• Replacing with functional globals doesn’t count!
• Use existing libraries instead of rolling your own
• Recognized icons/patterns
• Corner cases/bugs already addressed
• Code reviews with experienced developers help with this
Summary

• Become familiar with popular LabVIEW frameworks so you

recognize them in customer code

• Use tools to identify problematic error propagation

• Recognize code smells and suggest refactoring to eliminate them

before they turn into legitimate problems
Homework

• Download these slides at bit.ly/dnattlvtroubleshooting

• Read getting started materials on LabVIEW frameworks

• Start with AF and DQMH, then go from there

• Watch ‘What to Expect When You’re Expecting an Error’

• http://bit.ly/dnatterrors
Thanks for watching!