Automated Testing Using PTEM
My earlier post on Reducing Test Development time with Pathwave Test Executive for Manufacturing (PTEM) shared the ease of working with a SCPI instrument in PTEM. Using this method, we have access to the low-level command sets of any instrument or application that supports TCPIP socket communication protocols.
Using the FlexiCore Inline parallel ICT system as an example, let’s look into the commands and response sequence of the inline handler system and create our PTEM testplan to control it. My testplan contains a SCPI instrument definition that targets the Handler Control Panel application which manages the FlexiCore’s handler operation. Through this, I can control the handler movements and generate a testplan sequence that performs automated inline testing. This allows me to automate almost any kind of test or programming operations. The details of the command and control of the FlexiCore Inline parallel ICT system are in a series of posts that I uploaded some time back.
Initializing the Handler
As with any other instruments, we want to initialize them at the start of a test operation. I do this by sending the initialization command SfpH:Init to the Handler Control Panel application.
The “SCPI Ext” test step lets me send commands or queries to the instruments. Software automatically adds the carriage return character to the end of each command/query, so you do not need to worry about forgetting to do so. The test step also allows the use variables to hold parameters in the command string. Concatenate multiple parameters, if any, into a single string as the test step allows for only one variable.
The initialization command does not carry any parameter, nor does it return any value. We can either use a fixed delay time to wait for the completion of the initialization sequence or take the initiative to check the system status and see if the sequence completes.
Initialization takes about three seconds to complete when there is no prior board present in the FlexiCore handler. Otherwise, the handler will take a little longer to purge the board inside before completing the initialization sequence. We can check the system status flag on the Handler Control Panel to know if the initialization is complete by sending the SfpH:HSTATE? “System Status” query.
In my testplan, I created a Repeat Ext loop (step name: Wait for Initialization) after the initialization test step to wait for the system status query to come back with a value of 1. Under the child step of the repeat loop, a query checks the System Status flag at one-second intervals. For my experimental testplan, I am letting this loop infinitely until the system status flag becomes ready. If I am to move this testplan into production, then it is better to create a timeout loop in parallel with this repeat loop such that it limits the duration for the initialization sequence.
Fig 2. The repeat loop monitors the system status while waiting for initialization to be completed.
Transfer Board into Handler
My next step is to start the transfer of boards into the handler for testing. Do this by sending the SfpH:ToFirstRun command (step name: Start Test Operation). The first run command sets the handler into auto mode operation. The handler negotiates with the upstream and downstream conveyors to manage the transfer of board in and out of the handler. This is transparent to the user, and I do not need to worry about the detailed sequence of the transfer at all.
Once the upstream conveyor transfers in the board, handler automatically engages the board into the test fixture and sets an AutoStart flag. For the testplan, it goes into the next repeat-until loop (step name: Wait for Start) to wait for the board to engage by watching the AutoStart flag. A query sends SfpH:ChkAutoStart? to update the status of the flag at an interval of 0.5 second within the loop. Once the status is correct, testplan can continue to the next step, which initiates the actual test sequences.
Releasing Board from the Handler
Upon test completion, I will release the tested board to the downstream conveyor. For this to happen, the testplan sends the test result (step name: Set Test Results) to the handler using SfpH:SetTRslt <1/0> where 1 indicates pass and 0 indicates fail. After I send the command, the handler continues to negotiate with the downstream conveyor to transfer the tested board out. This marks the end of one complete test cycle.
However, the test operation does not stop here. The handler automatically returns to the input state and transfers the next board for testing into the handler once it is available. Therefore, the testplan must return to the point where it waits for a new board engagement, and then continue the next test cycle. The cycle repeats itself until the user stops the testplan, or the handler runs into an error.
To allow the testplan to loop back, I created an infinite loop (step name: Main Test Loop) and moved all the test steps after Wait for Start into its child steps. This allows the testplan to always loop back to wait for the next board to test.
The testplan contains the basic command and sequences to control the FlexiCore Inline parallel ICT system. It is unable to determine when to break the test operation in cases of handler error or timeout. In the same way I used the repeat-until loop to watch the state of different flags along the test cycles, we can also create a set of parallel sequences to watch the error state of the handler. This can then become the background monitor for any unexpected conditions that may occur and help trigger a breakout of the Main Test Loop.
I do not intend go into the details of the testplan in a post that is already quite long. So, if you are interested in developing your own testplan for the FlexiCore, you are more than welcome to contact me.
Until the next post, stay healthy and safe!
Email me with your questions or comments!