Double the tester output instantaneously by testing two boards at the same time. The concept of running multiple tests in parallel translates directly to an increase in production throughput and efficiency. Parallel test is like multi-threading in software coding terms. The main test program sequence branches out onto multiple parallel paths with each performing its own set of test actions. Eventually, these parallel paths merge back to the main sequence after completing their respective tests and the main sequence collates the results for reporting.
Pathwave Test Executive for Manufacturing (PTEM) has a test step that supports parallel test operation. The parallel test executes all its immediate child steps in parallel and waits for all parallel paths to be completed before moving onto the next step. This enables you to create and execute multiple sequences. The common usage of parallel test steps is to perform testing at the same time. In Figure1 below, the parallel step has two immediate child steps named Sequence1 and Sequence2. When testplan execution enters the parallel step, Sequence1 and 2 will be started at the same time. The sequences may not necessarily have identical number of steps, and the parallel step waits for until all parallel child steps complete their run before exiting to the next step. The example in Figure1 shows a typical use model for a parallel test step where sequence1 and 2 are two separate groups of actions, each performing its own task to test one of the units under test (UUT) in the test plan. These can also be a set of data processing steps to perform data mining or analysis of large data sources in parallel.
Figure1: Parallel step executes immediate child steps at the same time for parallel testing
The parallel step can also become a watchdog sequence where it continuously watches certain values or parameters while testing is going on in a separate thread. Figure2: shows a running testplan for the Keysight i7090 automated inline in-circuit test (ICT) system. The parallel step has a group of steps to watch for any error codes coming from the automated handler and a separate group that does the test executions itself. The error monitoring group loops endlessly until an error is detected while the test execution group carries out the tests.
Figure2: Parallel test step in watchdog loop to watch for errors during test execution
Each of the parallel paths requires exclusive access to the instruments and test resources to avoid any conflict when the multiple test steps try to access to the same instrument or resource. In PTEM, generic SCPI instrument plugin has the capability of locking its instrument locking the command queries. This creates a queuing system for the instrument and manages the incoming flow of commands to prevent conflict. Multiple test steps from different parallel paths can send their commands to the same instrument at the same time and let PTEM manage the execution.
Figure3 shows the generic SCPI instrument setup in PTEM using the Lock queries option. PTEM manages the command queue using the VISA address of the instrument, so it is independent of the testplan. As PTEM allows multiple instances of execution, it is possible to have multiple testplan running at the same time calling for the same instrument without conflict.
Another available choice is the Lock instrument way. The concept is like Lock queries, but Lock instrument manages the queue at an instrument level instead of command level. So, when a testplan runs and opens the SCPI instrument’s VISA address, that testplan obtains exclusive access to the instrument and other testplan will have to wait until the first testplan releases it. Both options provide you with the flexibility to decide how the testplan will access the instrument.
Figure3: SCPI instrument lock queries/instrument allows sharing of instrument resources.
For other instruments plugins that do not offer the locking feature, PTEM provides a Lock step that lets you create a mutex and then executes its child steps within. If you have multiple paths of test steps that will access to the same instrument, you may put these steps under the child of the Lock step and assign it with the same mutex. Lock steps using the same mutex will wait for each other to release the mutex before executing. So, this prevents the possibility of two or more test steps trying to access the same instrument.
Figure 4 shows an example of a testplan using the Lock steps to execute tests for 3 UUT in parallel. The parallel test step holds 3 groups (Test UUT) of child steps, one for each UUT. Once the testplan execution reaches the parallel step, all 3 child groups will start executing at the same time. So, to prevent conflict within the child steps when accessing the same instrument or resource, the Lock step is used to hold the test steps of each UUT group.
All 3 Lock steps set its lock name as TAP_mutex1. Whichever group starts the Lock step first will complete its execution while the other groups wait for the mutex to become available. There will be other test steps within each group that may not need to have exclusive access to instruments or resources. Place these steps outside of the lock steps so that they will run in parallel at the same time. The output panel in Figure5 is the result of the testplan execution of the UUT test groups with the lock steps. Each group consists of two test steps that are not locked. You can see that these steps are executed in parallel at the beginning where their timestamps are the same. The execution then enters the Lock step of each group and in this example, the group for UUT2 secures the mutex and gets to go first, followed by UUT1 and UUT3.
Figure5: Lock steps run sequentially in parallel group
Notice that with lock steps, the test becomes sequential. This is because each test group under lock needs to wait for the earlier group to complete before starting its execution. This defeats the purpose of parallel testing. So, use lock steps only when there are no other options available.
For more details on the commands and sequences for the control of the i7090 handler, you can refer to my earlier posts on Keysight i7090 with PTEM-Auto Mode. Also check out the series of posts on test automation with Keysight i7090 using PTEM to find out more.
You are welcome to contact me if you have any questions or comments.
Stay safe and happy.