Labview Error Handling

Labview vi when programmed neatly with error terminals could be a good repeatable code. Any new applications for vi would successfully pass error out to the error out terminals of the vi which means developers find bugs by only monitoring inputs and outputs of the vi without requiring to look deep into the code. Here is an example of block diagram of a vi with error terminals properly wired when there is no error on input node ‘error in (no error).

Labview Error No Error case

The case structure will execute ‘No Error’ instance when there is no error and functionality code in this case will be executed. If there is error on the error chain, case structure executes ‘Error’ case as shown below. In this case, the executed Error case turns red. Such colour segregation further helps with troubleshooting labview code especially when hundreds of vis are coded within application.

Also note, the vis in No Error case are wired on the error chain. Within each vi, there is similar structure of No Error and Error case as above. As a result, code functionality is executed when error chain is healthy otherwise it is bypassed. Such inherent fool-proof architecture helps with making a safe software application when we really do not want to execute code when an error is present in the system. On the other hand, designing by appropriately putting vis on the error chain and passing error out to Error Hander vis or present to operator for diagnostics could result in a very friendly and safe design.

Writing error handling code

Error or exceptions are usually events that occur which were unexpected. It could be difficult to prepare for all possible error that might occur and over-analysing and logical thinking might result in writing more code involved in catching errors than required to perform task that we originally set out to do. However, a software app that is written to automate an assembly line producing hundreds of production units for revenue would benefit greatly with stable and robust error handling code.

Labview I/O and logical errors

In labview, error would normally be classified into logical or I/O errors. I/O errors occur when app is trying to perform operation with external hardware or File I/O system. Logical errors are more tricky and occur due to bad coding. A good example of logical error is dividing numeric value by zero. Other programming language might result in CPU error causing OS to terminate software application.

Labview is great to interface with other hardware and perform File I/O functions but variety of errors could occur between labview and external hardware. When doing serial communication, baud rate must match between the two. There are often initialisation requirements that need to be met prior further communication or data transfer. A file must be opened prior to writing data into file. Possibilities of I/O errors are endless. IP errors are even more worrying as IP data is non-deterministic and order is never guaranted. Both sides of communication must be able to handle IP data and be able to put data back in order when it arrives out of order or goes missing.

Error Clusters

Error clusters consist boolean control, error code and error description. Boolean control is set to true and error code and description are populated in the event error has occurred. Adding Error terminals to vis is excellent programming practice not only to capture errors but also to introduce the order of execution in labview code. Order of execution ensures part of code executes in order we anticipate otherwise labview data flow nature might result vi to wait indefinitely for data to arrive at its input terminals. Also note, most non-user defined errors will have boolean value false if it is just a warning but still provide error code and description within error cluster.

Error code are great way to determine reason for error. Error code value is zero when there is no error on error chain. To get further help about error, simply type in error code in ‘Explain Error’ from help menu.

Programming custom errors and General Error Handler VI:

It is also possible to create custom errors to achieve desired control on application. Labview reserves error codes 5000 to 9999 for user defined errors. Accordingly, a prudent programmer would produce a deliberate error on error wire if desired conditions are not satisfied. Further, programmer can help app user to find where in app error occurred by appending ‘call chain’ and date and time detail within error cluster string description.

General Error Handler VI

General error handler vi could be used to add details of custom errors. In this way, both user defined and non-user defined errors could be handled using built in labview vi. General error handler provides further flexibility by allowing operator to be able to clear error or set error as well as alter error description and error code detail within error cluster. Such built in features could assist with developing very robust and reliable application without spending much time programming error handling code from scratch.

Simple Error Handler vi

Simple error handler vi could be used to halt code execution by displaying a pop-up dialog to operator when an error occurs. It provides an easy way of prompting user that error has occurred. The disadvantage is obviously execution halt which would prevent app from running until user has either stopped vi or clicked OK to continue execution. Usually these are wired as the last step in code execution and error is handled or logged within Error Module. By wiring simple error handler vi as the last step in code diagram, code stops gracefully displaying a pop up window showing cause of the error and the error code. Here is how to wire as the last step in the code diagram.

In this article, I briefly went through errors and error handling tools available within labview. I hope developer would benefit with information to develop robust labview apps.