LabVIEW Wiki - User contributions [en]

Error Cluster data type

2009-04-16T14:28:14Z

Wevanarsdale:

Aspects of error handling

2007-10-14T14:38:41Z

Wevanarsdale:

{{Template:ActiveDiscuss}}

This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.

[[category:LabVIEW fundamentals]]

Error Cluster data type

2007-05-08T03:20:09Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in LabVIEW 8.2 ([http://www.ni.com/pdf/manuals/371780b.pdf 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T03:18:13Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in LabVIEW 8.2 (see[http://www.ni.com/pdf/manuals/371780b.pdf 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T03:16:34Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in LabVIEW 8.2 ([http://www.ni.com/pdf/manuals/371780b.pdf page 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T03:14:13Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in [http://www.ni.com/pdf/manuals/371780b.pdf LabVIEW 8.2]. 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T03:11:32Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in [http://www.ni.com/pdf/manuals/371780b.pdf LabVIEW 8.2]. 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T03:10:20Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in [http://www.ni.com/pdf/manuals/371780b.pdf LabVIEW 8.2]. 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You could extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''. The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]


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

Error Cluster data type

2007-05-08T02:55:48Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Error_cluster_control_and_terminal.JPG‎|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

Note that the default terminal and wire color was changed from pink to dark yellow in [http://www.ni.com/pdf/manuals/371780b.pdf LabVIEW 8.2]. 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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.


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

File:Error cluster control and terminal.JPG

2007-05-08T02:47:09Z

Wevanarsdale: 3D error cluster control and terminal (LabVIEW 8.2 and 7.1)

3D error cluster control and terminal (LabVIEW 8.2 and 7.1)

Error Cluster data type

2007-05-06T22:52:24Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

Error Cluster data type

2007-05-06T22:25:11Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes. (referenced earlier)'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.

Error Cluster data type

2007-05-06T22:24:21Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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 Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes. (referenced earlier)'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-06T22:23:23Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes. (referenced earlier)'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T22:10:46Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes. (referenced earlier)'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' is available.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T21:59:35Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 '''and''' the range -9999 to -5000 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

{| class="wikitable" border="1"
|-
| For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.
[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]
This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. <s>You would have to extend this database to handle user defined error codes and provide some type of error log.</s> ''See General Error Handler.vi online help for two different ways of providing error descriptions for user defined error codes.'' For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

|This entire section of WIKI about "Error Handling" could benefit from a deep reading of the online help for the General Error Handler.vi. That VI has more facilities than folks typically know. FOR EXAMPLE:

The General Error Handler.vi includes an input parameter for the type of dialog, one option is "no dialog." I would STRONGLY recommended instead of calling "Error Code Database.vi". The primary reason for the recommendation is that the translation of error code cluster into human readable strings involves much more than just looking up text in the database. The '''source''' string itself may include information to override or extend the database, and the text in either the '''source''' string or the database may include formatting commands, such as HTML tags for bold face. Encoding information in the '''source''' string is a technique that will become more common in the future.

You may desire to display the text, fully formatted, in a string indicator of your own instead of in any dialog. Use the function of General Error Handler CORE.vi (found on the block diagram of General Error Handler.vi) to do this.
|}

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [http://forums.lavag.org/downloads.html&showfile=86 log event error] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T05:25:35Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI [[log event error]] for logging errors to the '''Event Viewer''' should available soon.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-05T05:22:46Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available [[log event error]].
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T17:43:44Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG|frame|center|'''Figure 1''': 3D error cluster control and terminal‎]]

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg|frame|center|'''Figure 2''': '''Explain Error''' tool]]

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG|frame|center|'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi''']]

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

[[Image:Fig_3-error_cluster_examples.JPG|frame|center|'''Figure 4''': structures, comparison and array functions involving error cluster inputs]]

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

[[Image:Comparison_function_indicators.JPG|frame|center|'''Figure 5''': typical indicators for both modes of a comparison function]]

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG|frame|center|'''Figure 6''': diagram for a simple error selector that does not detect warnings]]

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

[[Image:Error_selector_diagram_A.JPG|frame|center|]][[Image:Error_selector_diagrams_B.JPG|frame|center|'''Figure 7''': possible diagrams for an error selector that detects warnings]]

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG|center|thumb|600px|'''Figure 8''': producer-consumer diagram with error handling in the top loop]]

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg|frame|center|'''Figure 9''': connector for the '''Error Code Database.vi''']]

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10''' and '''Figure 11'''.

[[Image:Event_viewer.JPG|frame|center|'''Figure 10''': '''Event Viewer''' in Windows]]
[[Image:Event_properties.jpg|frame|center|'''Figure 11''':'''Event Properties''' in Windows]]

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:50:08Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties''' in Windows

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:45:44Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:45:12Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 3''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:28:07Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:24:54Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:21:26Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:19:27Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Producer-consumer.PNG]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Producer-consumer.PNG

2007-05-04T03:17:46Z

Wevanarsdale: producer-consumer diagram with error handling

producer-consumer diagram with error handling

Error Cluster data type

2007-05-04T03:11:48Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the '''Event Viewer''' is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:10:32Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:10:01Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:07:24Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The '''eventcreate''' command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:05:39Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]]
[[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T03:04:10Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

[[Image:Error_code_database_connector.jpg]]

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

[[Image:Event_viewer.JPG]][[Image:Event_properties.jpg]]

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Event properties.jpg

2007-05-04T03:03:16Z

Wevanarsdale: Windows Event Properties

Windows Event Properties

File:Event viewer.JPG

2007-05-04T03:02:03Z

Wevanarsdale: Windows Event Viewer

Windows Event Viewer

File:Error code database connector.jpg

2007-05-04T03:00:07Z

Wevanarsdale: connector for the Error Code Database.vi

connector for the Error Code Database.vi

Error Cluster data type

2007-05-04T02:58:04Z

Wevanarsdale: /* Error Handling */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

[[Image:Download high resolution version (804x499, 209 KB)]]

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:wevanarsdale|wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Producer-consumer diagram.JPG

2007-05-04T02:56:47Z

Wevanarsdale: producer-consumer diagram with error handling

producer-consumer diagram with error handling

Error Cluster data type

2007-05-04T02:54:17Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T02:53:52Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]
'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T02:52:55Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

Error Cluster data type

2007-05-04T02:52:14Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]][[Image:Error_selector_diagrams_B.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:wevanarsdale|wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Error selector diagrams B.JPG

2007-05-04T02:51:00Z

Wevanarsdale: diagrams for slower error selectors that detect warnings

diagrams for slower error selectors that detect warnings

Error Cluster data type

2007-05-04T02:46:38Z

Wevanarsdale: /* Error Selection */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

[[Image:Simple_error_selector_diagram.JPG]]

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

[[Image:Error_selector_diagram_A.JPG]]

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Error selector diagram A.JPG

2007-05-04T02:45:50Z

Wevanarsdale: diagram for a fast error selector that detects warnings

diagram for a fast error selector that detects warnings

File:Simple error selector diagram.JPG

2007-05-04T02:42:45Z

Wevanarsdale: simple error selector based on the Select function

simple error selector based on the Select function

Error Cluster data type

2007-05-04T02:40:54Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

[[Image:Comparison_function_indicators.JPG]]

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Comparison function indicators.JPG

2007-05-04T02:40:10Z

Wevanarsdale: typical indicators for both compare elements and compare aggregates modes of a comparison function

typical indicators for both compare elements and compare aggregates modes of a comparison function

Error Cluster data type

2007-05-04T02:37:30Z

Wevanarsdale: /* Error Cluster */

== Error Cluster ==

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.

[[Image:Fig_1-error_cluster_control_and_terminal.JPG‎]]

'''Figure 1''': 3D error cluster control and terminal

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''), with the range 5000 through 9999 reserved for user defined error codes. 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'''.

[[Image:Explain_Error_tool.jpg]]

'''Figure 2''': '''Explain Error''' tool

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 <labview\user.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.

[[Image:Fig_3-VI_connectors.JPG]]

'''Figure 3''': connectors for '''Error Cluster from Error Code.vi''' and '''General Error Handler.vi'''

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

[[Image:Fig_3-error_cluster_examples.JPG]]

'''Figure 4''': structures, comparison and array functions involving error cluster inputs

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

'''Figure 5''': typical indicators for both modes of a comparison function

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'''.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== 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 0 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''').

'''Figure 6''': diagram for a simple error selector that does not detect warnings

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

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

'''Figure 7''': possible diagrams for an error selector that detects warnings

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.
--[[User:Wevanarsdale|Wevanarsdale]] 21:18, 3 May 2007 (CDT)

== Error Handling ==

Every LabVIEW programmer has their own approach to handling errors. In fact, those with multiple personalities probably have several different approaches to handling errors. As an example, consider the producer-consumer diagram shown in '''Figure 8'''.

'''Figure 8''': producer-consumer diagram with error handling in the top loop

The “event loop” (bottom) produces enumerated commands that are processed by the “cmd loop” (top). The outer case structure in the top loop traps for errors that are placed on the lower shift register. The corresponding error case (not shown) allows error handling by “code” with different methods of notification. For example, a user interface application based on this design pattern might employ the '''General Error Handler.vi''' shown in '''Figure 1''' to display a dialog for particular errors. However, this method would not work for applications that run continuously without user interaction.

For continuously running applications, an error dialog (or any other kind of dialog for that matter) would disrupt execution, causing data loss or some other event you are being paid to avoid. Logging error information to file is a useful notification method for such applications. This approach requires an error description, which is provided by the '''Error Code Database.vi''' (see '''Figure 9''') for specified error codes in LabVIEW.

'''Figure 9''': connector for the '''Error Code Database.vi'''

This locked VI, located in the library <labview\vi.lib\Utility\error.llb>, is easily found as a subVI of the '''General Error Handler.vi'''. You would have to extend this database to handle user defined error codes and provide some type of error log. For example, some Windows applications log errors to the '''Event Viewer''' (right-click on '''My Computer''' and select '''Manage''' from the popup menu) shown in '''Figure 10'''.

'''Figure 10''': '''Event Viewer''' and '''Event Properties'''

The eventcreate command can be used in Windows to log events to this application. A VI for logging errors to the Event Viewer is available here.
--[[User:Wevanarsdale|Wevanarsdale]] 21:17, 3 May 2007 (CDT)

File:Fig 3-error cluster examples.JPG

2007-05-04T02:36:30Z

Wevanarsdale: structures, comparison and array functions involving error cluster inputs

structures, comparison and array functions involving error cluster inputs