top of page
Search

Device Error Handling in the Lab Environment

Updated: Aug 7, 2020

You certainly can't expect automation devices to work every time. Once you get a system dialed in, they have impressive repeatability, but you still need a solid contingency plan for device failures in the middle of a run. You can find ways to deal with this by utilizing the try/catch strategy. In essence you are telling your program that the process is delicate and may fail, and then you can provide instructions for how to react to those failures.



Here is an example of a script using the try/catch to throw a dialog alerting the user to intervene upon to a hardware issue. As a general rule of thumb, one should use the instrument traces to provide info to themselves that help debug issues, you can do this by concatenating strings with your variables to provide useful information about the values that you feed in as parameters. You can see how the method shown is doing this to show---



General Error Handling


Below is an example of general device error handling dialog that I use as a standard when approaching this type of work. This dialog provides 3 basic options, which I have found to be pretty well encompassing of the required actions one should take: retry the command, ignore the command and press on like nothing happened, or abort the method. First of all if you use this strategy, the devices will automatically pause while your error handling dialog awaits response. This particular dialog also accepts an input parameter of strMessage, which is a variable defined to accept and display actual the Error Message here where you see the red text.


Retrying will allow you to reset the labware on your instrument (if needed) and take any action needed to bring the device back into ready condition to accept the job, then you can try again and proceed from there upon success. Ignoring the command can be a quicker route sometimes, if you manually perform the task and then place your labware back into a position to proceed as if the command had originally executed properly. And sometimes the issue is to sever, and the whole run must be aborted.


This setup can be set up like in the code shown below, where you will start by creating a while loop to control the flow of action. This will tell the script to keep repeating that action until you tell it otherwise. This also requires a simple boolean variable as a 'flag' that you can use to actually flip that switch and kill that loop. Within this loop, the strategy is to try complicated actions, like sending a command to a peripheral robotic device. Here in the example shown below, that device is a robotic decapper for handling sample tubes.


So when the portion in the try block of code fails for any reason, the dialog above will read that error message and then pop up to display that info for the user. If the user were to select retry on that dialog, then the while loop is not broken and we will again to execute the code in that try block. If the user were to push Ignore, then we set our boolean flag variable to false, indicating that the loop is broken and that the script should proceed with everything after that try block as if it happened as expected.



Contingency Action


Using the catch portion of the code, you can also set up automated actions to respond to known errors. Here is an example of how I like to parse the error message to figure out what happened, and then overtime you can program in specific actions to these captured errors if the system supports. I do this by searching for expected string values within that error message received.


You can see here that the dialog response strategy is the same as the example above. When integrating devices into my methods, I begin with a general strategy trying to carry out the command, and then my response dialog allows for retry, ignore, abort. This is flexible enough to allow the lab to keep most experiments moving along even if a device goes down or has an issue.


4 views0 comments
bottom of page