Clever Debugging Techniques for Every LabVIEW Developer

Publish Date: Aug 21, 2017 | 15 Ratings | 4.53 out of 5 | Print | 4 Customer Reviews | Submit your review

Table of Contents

  1. Be a LabVIEW Bug Assassin
  2. Probes Revisited
  3. Suspend When Called 
  4. Unwired Front Panel Controls and Indicators
  5. Execution Tracing
  6. Unit Testing
  7. Do You Have Something to Add?

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.

:source images:brian-searle-3122477836_54e09dde68_b.jpg

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.

Back to Top

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.

:source images:retain-wire-values-cropped.png

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.

:source images:custom-probe-history.png

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.

:source images:vibox-lvtn-cropped.png

Figure 4. Use VIPM to install SAPHIR's custom probes.

Back to Top

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:

  1. Arbitrarily change the control values of a VI before it runs.
  2. Arbitrarily change the indicator values a VI returns to its caller.
  3. Run a VI over and over without returning execution to the caller.
  4. Skip execution of a VI entirely and return to the calling VI.

:source images:suspend-when-called-edited.png

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.

Back to Top

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.

To learn more about Ben’s debugging subVIs, read his post on

Back to Top

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.

:source images:highlight-execution-cropped.png


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.

:source images:geek_and_poke_step_over.jpg

Figure 7. The Perils of Manual Execution Tracing (courtesy of Oliver Widder)

Professional LabVIEW developers can celebrate, because the LabVIEW Desktop Execution Trace Toolkit is now included at no extra cost with NI Developer Suite 2011.

Back to Top

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.

:source images:i-dont-always-test-my-code.jpg

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:

  1. The unit test provides traceability to demonstrate exactly how the bug occurred and how you isolated it.
  2. 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.
  3. 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.

Back to Top

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.

Do you have a tip or trick that makes your coworkers say, “How’d you do that?” Tell us on Twitter (@jkisoftware), post it on our Facebook page, or come to the JKI Forums and share it!

Omar Mussa is a CLA and JKI’s professional services manager. He is passionate about object-oriented programming and test-driven development, and was using Suspend When Called before it was cool.

Justin Goeres is a CLA and JKI’s product marketing manager. Even after using LabVIEW for 14 years, he loves to learn something new every day about how other software developers see the world.

Back to Top

Customer Reviews
4 Reviews | Submit your review

Custom Probe Waveform Chart not available on a RT target  - Jul 4, 2014

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

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

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

View more reviews

Bookmark & Share


Rate this document

Answered Your Question?
Yes No