Error out labview

ERROR HANDLING

By default LABVIEW automatically handles any error that occurs when a VI runs by suspending execution, highlighting the subVI or function where the error occurred, and displaying a dialog box. You can choose other error handling methods. For example, if an I/O VI on the BLOCK DIAGRAM times out, you might not want the entire application to stop. You also might want the VI to retry for a certain period of time. In LabVIEW, you can make these error handling decisions on the block diagram of the VI.

VIs and functions return errors in one of two ways—with numeric error codes or with an error cluster. Typically, functions use numeric error codes, and VIs use an error cluster, usually with error inputs and outputs. Error handling in LABVIEW follows the data flow model. Just as data flow through a VI, we get an error information. Wire the error information from the beginning of the VI to the end. Include an error handler VI at the end of the VI to determine if the VI ran without errors. Use the error in and error out clusters in each VI you use or build to pass error information through the VI.

If you would like to Enrich your career with an Android certified professional, then visit Mindmajix — A Global online training platform: “LabVIEW training” Course.This course will help you to achieve excellence in this domain.

As the VI runs, LabVIEW tests for errors at each execution node. If LabVIEW does not find any errors, the node executes normally. If LabVIEW detects an error, the node passes the error to the next node without executing. The next node does the same thing and so on. Use the simple error handler VI, shown below Figure, to handle the error at the end of the execution flow. The simple error handler VI is located on the Functions» All Functions» Time & Dialog palette. Wire the error cluster to the error in input.

ERROR CLUSTER

Error clusters tell you why and where errors occur. When you perform any kind of I/O, consider the possibility that errors will occur. Almost all I/O functions return error information. Include error checking in VIs, especially for I/O operations such as file, serial, instrumentation, data acquisition, and communication operations, and provide a mechanism to handle errors appropriately. No matter how confident you are in the VI you create, you cannot predict every problem a user might encounter. Without a mechanism to check for errors, you know only that the VI does not work properly. Checking for errors in VIs can help you identify the following problems:

• You initialized communications incorrectly or wrote improper data to an external device.
• An external device lost power, is broken, or is not working properly.
• You upgraded the operating system software which changed the path to a file or the functionality of a VI or library. You might notice a problem in a VI or a system program.

Frequently Asked LabVIEW Interview Questions & Answers

The error clusters located on the Functions» All Functions» Array & Cluster palette include the following components of information which are also shown below Figure.

• status is a Boolean value that reports True if an error occurred. Most VIs, functions, and structures that accept Boolean data also recognize this parameter. For example, you can wire an error cluster to the Boolean inputs of the Stop, Quit LabVIEW, or Select If an error occurs, the error cluster passes a True value to the function.  
• code is a 32-bit signed integer that identifies the error numerically. A non-zero error code coupled with a status of False signals a warning rather than a fatal error.
• the source is a string that identifies where the error occurred. Use the error cluster controls and indicators to create error inputs and outputs in subVIs.

When an error occurs, right-click within the cluster border and select Explain Error from the shortcut menu to open the Explain Error dialog box. The Explain Error dialog box contains information about the error. The shortcut menu includes an Explain Warning option if the VI contains warnings but no errors. You can also access the Explain Error dialog box from the Help» Explain Error menu.

Explore LabVIEW Sample Resumes! Download & Edit, Get Noticed by Top Employers!Download Now!

About Author

This article or section needs to be updated. Some information on it may be out of date, and should not be relied on. Please improve this article if you can.

The Error Cluster is a predefined LabVIEW Cluster that is used to contain error status information. The cluster contains the following three components:

An error cluster contains a Boolean “status”, an I32 numerical “code” and a “source” string in that order. Any cluster with this structure is treated as an error cluster in LabVIEW. The default value, “status” = false, “code” = 0 and “source” empty, is shown in Figure 1 for a typical control.

Note that the default terminal and wire color was changed from pink to dark yellow in LabVIEW 8.2 (upgrade notes p. 35). The “status” is true if an error has occurred but remains false for warnings. The “code” assumes positive and negative values (see “error codes, ranges of” in LabVIEW Help).

Custom Error Codes

The following ranges are reserved for developers to define their own error codes (see Custom Error Code):

• 5000 to 9999
• -8999 to -8000
• 500000 to 599999

Use Tools >> Advanced >> Edit Error Codes to create text files to define your own errors.

The “source” identifies a VI and possibly its call chain as the origin of an error. Possible reasons for an error can be obtained from the Explain Error tool (see Figure 2). This tool is activated by selecting the Explain Error… item under the Help menu in LabVIEW or by right-clicking on any element of an error cluster with “status” true and selecting Explain Error.

General Error Handling

LabVIEW provides several VIs for working with error clusters. For example, the Error Cluster from Error Code.vi generates an error cluster based on a specified “code” (see Figure 3). You can also define custom codes using the General Error Handler.vi or by creating an XML-based text file in the <labviewuser.lib errors> directory (see “error codes, defining custom” and “error codes, defining custom in text files” in LabVIEW Help). This VI outputs a “message”, like the “Explanation” from Explain Error, which identifies the “source” and describes possible causes associated with the “code”. This information can also be displayed using several different types of dialogs. This feature is commonly employed to identify errors in user interface applications.

Error Comparison

Error clusters are also valid inputs to some comparison and array functions and can be used to control case structures and while loops (see Figure 4).

The comparison functions Equal?, Not Equal?, Greater?, Less?, Greater Or Equal? and Less Or Equal? can operate in two modes. The output is Boolean in the Compare Aggregates mode, while a cluster of three Booleans corresponding to each component of the error cluster is generated in the Compare Elements mode (see Figure 5).

The Select, Max & Min and In Range and Coerce functions can output an error cluster. While the Max & Min function returns ordered inputs in the Compare Aggregates mode, an output may not correspond to either error cluster if Compare Elements is selected (default). The Array Max & Min function always returns ordered inputs corresponding to the first and last elements of the Sort 1D Array output. The primary sort is performed on “status”, with secondary ordering by “code” and then “source”. Strings are sorted by ASCII code starting with the leading character. Note that error clusters behave like their Boolean “status” value when connected to the selector terminal of a Select function and Case Structure or the conditional terminal of a While Loop.

Error Selection

A common programming issue in LabVIEW involves selecting between two or more error clusters. This process involves finding the cluster with “status” true or “code” not equal zero if no “status” is true. The Merge Errors.vi shown in Figure 4 implements this search for up to three error clusters and an array of such clusters. This subVI is relatively fast with large error arrays. However, a significant portion of the execution time involves concatenation of inputs for the small arrays (<10 elements) typical in most applications. This result suggests that time critical applications should be built around the immediate selection between two error clusters rather than their concatenation into an array. The simplest method of comparing the “status” of two error clusters involves the Select function (see Figure 6).

This function selects the first error cluster with “status” true, much like the Or function operating on Boolean inputs. Connecting “error 2” instead of “error 1” to the selector terminal is more analogous to the And function, which is typically less useful. While about 30 times faster than the Merge Errors.vi (LabVIEW 7.0), the Select function does not detect a warning (“status” false and “code” not equal zero).

Diagrams for several VIs that compare error clusters and detect warnings are shown below (fastest to slowest).

These VIs execute about 5 times faster than the Merge Errors.vi (LabVIEW 7.0), even with normal priority execution. (Merge Errors.vi uses the “subroutine” priority.) Inputs to selector terminals in the first and second diagrams are passed to “error” for the cases not shown. Otherwise, “error 1” is checked for nonzero “code” since neither cluster has “status” true. The last approach uses the Max & Min function in Compare Aggregates mode to order inputs. If just one of these clusters has “status” true, that input will be the “max” output since true > false. However, this output must be checked for “status” true or “code” nonzero to determine selection.

Error Cluster as Execution Order Specifier

LabVIEW is a dataflow language and as such preferred way to specify execution order of block diagram items is to connect output of a block diagram item to an input of another block diagram item. There are situations when some certain execution order is required but the outputs of the items to be executed earlier cannot be connected to the inputs of the items to be executed later. In these situations error cluster is a preferred way to specify the execution order of the items. It’s preferred over sequence structures in almost all use cases.

This can easily be achieved by a private replacement for the ‘merge errors’ node, that also contains a ‘No_Error’  constant:

The connector pane looks like this:

It can be used like this:

So a VI-Ref is opened independently if an error occured before, but after all preliminary portions of code had been finished. The printing actions relate to the eventual error of the OpenVI-Ref node only. All errors are merged as final action, so any error that might have shown up is reported, while the printing actions care only on VI-server related errors.

This little helper is too simple to provide its code as VI, though…

Tips and tricks

• Right-click the status button inside an error cluster on the front panel and select Explain Error to open the Explain Error dialog.

See also

• Error handling
• Error Case Structure

Соседние файлы в папке LabView — учеб. пособия

• #
• #
• #
• #

You might have already noticed the error cluster datatype, which is found on the Modern>>Array, Matrix & Cluster palette (Error In and Error Out, shown in Figure 7.64) and can also be found used in the inputs and outputs of many VIs and functions. The error cluster is a special datatype in LabVIEW (a cluster consisting of a status Boolean, code I32, and source string) that is used for propagating information about errors that occur during the execution of LabVIEW code. Errors and error handling are very naturalthere is no reason to be afraid of errors. Rather, we should understand how errors can occur, how to communicate errors, and how to handle errors.

Figure 7.64. Error In and Error Out controls found on the Array, Matrix & Cluster palette

So, what is an error? In simple terms, an error is an event where a function or subVI cannot complete a request because resources are not available or the information (arguments) passed to it are not valid.

In LabVIEW, we use dataflow to propagate information about errors inside of an error cluster datatype.

Error Cluster Datatype

The error cluster (shown in Figure 7.65) contains three elements, as follows:

1. status BooleanSignifies whether there is an error (TRUE) or no error (FALSE).

2. code I32Is an error code signed integer that identifies the error.

   1. Positive codes are errors.

   2. Negative codes are warnings.

   3. Zero is no error.

3. source stringIs a string that contains descriptive information about the source of the error. This commonly also contains a call chain, a list of VIs starting at the subVI (or function) where the error occurred and then listing up the call hierarchy, all the way up to the top-level VI.

   Figure 7.65. Error cluster

   

Propagating Errors: Error Dataflow

You use the error cluster datatype to store information about an error, and you use dataflow to propagate the error cluster through your block diagram. As you can see the example shown in Figure 7.66, an error cluster passes through the block diagram, connecting the following, in sequence:

1. error in control terminal to the Read From Measurement File subVI.

2. Read From Measurement File subVI to Amplitude and Level Measurements subVI.

3. Amplitude and Level Measurements subVI to the error out indicator terminal.

   Figure 7.66. Block diagram showing how the error cluster is used to propagate errors using dataflow

   

Many of LabVIEW’s functions and VIs have error in and error out terminals. These are almost always found (if present on the function or VI) on the lower-left and lower-right terminals of the connector pane (respectively). Figures 7.67 and 7.68 show the inputs and outputs of Read From Measurement File and Amplitude and Level Measurements with error in and error out highlighted.

Figure 7.67. Read From Measurement File

Figure 7.68. Amplitude and Level Measurements

Generating and Reacting to Errors in SubVIs

The expected behaviors of functions and VIs, with respect to generating and reacting to errors, are the following:

1. If error in contains an error (status = TRUE), do not do any work unless it is «clean up» work, such as

   1. closing file references.

   2. closing instrument or other communication references.

   3. putting the system back into an idle/safe state (powering off motors, etc.).

2. If an error occurs inside of a function or VI, the function should pass out the error information via its error out indicator terminal unless it was passed in an error via its error in input terminal. In this case, just pass the incoming error from error in to error out, unchanged.

Error Case Structure

A subVI can fulfill expected behavior #1, by «wrapping» all of its functional code (its «work») inside of an Error Case Structure, which is simply a case structure that has an error cluster wired to its case selector terminal. As you can see in Figure 7.69, the Case Structure allows the error cluster datatype to be wired to its case selector terminal. When wired in this way, the Case Structure frame names change to «No Error» and «Error.» At run-time, if the error cluster does not contain an error, then the «No Error» frame will execute. Conversely, if the error cluster does contain an error, then the «Error» frame will execute.

Figure 7.69. An «Error Case Structure» containing an «Error» and «No Error» cases

Figure 7.70 shows how we can use a case structure to conditionally execute our functional code only when there is no «upstream error» (using the dataflow vernacular).

Figure 7.70. An «Error Case Structure» used to execute code only when there is no «upstream error»

Merge Errors

But, what about the situation where you want to do some clean-up work, even if an upstream error has occurred? In this case, you should not wrap your functional code in an Error Case Structure, but rather, merge the error cluster flowing out of your work with the upstream error cluster using Merge Errors.vi, as shown in Figure 7.71.

Figure 7.71. Using Merge Errors.vi to combine several error clusters into a single error cluster

An error cluster can contain information about one, and only one, error. (This is a limitation in the data structure that carries a long legacy.) Merge Errors.vi merges several errors cluster inputs into a single error output. However, if there are errors in more than one input, it must choose which of these errors will take top priority and be passed to error out. It uses a top-to-bottom priority scheme, giving error in 1 top priority, then error in 2, and so on.

In the example shown in Figure 7.72, it is critical that the upstream error be wired to error in 1 (the top-most error input terminal) to ensure that the upstream error takes priority over any errors that occur inside our subVI.

Figure 7.72. Merge Errors.vi

(Programming>>Dialog & User Interface palette). Merges error I/O clusters from different functions. This VI first looks for errors among error in 1, error in 2, and error in 3; then error array in and reports the first error found. If the VI finds no errors, it looks for warnings and returns the first warning found. If the VI finds no warnings, it returns no error.

Use merge errors to combine the error clusters of parallel tasks, or tasks that must each execute regardless of upstream errors.

Handling Errors in SubVIs

It is a good practice for a subVI to make a reasonable attempt to fulfill its contract (its stated job, per the software design requirements) in every way it can before passing an error up.

For example, imagine you are writing a routine that initializes an XY motion stage. (This might actually be the case, for some of our readers.) In order to find the home position (X = 0, Y = 0), the stage is moved at a low velocity toward a position sensor that outputs a digital signal of 1 (TRUE) when the stage reaches the home position. However, because there is a lot of electrical noise coming from the stage motors, the position sensor sometimes fails to report when the stage is at the home position (it sometimes jumps to 0, momentarily). This causes the initialization routine to fail at a rate of about one (1) out of twenty (20) tries, or 5% of the time. When it does fail, it always outputs the same error code. The noisy home position sensor signal has no other effect on the system, except for the occasional error during the homing operation.

Knowing what you know about the rate of failure and the type of failure, why not adapt your homing routine to retry (up to a certain number of times) before actually outputting an error message to the calling VI? This would make your code robust: fault tolerant and able to get the job done in spite of minor errors. Wouldn’t your end users be much happier if you made this change? Think of all those times they’ve started an experiment and came back to the lab an hour later expecting to find their experiment completed but, instead, they find that the system has generated that blankity-blank error while trying to home the stage… again!

OK, you agree that handling errors in subVIs is a great idea. Because the error cluster is just that, a cluster, you can use the cluster functions such as Unbundle By Name and Bundle By Name to access and modify the error data. For example, you can unbundle the error code.

Generating Errors in SubVIs

When you call a subVI or function and it generates an error, you can either try again (or perhaps try something else) or you can give up and propagate error (passing it downstream or up to the calling VI). But what happens when you want to generate a new error, perhaps because of an invalid input passed down from the calling VI? For this situation, you should use Error Cluster From Error Code.vi to generate a new error (see Figure 7.73).

Figure 7.73. Error Cluster From Error Code.vi

Error Cluster From Error Code.vi (Programming>>Dialog & User Interface palette) converts an error or warning code to an error cluster. This VI is useful when you receive a return value from a DLL call or when you return user-defined error codes.

For example, Figure 7.74 shows how we might generate an error in a subVI when an invalid argument is passed into the subVI (the TRUE case of the inner Case Structure is shown only for illustration purposes). In this example (which is located on the CD at EVERYONE/CH07/Calculate Square Root with Error.vi), we are calculating the square root of a number x. If x is negative, we will output an error (error code 1, which signifies an argument error) and default output data.

Figure 7.74. Calculate Square Root with Error.vi block diagram

Giving Up: Displaying Error Messages to the User

If error conditions cannot be handled by subVIs or in your top-level application, you can «give up» (but, please don’t accept defeat too easily) and display an error message to the user. This is the «last resort» of error handling. Figure 7.75 shows an error being passed to Simple Error Handler.vi (found on the Programming>>Dialog & User Interface palette) to display a dialog containing the error information. In this case, we passed a negative number to the subVI shown in Figure 7.74, which is an invalid input.

Figure 7.75. Calling Calculate Square Root with Error.vi as a subVI

Figure 7.76. Simple Error Handler.vi

Simple Error Handler.vi (Programming>>Dialog & User Interface palette) indicates whether an error occurred. If an error occurred, this VI returns a description of the error and optionally displays a dialog box. This VI calls the General Error Handler VI and has the same basic functionality as General Error Handler but with fewer options.

Extra Tips for Error Handling

Use the following tips for successful error handling.

Use the Explain Error Dialog

When an error cluster control or indicator contains an error or warning, you can learn more about an error by selecting Explain Error from the cluster’s pop-up menu, as shown in Figure 7.77.

Figure 7.77. Selecting Explain Error from the pop-up menu of an error cluster to open the Explain Error dialog (shown in Figure 7.78)

This will display the Explain Error dialog, as shown in Figure 7.78.

Figure 7.78. Explain Error dialog, which shows a detailed error explanation

Go with the Dataflow: Use Error In and Error Out Terminals

When you add error in and error out I/O terminals to your VIs, you allow calling VIs the opportunity to chain the error cluster wire to create dataflow dependencies between subVIs. Also, you are enabling applications to perform error handling, which is a good programming practice. Even if your subVI might not ever generate an error itself, put error I/O terminals on the front panel, and put an Error Case Structure on the block diagram (as you just learned) to allow errors to propagate through the software.

Make sure to wire error in to the lower-left terminal and error out to the lower-right terminal of the VI connector panethis is a best practice.

Define Your Own Errors: User-Defined Error Codes

For large applications, you might want to explore user-defined error codes, which are specific to your application. The LabVIEW Help documentation describes the process for defining and using this feature.

Don’t Get Stuck in a Loop: Test Error Status in Loops

It is almost always a good idea to check for errors inside of loops, so that you can exit the loop if an error occurs. Figure 7.79 shows how this is done. Note that the loop will stop if either the stop button is pressed or an error occurs.

Figure 7.79. Checking for errors in a While Loop to exit the loop when there is an error

Use Shift Registers to Pass Errors Through Loops

Always use shift registers (not tunnels) for passing error clusters through the wall of a loop. This is especially important for a For Loop, as shown in Figure 7.80. Remember, if a For Loop executes zero times, data still passes from the input shift register to the output shift register. Wiring error clusters to shift registers on a For Loop ensures that errors propagate through the For Loop if it executes zero times.

Figure 7.80. Using shift registers to pass errors through loops

Included in the Section

Selecting a Tool

Shortcut Menus

Property Dialog Boxes

Front Panel Window Toolbar

Block Diagram Window Toolbar

In a graphical programming language such as LabVIEW software, the mouse is the main way to interact with the programming environment. That said, the mouse pointer must be able to accomplish many different tasks, such as selecting, wiring, highlighting text, and so on. This module examines not only the many functions that the mouse can accomplish in LabVIEW but also how to go about completing those tasks.

This module also covers a few other important ways of modifying your VIs: shortcut menus, property dialogs and the toolbar.

You can create, modify, and debug VIs using the tools provided by LabVIEW. A tool is a special operating mode of the mouse cursor. The operating mode of the cursor corresponds to the icon of the tool selected. LabVIEW selects this tool based on the current location of the mouse.

Figure 1. Tools Palette

You can manually choose the tool you need by selecting it on the Tools palette. Select View»Tools Palette to display the Tools palette.

Automatic Tool Selector

The top item in the Tools palette is the Automatic Tool Selection button. When you select this, LabVIEW automatically chooses a tool based on the location of your cursor. You can turn off automatic tool selection by deselecting the item or by selecting another item in the palette.

If you were to compare the tools in LabVIEW to common household tools, the individual tools listed below would represent a screwdriver, knife, and corkscrew, and the automatic tool selector would be a Swiss army knife that is capable of accomplishing all tasks.

Figure 2.Individual Tools and Automatic Tool Selector

Listed below are some of the more common tools that you encounter in LabVIEW. Note that when the Automatic Tool Selection button is enabled, the mouse changes into one of the following tools to accomplish the most common tasks in LabVIEW.

Operating Tool

Use the Operating tool to change the values of a control. For example, in Figure 3 the Operating tool moves the pointer on the Horizontal Pointer Slide. When the mouse hovers over the pointer, the cursor automatically accesses the Operating tool.

Figure 3. Using the Operating Tool

The Operating tool is mostly used on the front panel window, but you also can use the Operating tool on the block diagram window to change the value of a Boolean constant.

Positioning Tool

Use the Positioning tool to select or resize objects. For example, in Figure 4 the Positioning tool selects the Number of Measurementsnumeric control. After selecting an object, you can move, copy, or delete the object. When the mouse hovers over the edge of an object, the cursor automatically accesses the Positioning tool.

Figure 4. Using the Positioning Tool to Select an Object

If the mouse hovers over a resizing node of an object, the cursor mode changes to show that you can resize the object, as shown inFigure 5. Notice that the cursor is hovering over a corner of the XY Graph at a resizing node, and the cursor mode changes to a double-sided arrow.

Figure 5. Using the Positioning Tool to Resize an Object

You can use the Positioning tool on both the front panel window and the block diagram.

Labeling Tool

Use the Labeling tool to enter text in a control, to edit text, and to create free labels. For example, in Figure 6 the Labeling tool enters text in the Number of Measurements numeric control. When the mouse hovers over the interior of the control, the cursor automatically accesses the Labeling tool. Click once to place a cursor inside the control. Then double-click to select the current text.

Figure 6. Using the Labeling Tool

When you are not in a specific area of a front panel window or block diagram window that accesses a certain mouse mode, the cursor appears as cross-hairs. If automatic tool selection is enabled, you can double-click any open space to access the Labeling tool and create a free label.

Wiring Tool

Use the Wiring tool to wire objects together on the block diagram. For example, in Figure 7, the Wiring tool wires the Number of Measurements terminal to the count terminal of the For Loop. When the mouse hovers over the exit or entry point of a terminal or over a wire, the cursor automatically accesses the Wiring tool.

Figure 7. Using the Wiring Tool

The Wiring tool works mainly with the block diagram window and when you create a connector pane on the front panel window.

Other Tools Accessed from the Palette

You can access the following additional tools on the palette:

Use the Object Shortcut Menu tool to access an object shortcut menu with the left mouse button. You also can access this menu by right-clicking any object in LabVIEW.

Use the Scrolling tool to scroll through windows without using scrollbars.

Use the Breakpoint tool to set breakpoints on VIs, functions, nodes, wires, and structures to pause execution at that location.

Use the Probe tool to create probes on wires on the block diagram. Also use the Probe tool to check intermediate values in a VI that produces questionable or unexpected results.

Use the Coloring tool to color an object. The Coloring tool also displays the current foreground and background color settings.

Use the Get Color tool to copy colors for pasting with the Coloring tool.

All LabVIEW objects have associated shortcut menus, also known as context menus, pop-up menus, and right-click menus. As you create a VI, use the shortcut menu items to change the appearance or behavior of front panel and block diagram objects. To access the shortcut menu, right-click the object.

Figure 8. Shortcut Menu for a Meter

Objects in the front panel window also have property dialog boxes that you can use to change the look or behavior of the objects. Right-click an object and select Properties from the shortcut menu to access the property dialog box for an object. Figure 9 shows the property dialog box for the meter shown in Figure 8. The options available on the property dialog box for an object are similar to the options available on the shortcut menu for that object.

Figure 9. Property Dialog Box for a Meter

You can select multiple objects on the front panel or the block diagram and edit any properties the objects share. To select multiple objects, use the Positioning tool to drag a selection rectangle around all of the objects you want to edit or hold down the <Shift> key while clicking each object. Right-click an object from the selection and select Properties from the shortcut menu to display theProperties dialog box. The Properties dialog box only displays tabs and properties that the objects you select share. Select similar objects to display more tabs and properties. If you select objects that do not share any common properties, the Properties dialog box does not display any tabs or properties.

Each window has a toolbar associated with it. Use the front panel window toolbar buttons to run and edit the VI.

The following toolbar appears on the front panel window.

Click the Run button to run a VI. LabVIEW compiles the VI, if necessary. You can run a VI if the Run button appears as a solid white arrow, as shown at left. The solid white arrow also indicates you can use the VI as a subVI if you create a connector pane for the VI.

While the VI runs, the Run button appears as shown if the VI is a top-level VI, meaning it has no callers and therefore is not a subVI.

If the VI that is running is a subVI, the Run button appearance changes as shown.

The Run button appears broken when the VI you are creating or editing contains errors. If the Run button still appears broken after you finish wiring the block diagram, the VI is broken and cannot run. Click this button to display the Error list window, which lists all errors and warnings.

Click the Run Continuously button to run the VI until you abort or pause execution. You also can click the button again to disable continuous running.

While the VI runs, the Abort Execution button appears. Click this button to stop the VI immediately if there is no other way to stop the VI. If more than one running top-level VI uses the VI, the button is dimmed.

Caution: The Abort Execution button stops the VI immediately, before the VI finishes the current iteration. Aborting a VI that uses external resources, such as external hardware, might leave the resources in an unknown state by not resetting or releasing them properly. Design VIs with a stop button to avoid this problem.

Click the Pause button to pause a running VI. When you click the Pause button, LabVIEW highlights on the block diagram the location where you paused execution, and the Pause button appears red. Click the Pause button again to continue running the VI.

Select the Text Settings pull-down menu to change the font settings for the selected portions of the VI, including size, style, and color.

Select the Align Objects pull-down menu to align objects along axes, including vertical, top edge, left, and so on.

Select the Distribute Objects pull-down menu to space objects evenly, including gaps, compression, and so on.

Select the Resize Objects pull-down menu to resize multiple front panel objects to the same size.

Select the Reorder pull-down menu when you have objects that overlap each other and you want to define which one is in front or back of another. Select one of the objects with the Positioning tool and then select from Move Forward, Move Backward, Move To Front, and Move To Back.

The LabVIEW search can locate information in the LabVIEW Help, in the Controls and Functions palettes, and from NI support, community support, downloads, and product information sections on ni.com. You can configure which categories you want LabVIEW to search by selecting Tools»Options and selecting Search from the Category list.

Select the Show Context Help Window button to toggle the display of the Context Help window.

Enter Text appears to remind you that a new value is available to replace an old value. The Enter Text button disappears when you click it, press the <Enter> key, or click the front panel or block diagram workspace.

Click the Clean Up Diagram button to automatically reroute all existing wires and rearrange objects on the block diagram to generate a cleaner layout. To configure the clean up options, select Tools»Options to display the Options dialog box and select Block Diagram: Cleanup from the Category list.

The other buttons unique to the block diagram toolbar are primarily used for troubleshooting and are covered in the Debugging Tools document