Scribd
Upload
76 views

LabVIEW Debugging Techniques

The document discusses 10 debugging techniques for finding and fixing bugs in LabVIEW programs: 1) using error wires, 2) highlighting execution, 3) single-stepping, 4) using probes, 5) setting breakpoints, 6) suspending when called, 7) binary search debugging, 8) writing to a debug file, 9) using the desktop execution trace toolkit, and 10) initializing shift registers and checking for hidden VIs. It provides brief descriptions and tips for each technique.

Uploaded by

maryusso
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
76 views

LabVIEW Debugging Techniques

The document discusses 10 debugging techniques for finding and fixing bugs in LabVIEW programs: 1) using error wires, 2) highlighting execution, 3) single-stepping, 4) using probes, 5) setting breakpoints, 6) suspending when called, 7) binary search debugging, 8) writing to a debug file, 9) using the desktop execution trace toolkit, and 10) initializing shift registers and checking for hidden VIs. It provides brief descriptions and tips for each technique.

Uploaded by

maryusso
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

LabVIEW Debugging Techniques to Find and

Squash Software Bugs

ni.com
Photo Credit: Bugs / Brian Searle / CC BY 2.0
LabVIEW Edit-Time Bugs
LabVIEW Edit-Time Bugs
LabVIEW Run-Time Bugs
1. Use Error Wires
 Surfaces run-time errors so you can fix them

• Search ni.com “Structured Error Handler” for a more


structured error handling strategy
1. Use Error Wires
 Surfaces run-time errors so you can fix them

• Search for “Structured Error Handler” on ni.com for a


more structured error handling strategy
2. Highlight Execution
 Animation of the block diagram data flow

• LabVIEW Idea Exchange (ni.com/ideas) on “User


Defined Partial Highlight Execution”
3. Single-Stepping
 Walk through each block diagram interaction one at a time

Step Into Step Over Step Out

• If you single-step through a VI with execution highlighting


on, an execution glyph appears on the icons of the
subVIs that are currently running.
4. Probes
 Watch data values on wires in “real time”

• SAPHIR - VIBox Probes free add-on for custom probes


available on the LabVIEW Tools Network
DE
4. Probes M
O
 Watch data values on wires in “real time”

• SAPHIR - VIBox Probes free add-on for custom probes


available on the LabVIEW Tools Network
4. Probes
 Watch data values on wires in “real-time”

• SAPHIR - VIBox Probes free add-on for custom probes


available on the LabVIEW Tools Network
5. Breakpoints
 Pause execution of a VI at a certain block diagram location

• LabVIEW Idea Exchange (ni.com/ideas) on “Allow Data


in Wires to be Forced During Development”
5. Breakpoints
 Pause execution of a VI at a certain block diagram location

• LabVIEW Idea Exchange (ni.com/ideas) on “Allow Data


in Wires to be Forced During Development”
6. Suspend When Called
 Suspends execution of subVI when it is called

• Determine where the subVI is being called from by using


the Call list pull-down menu on the toolbar (Call Chain
function also would work programmatically)
6. Suspend When Called
 Suspends execution of subVI when it is called

• Determine where the subVI is being called from by using


the Call list pull-down menu on the toolbar (Call Chain
function also would work programmatically)
6. Suspend When Called
 Suspends execution of subVI when it is called

• Determine where the subVI is being called from by using


the Call list pull-down menu on the toolbar (Call Chain
function also would work programmatically)
6. Suspend When Called
 Suspends execution of subVI when it is called

• Determine where the subVI is being called from by using


the Call list pull-down menu on the toolbar (Call Chain
function also would work programmatically)
EM DE
6. Suspend When Called M
O O
 Suspends execution of subVI when it is called

• Determine where the subVI is being called from by using


the Call list pull-down menu on the toolbar (Call Chain
function also would work programmatically)
7. Debugging with “Binary Search” method
 Comment out half of your code and see if the problem still
persists. Keep going until you narrow in on the offending
code

• LabVIEW Idea Exchange (ni.com/ideas) on “Conditional


Disable Symbols settable in Application Builder”
DE
7. Debugging with “Binary Search” method M
O
 Comment out half of your code and see if the problem still
persists. Keep going until you narrow in on the offending
code

• LabVIEW Idea Exchange (ni.com/ideas) on “Conditional


Disable Symbols settable in Application Builder”
7. Debugging with “Binary Search” method
 Comment out half of your code and see if the problem still
persists. Keep going until you narrow in on the offending
code

• LabVIEW Idea Exchange (ni.com/ideas) on “Conditional


Disable Symbols settable in Application Builder”
8. VI Debug File
 Write values to a “debug file” periodically so that you can
read about the VI execution later

• This will show the values in more real execution timing


compared to other tools like Highlight Execution
8. VI Debug File
 Write values to a “debug file” periodically so that you can
read about the VI execution later

• This will show the values in more real execution timing


compared to other options like Highlight Execution
8. VI Debug File
 Write values to a “debug file” periodically so that you can
read about the VI execution later

• This will show the values in more real execution timing


compared to other options like Highlight Execution
8. VI Debug File
 Write values to a “debug file” periodically so that you can
read about the VI execution later

• For this example, search ni.com/community for “Simple


Debug File Troubleshooting in LabVIEW”
9. Desktop Execution Trace Toolkit
 Even code that is syntactically correct and functionally
complete is often still contaminated with problems such as
memory leaks or daemon tasks that can impact
performance or lead to incorrect behavior
 Debugging large, highly parallel applications is difficult
 Code that crashes LabVIEW needs another process to
help it debug
9. Desktop Execution Trace Toolkit
 Good for memory leaks, event sources, last call before
error, and remote execution tracing
 It can trace VI Execution, Event Structure, Queues and
Notifers, User Logged Strings, Reference Leaks, Error I/O,
Memory Allocations, and Thread and CPU IDs
 Comes free with Developer Suite
10. Catch All
 Make sure and initialize appropriate shift registers (There
is a VI Analyzer test for this)

 Hidden or unwired subVIs could happen if you place


structures on top of VIs and could cause the VI to perform
extra functions. Use View»VI Hierarchy, to look for extra
VIs or change the environmental setting so that terminals
are “required” by default.

• What else is missing from this list?

You might also like