There are two approaches to implementing parallel test systems inside TestStand. You can create your own parallel mechanism and call sub-sequences in new threads. Alternatively, you can use the two new TestStand "models" that abstract all of this work into pre-built sequences.
Do It Yourself
To launch a test sequence in parallel is, in itself, very simple. First, you have to define the sequence you need to run in parallel, and then you configure its options to run in a separate thread. (See Figure 3.) However, running the sequence in parallel is only a part of the problem. If you need to resynchronize the application after you have launched the threads, you need much more development time. For example, you may have to wait for threads to complete before you can launch the next set of steps. In TestStand, synchronization step types provide this low level control. We will discuss this further on in the article, however, a better approach that involves less development time is the new TestStand models.
Figure 3. Configuring a sequence to be called in a new thread using step settings.
Use TestStand Models
The two new models introduced in TestStand 2.0 are Parallel and Batch. We use these models, just like the original Sequential model, to produce a framework in which our tests run. The models define the order, or flow, of the test system, defining and controlling common tasks such as reporting, database reporting, logging in and out, and serial number information. They also provide placeholders for custom tasks such as pre and post-UUT tasks. For example, you can control the fixture to load and unload the device before and after testing. The models are themselves sequences, so you have free access to define custom sequence structures. (See Figure 4.)
Figure 4. TestStand Process Model
The parallel and batch models differ in the way they handle multiple boards. The batch model defines that the boards are synchronized at the start and end of the test sequence, and also potentially between. This is a natural model for testing a batch of products undergoing environmental screening, where sets of units are tested together inside a temperature chamber or a vibration rig. The parallel model, by comparison, tends to act on the units completely independently. This behavior is much more applicable to end-of-line functional test, where a number of units may arrive at different times, providing there is a test fixture to hold the DUT then the test system starts to cycle through it. We show a flow diagram for these models below. (See Figure 5.)
Figure 5. Flow Diagram of Batch Model and Parallel Model
Using these models to define a test system now becomes a relatively simple proposition. For example, if we have defined a set of tests inside TestStand that we wish to run on a batch of DUTs we simply need to configure our model to be BatchModel, by choosing Configure... Station Options... and then selecting the Models tab. (See Figure 6.) We then select our type of model from the ring control. Having told the system that we are running a batch process, we now need to define now many DUTs we are testing at the same time. Again for this we select the Configure... menu and then Model Options... that appear as we moved to a multi-UUT capable model. Now we can select the number of Test Sockets that we will provide for the UUT. (See Figure 7.)
Figure 6. Use the Station Options Configuration Panel to select your target model.
Figure 7. Use the Model Options Configuration Panel to set the number of test sockets.
With these options now configured, the test sequences, or steps, which you have developed in the sequence editor now run in parallel with an initial dialogue for entering the four serial numbers. The four instances of the tests are each run on a separate thread, all of which are created automatically by the batch model. These threads are synchronized at the start of the execution, and then, they are resynchronized before generating the reports and being destroyed by the model. (See Figure 8.)
Figure 8. Simplified View of Sequence Execution in the Batch Process Model
This sequence execution scenario is obviously very simplistic and assumes that all tests need to be run in parallel. However, this is not the case for most test systems where, potentially, you want only one of the threads to execute the test step. For example when controlling an environmental chamber, you may want to serialize a set of steps, i.e. each thread waits until the previous thread has completed before testing a step. Using TestStand, this is again simply a matter of configuration.
For example, let us assume that we have a simple set of three tests to be run on a batch of DUTs, Configure Chamber, RF Test, and Vibration Analysis. (See Figure 9.) The Configure Chamber test, we may want only one thread to execute, as it is talking to a PLC, and if all four threads spoke it may confuse the chamber controller. For the RF Test, we may have limited instrumentation and so we need to complete the tests on our DUTs one at a time, thread0, thread1, etc. where the test running on thread1 only executes when thread0 completes. For the final test, Vibration Analysis, we may need all of the DUTs to be measured in parallel to reduce test time. You can configure this with TestStand by selecting the properties of each of the steps, highlighting and right-clicking the step, and then selecting their synchronization properties. (See Figure 10a, b, c.)
Figure 9. Simple Three-Step Sequence in TestStand
Figure 10a. Use the Batch Synchronization to set the Configure Chamber step to only execute one thread. "One Thread Only (First Thread Execute Step, Remaining Threads Skip)"
Figure 10b. Use the Batch Synchronization to set the RF Test step to only execute one thread at a time. "Serial (One Thread at a Time)"
Figure 10c. Use the Batch Synchronization to set the Vibration Analysis step to execute all threads in parallel. "Parallel (All Threads Enter Simultaneously)"
By implementing the batch properties on each of the steps, you have massive flexibility on how you want your system to operate. You can create complex parallel systems in a very short time.