Doing Batch Model + Parallel Model test

[ChevyVolt1]

I have a scenario now where we have a batch of, say, 32 units to test, one unit after another.

I set up a Controller sequence with Batch Synchronization steps (for this, let's say I have just one pair of Batch Synch steps). The Batch Synchronization is set up to process each unit in a serial manner. Sandwiched between the batch synch steps is a Sequence Call that processes the test.

Now, due to a redesigned test equipment setup, I want to change the logic so that the same controller gets x number of units, say, 4 units from the batch, and starts the test in parallel -- 4 units can be tested in parallel. Get the next unit when one unit in the "4-batch" completes, repeat until the original 32 unit batch pool is empty. I checked with TestStand's Batch Synchronization settings, and all it has is Parallel (All Threads Enter Simultaneously). 

Is there a way to grab 4 test sockets from the original batch, and pass it to the "4-parallel-batch" Sequence Call, and keep getting the next unit until the original 32-batch pool is empty? I checked with the TestStand examples, and they appear to use "all threads enter simultaneously" literally. If there are examples like this, please let me know as I'm not finding the right ones.

I have some ideas, but I'm not sure if they're appropriate (read: best practices). Basically do a Batch Synch in serial, but maintain a running variable of the number of units being tested (each test using a "New Thread" Sequence Call execution) vs the remaining number of sockets to test, and repeat until remaining = 0, and number of units being tested = 0 (along with a timeout value to prevent infinite loops)

[Oli_Wachno]

So you want to slice the batch and queue the slices for processing?

IMHO you'll have to modify the Batch Process model for that.

I am sure this is possible, you'd have to modify the way, the (talking of the ProcessModel here) ControllerExecution communicates with the SocketExecutions.

Though I am unsure about the efforts needed and the costs for maintenance of such a solution compared to the benefits.

Having said this, I enjoy learning new things every day 🙂

[santo_13]

Here is how I would call it, you got a sub-lot of 32 units, and your test system is capable of testing 4 units in a batch (parallel with enough test hardware).

Now, what is the significance of those 32 units? why not treat it part of the larger lot of units instead of considering these 32 as a set?

[ChevyVolt1]

Santhosh,

Good question. It's a thermal chamber used for environmental stress testing. The setup inside the chamber allows for up to 32 units to be tested during a single chamber operation (say at extreme cold or at extreme hot). We have the hardware to test in parallel a few of those at a time, one mini-group after another, until all 32 units have been tested. When the chamber is at a certain extreme temperature, we cannot just open up the chamber and swap out the units with new ones to be tested. As it is now, all 32 gets the same thermal treatment, but waits their turn to be tested with 3 others in a group of 4, for example. 

We already have another thermal chamber with a similar setup, however, this one tests the batch in a serial manner, one after another. We want to cut down testing time dramatically by increasing the number of units that can be tested in parallel (from 1 to 4 would significantly cut down on testing time). 

[ee-jallen · Accepted solution]

"We have the hardware to test in parallel a few of those at a time"

This is the key point.  What hardware do you have in parallel; I imagine at minimum you have Power Supplies.

• Use Batch Process Model
• In your sequence use "Auto Schedule" step.  This step will automatically insert a "Use Auto Schedule Resource" step and section. Setup resource lock strings in the Use Auto Schedule Resource "configure" settings. For example your Power Supplies can be used for the resource lock; "PS1", "PS2", "PS3", etc
• Teststand then uses the lock string to control the sockets.  Whichever sockets get the locks first, those sockets will run test in parallel.  The other sockets wait until a resource lock is released and then starts. Other areas in your sequence that need to use different synchronization can do so using Batch Synchronization steps sections (One at a time, one only others skip or parallel mode)

Please look at the Parallel Testing Strategies Demos that install with TestStand (C:\Users\Public\Documents\National Instruments\TestStand 2019 (32-bit)\Examples\Demos\Parallel Testing Strategies).  The "Auto Scheduled (Additional DMM)" sequence is a good starting point. Run the demo to see how various testing can be setup.

Copy it and examine all of the settings and variables that are used.

[ChevyVolt1]

Thanks ee-jallen, I came here to report that the Auto Scheduler step did exactly what I wanted. I have a working proof of concept underway. I'll mark your reply as the solution. 

Thanks all!

[santo_13]

Auto Scheduler can do the job, but be aware it is very capable but complicated to get it correct in the first attempt.