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
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.
Figure 4. Use VIPM to install SAPHIR's custom probes.
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.
To learn more about Ben’s debugging subVIs, read his post on LVMastery.com.
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.
Figure 7. The Perils of Manual Execution Tracing (courtesy of Oliver Widder)
See this tutorial to learn how to get the most out of the toolkit.
Professional LabVIEW developers can celebrate, because the LabVIEW Desktop Execution Trace Toolkit is now included at no extra cost with NI Developer Suite 2011.
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.
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.