{"id":303,"date":"2018-07-31T20:51:23","date_gmt":"2018-07-31T19:51:23","guid":{"rendered":"http:\/\/controlsoftwaresolutions.com\/?p=303"},"modified":"2018-07-31T20:51:23","modified_gmt":"2018-07-31T19:51:23","slug":"error-handling-strategies-labview","status":"publish","type":"post","link":"https:\/\/controlsoftwaresolutions.com\/error-handling-strategies-labview\/","title":{"rendered":"Error handling strategies in LabVIEW"},"content":{"rendered":"
David Maidman –\u00a0 Control Software Solutions<\/strong><\/p>\n Error handling is an essential part of a professional LabVIEW application, however is something that is often overlooked. Without adequate error handling applications can be hard to debug, provide a bad user experience and in the worst case can cause damage to equipment, loss of data and even injury.<\/p>\n When starting out with LabVIEW one of the first things we are taught is the importance of error handling. In these early days the general advice is that we should always enclose block diagram code in an error case and that we should always wire errors between our subVIs. However, in practice this advice does not always provide an adequate error handling strategy when creating professional applications, and in some circumstances causes more problems than it solves.<\/p>\n Often when an error occurs, rather than passing it downstream it can be dealt with there and then. How you handle the error depends on the specific error and the software requirements. Often when an error occurs we might decide to handle it locally by one of three ways; ignore it, modify it, or retry.<\/p>\n Sometimes it is possible to simply ignore an upstream error. One common example might be a communications timeout error when reading from a TCP connection. In the case of a timeout the read VI returns an error because it failed to successfully carry out its primary job, however in the context of your application this might not be seen as an error and therefore it can be cleared (for example it could be that there are no messages to read).<\/p>\n Figure 1 clearing a timeout error<\/em><\/p>\n Figure 2 example of how a specific error can be cleared<\/em><\/p>\n Some errors may provide information that can be used downstream, even if you do not consider them to be errors. In this case you could choose to downgrade an error to a warning. In this case the error cluster retains the useful information, however does not prevent downstream code from executing. One example would be when creating a new directory: if the directory already exists an error will be generated, however if the reason you are creating the directory is simply to ensure that it exists then you might not want an error to be generated.<\/p>\n Figure 3 downgrading an error to a warning<\/em><\/p>\n Another reason you might want to modify an error is to change the error code to one specific to your application.<\/p>\n Figure 4 changing a default error code to one specific for the application<\/em><\/p>\n Sometimes you might only be interested in an error if it occurs a number of times. An example might be when attempting to initialise a DAQ device when the device has not been connected. In this example you might clear the error and then retry.<\/p>\n Figure 5 implementing a ‘retry on error’ strategy<\/em><\/p>\n You might not always want to handle errors locally and therefore it might be necessary to pass error information to another module to be handled. In this case you can use queued message handlers if you have a dedicated error handling module, or by user events if you want modules (for example a state controller or user interface) to subscribe to error messages.<\/p>\n Figure 6 adding errors to a queue to handle in another loop<\/em><\/p>\n <\/p>\n Figure 7 publishing errors as events to be handled by subscribing processes<\/em><\/p>\n In practice you are likely to use a combination of local and central error handling depending on the requirements of your project.<\/p>\n Figure 8 do not enclose shutdown code in an error case<\/em><\/p>\n <\/p>\n Figure 9 merging incoming errors with the output error stream to ensure the shutdown code executes<\/em><\/p>\n For more information on any of the topics you have read in this article, or for more information on LabVIEW programming\u00a0contact us<\/a>:<\/p>\n","protected":false},"excerpt":{"rendered":" David Maidman –\u00a0 Control Software Solutions Introduction Error handling is an essential part of a professional LabVIEW application, however is something that is often overlooked. Without adequate error handling applications … more Introduction<\/h1>\n
Local Error Handling<\/h1>\n
Ignore<\/h2>\n
<\/p>\n
<\/a><\/p>\n
Modify<\/h2>\n
<\/a><\/p>\n
<\/p>\n
Retry<\/h2>\n
<\/a><\/p>\n
Asynchronous Error Handling<\/h1>\n
<\/a><\/p>\n
<\/a><\/p>\n
Error Handling Guidelines<\/h1>\n
\n
<\/a><\/p>\n
<\/a><\/p>\n
Further Information<\/h2>\n