Table of Contents

1. Be a LabVIEW Bug Assassin

If you use NI LabVIEW software regularly, you probably have a personal toolbox of debugging tricks and techniques for when your software doesn’t do what you intended. Some of these are common, like Probes and Breakpoints, while others are probably personal things you’ve created or figured out on your own.

Figure 1. Good debugging kills bugs dead. (photo by Brian Searle)

We talked to JKI’s Certified LabVIEW Architects (CLAs) as well as our friends around the LabVIEW community to learn some of their “super-secret” tricks for identifying, isolating, and fixing bugs fast. We came away with the following handful of clever debugging techniques for every LabVIEW developer.

2. Probes Revisited

Probes are the first and simplest tools for LabVIEW debugging, but they’re deceptively powerful. With almost no extra effort, you can move beyond simply hanging a probe on a wire and increase the amount of information available as you track down problems. Here’s how.

Retain Wire Values

Retain Wire Values is an often-overlooked feature of the LabVIEW development environment. When you enable Retain Wire Values for a VI, LabVIEW automatically stores the last value of every wire on the VI’s block diagram. Then, you can hover over any wire and the probe tool will display a tooltip of that wire’s last value, even if the VI is no longer running.

Figure 2. Retain Wire Values is next to the famous light bulb.

Create Custom Probes Without Writing Any Code

You can use LabVIEW Custom Probes to create powerful and complex debugging tools, but you can also use them without writing any code at all. For example, you can make an easy “history probe” that displays the previous values of any numeric wire using Custom Probe >> Controls >> Waveform Chart. This can help you uncover patterns or trends in data you’re probing without writing special probe code yourself.

Figure 3. Use a Waveform Chart probe to show historical values of a simple numeric.

Custom Probes From the LabVIEW Tools Network

Expand your toolbox by reusing probes created by other people. SAPHIR offers a free set of custom LabVIEW probes on the LabVIEW Tools Network.

Just download and install VI Package Manager (VIPM) Community Edition (also free), search for ViBox, and install them in a couple clicks. If you’re using LabVIEW 2011, you can also get ViBox from the LabVIEW Tools Network by clicking Find LabVIEW Add-ons… in the LabVIEW Getting Started window.

3. Suspend When Called

Many CLAs don’t know this LabVIEW feature exists. Once they see it, they’re amazed at how powerful it can be.

In a few words, Suspend When Called suspends execution and lets a developer do any or all of the following:

Arbitrarily change the control values of a VI before it runs.

Arbitrarily change the indicator values a VI returns to its caller.

Run a VI over and over without returning execution to the caller.

Skip execution of a VI entirely and return to the calling VI.

Figure 5. SubVI node setup: Suspend When Called

National Instruments has a brief document on Suspend When Called here, and Sixclear offers an introductory video on their blog. The best way to get acquainted with this feature, however, is to just try it yourself.

4. Unwired Front Panel Controls and Indicators

Ben Zimmer of Enable Training and Consulting, Inc. recommends a technique for FIRST (For Inspiration and Recognition of Science and Technology) Robotics Competition teams, but it’s useful for professional LabVIEW developers, too.

Ben suggests adding front panel controls or indicators to a VI but not wiring them to its connector pane. These controls and indicators function like “debug” inputs or outputs that you can manually manipulate during testing. They make it easy to generate rare occurrences or corner cases in your application without writing a lot of support or simulation code.

You can even use these debug controls and indicators in built applications, as long as you make sure the Application Builder doesn’t strip the VI’s front panel.

5. Execution Tracing

When all else fails, like when a bug is dependent on a race condition or when it crashes LabVIEW, sometimes all you can do is trace your code step by step. When you’re faced with this kind of problem, there are several ways to trace execution in LabVIEW.

The most obvious is the built-in Execution Highlighting in LabVIEW, otherwise known as “the light bulb.” If Probes are the first tool of LabVIEW debugging, the light bulb is the second. For complicated or timing-dependent bugs, however, there are better tools.

Figure 6. There’s more to execution tracing than the light bulb.

Tracing to Disk or Memory

A simple way to begin tracing execution is to log the value of a wire in one of your subVIs. You can write a simple VI to log the value to a file, or even create a Custom Probe to display the wire’s historical values. Frequently, a simple trace such as this will gather enough information to lead you to the cause of a bug.

Desktop Execution Trace Toolkit

If you are debugging a large, highly parallel application, the LabVIEW Desktop Execution Trace Toolkit is the “big gun” of LabVIEW code analysis. It provides a wealth of information about your running application, including detailed memory allocations and deallocations, event generation, and custom information defined by your code. Fabiola De la Cueva, cofounder of the Austin LabVIEW Architects Forum, also points out that the toolkit is critical for debugging an application that crashes, because it runs outside LabVIEW.

6. Unit Testing

Test-driven development (TDD) is a software engineering technique that helps you create better code from scratch, but it's also a great tool to help you debug existing code.

In TDD, when you find a bug in your application, the first step of the debugging process is to create a unit test that reproduces the bug and results in a test failure. Only then do you begin actually trying to fix the problem. When your unit test passes, you know you’ve eliminated the bug.

Figure 8. Where do you test your code?

This approach to bug fixing takes a little more time at first, but it offers several advantages over other, less rigorous approaches:

The unit test provides traceability to demonstrate exactly how the bug occurred and how you isolated it.

You or other developers can easily verify or re-verify your fix at any time without remembering the details of how to trigger the bug.

The unit test can be executed automatically with all the other tests in your project, so that if the bug ever recurs you’ll know immediately.

There are two main LabVIEW add-ons for unit testing, and you can implement this kind of TDD approach with either one. See JKI’s free VI Tester LabVIEW add-on, or refer to Eli Kerry’s Software Engineering in LabVIEW tutorials to learn about the LabVIEW Unit Test Framework Toolkit, which is included in NI Developer Suite at no extra cost.

7. Do You Have Something to Add?

Whether you’re a seasoned CLA or a brash young Certified LabVIEW Associate Developer, you can always learn new techniques to more quickly identify, isolate, and fix bugs in your code (and others’ code, too). So now, we want to hear from you.

The Custom Probe Waveform Chart is very nice for aquiring history of data however, it does not work on a RT target.
You'd need debugging code to transfer the data to the host.

Express Tracing to Disk or Memory
- Nov 17, 2011

By Kelvin Tang, National Instruments.

User can use the auto indexing feature in a
loop structure to push their data during
execution into an array of 1 or more
dimensions, an express way to log data in the
same VI.

Another Debug/Logging Option
- Nov 15, 2011

By Jody Koplo, DMC.

Here at DMC we've recently implemented
a Logging utility that is heavily based on
the NLOG project.
It's similar to the Desktop Execution
Trace toolkit, but less focused on
memory and performance and more focused on tracing code execution. It has
the added benefits of being easy to use,
asynchronous, and run-time compatible
(and configurable).
I recently published a blog that goes into
more of the details. Check it out here:
http://www.dmcinfo.com/Blog/articleType/
ArticleView/articleId/807/NLog-for-
LabVIEW-Logging-done-properly.aspx
-Jody Koplo

Advanced tab: enable debugging
- Nov 15, 2011

After an EXE is built and deployed, it can
be hard to debug for errors that never
occured in the development
environment, especially if you're running
on a machine that doesn't have a full LV
environment on it. To help with this, you
can choose 'Enable Debugging' on the
Advanced tab to have all the front panels
load in memory. Then hide a Ring
control with the sorted names from 'App:
All VI's in memory' on your main front
panel. Put an event case for the Ring:
Value change that calls an Open VI
reference off the RingText.Text and wire
its reference to an FP.Open Invoke node
call and you can see your subvi's front
panels, which is often very helpful in
isolating a bug.