Automation Errors? Get to know your error codes!
2020-04-30 | 5 min read
Murphy’s Law says, “Whatever can go wrong, will go wrong”. This applies to coding of your test applications too. With the simple commands discussed in my “Test Automation In your Hands” post, you can easily interface your application to the FlexiCore handler system, and have it work the way you like it.
But what if errors pop up? Well, here’s where I will share some tips on error handling of the system so that your application will not be stuck in an infinite loop. Error handling is essential in all coding work. It allows your application or test plan to trap error conditions and manage it with the appropriate follow-up actions.
Let’s use a day-to-day analogy. Imagine you are at your favorite food joint. You place your order and patiently wait as the kitchen prepares your order. Twenty minutes lapse, but somehow your order isn’t ready. An hour passes, and you are still waiting. What will you do? Do you continue to wait silently? How much longer will you wait?
You probably walk up to the counter and ask for a status of your order. You want to know what is wrong with the order so that you can decide what to do next. Do you continue to wait? Or do you cancel that order and place a new one? Or do you get the manager to investigate the problem? This is error handling. And you won’t want to wait an hour before handling it.
In an automated handling system, the handler uses an array of sensors to monitor the operation sequence. When the behavior of the sensors does not follow the expected sequence, that constitutes an error event.
In an error event, the handler stops all movement and sets the corresponding error flag. The handler flashes the light tower in amber to indicate that the system has encountered an error. At the same time, a unique error code generated by the handler’s firmware describes the nature of the error. But when does your test plan check for errors? Real time checking is ideal, however, it’s not feasible as it generates significant digital traffic and may overwhelm the computer’s CPU.
Look at the different stages of the operational flow below. Each of the commands triggers the start of an operating stage in the handler. From the user testplan point of view, after the SfpH:ToFirstRun command is issued to start the test operation, the test plan goes into loop to wait for the handler to be ready by checking the AutoStart flag with the SfpH:ChkAutoStart? query before it conducts its test operation. At this point, the handler’s firmware works to engage the upstream system for the transfer of the unit under test. If there is any error event, the handler stops. Checking for errors with the SfpH:ChkErr? query within the loop will allow you to exit from the loop if an error does occur. This will prevent the execution of the testplan from getting into an infinite loop if the handler stops as a result of an error event.
The SfpH:ChkErr? query returns a string value that represents the error code. The user can map the value against the error code list and take the appropriate action to rectify the problem. An error event happens when the UUT is stuck, dropped, or delayed from reaching its designated position. As such, all error events should require the user to intervene and investigate before having the testplan automatically clear the error state and resume operation.
Great! You are all set to create your very own test application to control the FlexiCore Handler system for some basic test or programming operations. Happy coding!
As always, feel free to drop me an email (firstname.lastname@example.org) with your comments or questions.
Stay safe and stay healthy!