batch process model intergration with a thermal chamber

[JacobM123]

HI

I modified the batch process model to use my own dialog (defined in labivew).

the dialog includes information about temperature cycles, for example I want to repeat the test several times at different tempertures while taking advantage of the parallel batch model.

I figured out how to repeat the MainSequence within the sequenctial model and I now have a customised model which repeats the test for different temperatures in the thermal chamber.

I want to do the same with the batch model but I do not which steps within the "Test UUTs" sequence to put a "for each" step around.

I modified the "PreBatch Callback" to include the extra information about temperature cycles and have a vi which controlls the chamber and returns to test stand once the temperature has settled.

Where in the batch model do I need to put the temperature control VI?

how do I modify the batch model so I can repeat the tests at temperature?

[dug9000]

Why modify the process model at all? You could just put your tests in a subsequence and loop on that in your mainsequence perhaps even passing parameters to indicate which temperature or other info that might be useful to have in the subsequence.

For the batch model you can use "One thread only" batch synchronization in your sequences for steps that do things like raise the temperature of the chamber. All of the other test socket threads will wait until the thread running the "one thread only" step is done.

-Doug

[DowNow_]

Hi,

Using the One Thread Only property and putting the temp code in your client sequence would be a good solution. However, modifying the Batch Model is also a good solution. It's more advanced and complex and therefore will take significantly more time to perfect. The payback is it will be more scalable.

I worked at a place that put the temp chamber code in their client sequences and it was imho very messy. I'm sure it could be implemented "neatly," but just sharing my observation.

If you consider the temp chamber as part of your test process, then it would logically go in the process model. You could then use a functional test sequence with the sequential model on the bench, and use the same sequence with the temp-batch model in the chamber.

In answer to your question, Test UUTs -- Test Socket Entry Point is the sequence you'd put your temp chamber commands into. I would do lots of prototyping to make sure you understand everything. Another thing to consider is, the batch model naturally works with one temp "segment" for each iteration of the batch. For example, the first iteration of the batch could be soak at room temp, the second iteration ramp to high temp, the third iteration is soak at high temp, etc. You would then run a test sequence (or not) during each segment. You have to make sure you are collecting results correctly. It's not an easy thing to do, but I've done it and I know one other guy who has too. I'd only do it if you have a lot of temp cycling in your future 🙂

cc

[JacobM123]

well we do a lot of temperature cycling here, and we like to run the temperature cycles over night and have the chambers automatically progress to the next cycle after a test of a UUT. which is why I was putting it in the process model so that the code can be shared and we have the option of running the same sequence on the bench just by selecting another process model.

I was editing the sequence "test uuts" why would it go in the the other test uuts sequence? my understanding of the comments in the process model is that the other entry point is the entry point for each uut in the batch. So If i want to perform temperature cycling on all the units in the batch I would need to modify the "test uuts" sequence?

[dug9000]

Which version of TestStand are you using? The models changed quite a bit in TestStand 2012.

You likely do want to make the change in the "Test UUTs -- Test Socket Entry Point" because that is where the MainSequence is called in each test socket thread. Probably the easiest thing to do is add a step right after the mainsequence callback call that uses "One-Thread Only" batch synchronization and do whatever you need to do there. You can also add a step right before mainsequence callback but in that case I think you should also add a step right after mainsequence callback that does batch synchronization on an empty statement step to ensure that all of the socket threads complete their mainsequence call before you loop back around to call mainsequence again because the way batch synchronization works is that earlier steps in the flow of execution go first and it does not know about looping so it just looks at the order of the steps, so a step before the mainsequence callback would be considered earlier than a step inside the mainsequence callback even if it is really being run later due to looping.

Hope this helps,

-Doug