Have you ever written a program with no errors in it? LabVIEW has many built-in debugging features to help you develop your VIs. This section explains how to use these conveniences to your best advantage. Fixing a Broken VIRun Button (broken) A broken VI is a VI that cannot compile or run. The Run button appears as a broken arrow to indicate that the VI has a problem. It's perfectly normal for a VI to be broken while you are creating or editing it, until you finish wiring all the icons in the diagram. Sometimes you may need to Remove Broken Wires (found in the Edit menu) to clean up loose wires, but be careful not to delete wires you want! To find out why a VI is broken, click on the broken Run button or select Show Error List from the Windows menu. An information box titled "Error List" appears, listing all errors for the VI. You can choose to see the error list for other open VIs using a menu ring at the top of the window. To find out more about a particular error, click on it. The Error List window will display more information. To locate a particular error in your VI, double-click on the error in the list or highlight it and press the Show Error button. LabVIEW brings the relevant window to the front and highlights the object causing the error (see Figure 5.6). Figure 5.6. Error List dialog
WarningsWarning Button If you want extra debugging help, you can choose to Show Warnings in the Error List window by clicking in the appropriate box. A warning is something that's not illegal and won't cause a broken run arrow, but does not make sense to LabVIEW, such as a control terminal that is not wired to anything. If you have Show Warnings checked and have any outstanding warnings, you will see the Warning button on the Toolbar. You can click on the Warning button to see the Error List window, which will describe the warning. You can also configure LabVIEW's options to show warnings by default. Go to the Debugging section in the Options dialog box (accessed by selecting Tools>>Options . . .) and check the Show warnings in Error List by default box. Most Common MistakesCertain mistakes are made more frequently than others, so we thought we'd list them to make your life easier. If your Run button is broken, one of these might describe your problem. Please see Appendix E, "Resources for LabVIEW" for a link to the LabVIEW FAQ, a great on-line resource containing answers to frequently asked questions.
Single-Stepping Through a VIPause Button For debugging purposes, you may want to execute a block diagram node by node. Nodes include subVI's, functions, structures, code interface nodes (CINs), formula nodes, and property nodes. To begin single-stepping, you can start a VI by clicking on one of the single-step buttons (instead of the Run button), pause a VI by setting a breakpoint, or click on the Pause button. To resume normal execution, hit the Pause button again. You may want to use execution highlighting (described next) as you single-step through your VI, so you can visually follow data as it flows through the nodes. While in single-step mode, press any of the three step buttons that are active to proceed to the next step. The step button you press determines how the next step will be executed. Step Into Button Press the Step Into button to execute the first step of a subVI or structure and then pause at the next step of the subVI or structure. Or, you can use the keyboard shortcut: down arrow key in conjunction with <control> under Windows and <command> on Macs and <meta> on Linux. Step Over Button Press the Step Over button to execute a structure (sequence, loop, etc.) or a subVI and then pause at the next node. Or, you can use the keyboard shortcut: right arrow key in conjunction with <control> under Windows and <command> on Macs. Step Out Button Press the Step Out button to finish executing the current block diagram, structure, or VI and then pause. Or, you can use the keyboard shortcut: up arrow key in conjunction with <control> under Windows and <command> on Macs. Execution HighlightingExecution Highlighting Button Sometimes it's nice to see exactly where your data is and what's happening to it. In LabVIEW, you can view an animation of VI block diagram execution. To enable this mode, click on the Execution Highlighting button in the Toolbar. As data passes from one node to another, the movement of data is marked by bubbles moving along the wires. You will notice that highlighting greatly reduces the performance of a VI. Click again on the Execution Highlighting button to resume normal execution. Figure 5.7 shows a VI running with execution highlighting enabled. Figure 5.7. The block diagram of a running VI that has Execution Highlighting enabled, showing "data bubbles" flowing through wires and the values of wires appearing in tip strips
Node values are automatically shown during execution highlighting, as in the previous illustration, if you select Auto probe during execution highlighting from the Debugging menu of the Options dialog. You commonly use execution highlighting in conjunction with single-step mode to gain an understanding of how data flows through nodes. When these two modes are used together, execution glyphs on the subVI's icon indicate which VIs are running and which are waiting to run. Be aware that data in independent (parallel) "chunks" of the diagram (those not having data flow dependencies) may not always flow in the same sequence on subsequent executions or iterations. And sometimes "race conditions" that cause problems under normal execution (with execution highlighting turned off) may disappear completely with execution highlighting turned on and appear to behave as "expected," thus hiding the buggy behavior. A race condition refers to a situation in your program where two or more independent processes are trying to write data at the same time to a variable (thus, they "race" against each other). You will see more examples of race conditions, and how to avoid them, in the latter chapters of this book. If you see such quirky behavior, look for race conditions as the possible cause. Setting BreakpointsDon't panicbreakpoints do not "break" a VI; they only suspend its execution (similar to the Pause button) so that you can debug it. Breakpoints are handy if you want to inspect the inputs to a VI, node, or wire during execution. When the diagram reaches a breakpoint, it activates the pause button; you can single-step through execution, probe wires to see their data, change values of front panel objects, or simply continue running by pressing the Pause button or the Run button. Breakpoint Tool To set a breakpoint, click on a block diagram object with the Breakpoint tool from the Tools palette. Click again on the object to clear the breakpoint. The appearance of the breakpoint cursor indicates whether a breakpoint will be set or cleared. Depending on where they are placed, breakpoints behave differently:
When a VI pauses because of a breakpoint, the block diagram comes to the front, and the object causing the break is highlighted with a marquee. Breakpoints are saved with a VI but only become active during execution. Saving VIs with breakpoints is generally not advised, because they are intended for debugging your VIs. It is easy to inadvertently save a VI after setting a breakpoint. If you accidentally do so, you may be puzzled the next time you or a colleague opens your LabVIEW project and finds that a saved breakpoint is suspending execution of a VI. You can easily find breakpoints in your VIs using the Find dialog, which can be opened by selecting Edit>>Find and Replace from the menu or using the shortcut <ctrl-F> (Windows), <command-F> (Mac OS X), or <meta-F> (Linux). From the Find dialog, select Search for: Objects, Object: Others>>Breakpoint, and define your Application Instance and Search Scope options. Suspending ExecutionYou can also enable and disable breakpoints with the Suspend when Called option, found in the Execution menu of VI Properties . . . (which you access from the icon pane pop-up menu in a VI's front panel). Suspend when Called causes the breakpoint to occur at all calls to the VI on which it's set. If a subVI is called from two locations in a block diagram, the subVI breakpoint suspends execution at each call. If you want a breakpoint to suspend execution only at a particular call to the subVI, set the breakpoint using the SubVI Node Setup . . . option. Pop up on the subVI icon (in the block diagram of the calling VI) to access this option. You will learn more about VI setup options in Chapter 15, "Advanced LabVIEW Features." Using the ProbeUse the probe to check intermediate values in a VI that executes but produces questionable or unexpected results. For instance, assume you have a diagram with a series of operations, any one of which may be the cause of incorrect output data. To fix it, you could create an indicator to display the intermediate results on a wire, or you can leave the VI running and simply use a probe. To access the probe, select the Probe tool from the Tools palette and click its cursor on a wire, or pop up on the wire and select Probe. The probe display, which is a floating window, first appears empty if your VI is not running (unless you have pressed the Retain Wire Values button, which we discuss shortly). When you run the VI, the probe display shows the value carried by its associated wire. Figure 5.8 shows a VI block diagram with probes placed on two of the wires. Figure 5.8. A block diagram with probes placed on two of the wires
You can use the probe with execution highlighting and single-step mode to view values more easily. Each probe and the wire it references are automatically numbered uniquely by LabVIEW to help you keep track of them. A probe's number will not be visible if the name of the object probed is longer than the Probe window itself; if you lose track of which probe goes with which wire, you can pop up on a probe or a wire and select Find Wire or Find Probe, respectively, to highlight the corresponding object. You cannot change data with the probe. |