1 / 32

LabVIEW Debugging Techniques to Find and Squash Software Bugs

LabVIEW Debugging Techniques to Find and Squash Software Bugs. Grant Heimbach, LabVIEW Product Manager. 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.

kagami
Download Presentation

LabVIEW Debugging Techniques to Find and Squash Software Bugs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LabVIEW Debugging Techniques to Find and Squash Software Bugs Grant Heimbach, LabVIEW Product Manager

  2. Photo Credit: Bugs / Brian Searle / CC BY 2.0

  3. LabVIEW Edit-Time Bugs

  4. LabVIEW Edit-Time Bugs

  5. LabVIEW Run-Time Bugs

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

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

  8. 2. Highlight Execution • Animation of the block diagram data flow • LabVIEW Idea Exchange (ni.com/ideas) on “User Defined Partial Highlight Execution”

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

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

  11. 4. Probes DEMO • Watch data values on wires in “real time” • SAPHIR - VIBox Probes free add-on for custom probes available on the LabVIEW Tools Network

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

  13. 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”

  14. 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”

  15. 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)

  16. 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)

  17. 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)

  18. 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)

  19. 6. Suspend When Called DEMO • 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)

  20. 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”

  21. 7. Debugging with “Binary Search” method DEMO • 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”

  22. 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”

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

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

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

  26. 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”

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

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

  29. 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?

  30. Want to Learn More? • ni.com/training • “LabVIEW Core 1” – LabVIEW Debugging Basics • “LabVIEW Core 2” – Debugging a LabVIEW Application • “LabVIEW Performance” – Identify and Improve Performance Issues; VI Profiler, VI Analyzer, Desktop Execution Trace Toolkit • ni.com/training/self-paced(For LabVIEW Core 1 & 2) • “Debugging Techniques” in-product whitepaper (Help»LabVIEW Help) and also online if you search ni.com

More Related