Which model to choose

[mkossmann]

We have a device under test which specs require to measure it during up ramps of temperature cycles. Due to capacity reasons we need to test more than one DUT in one cycle. So neither the batch model nor the parallel model seem to fit for that problem because the batch model can't handle the parallel measurement during a temperature ramp ( it finally serializes all "parallel" measurements) and the parallel model seems to lack steps like the batch synchronization steps to provide steps which aren't run in parallel.( for controlling the temperature chamber).

Are there any examples , which handle such a mixed parallel /batch environments ?

[Norbert_B]

I don't understand your statement about the batch model:

it finally serializes all "parallel" measurements

Could you elaborate this?

In fact, the batch model requires the UUTs to be supplied in a "carrier"(batch). So if the first UUT has finished its test, this socket will wait until all other UUTs on the batch have been finished as well. But the tests of each UUT on a batch are in parallel as long as the environement (available instruments, code modules, ...) makes this possible.

So to conclude: The UUTs are tested in parallel using the batch model, but each socket has to test the same amount of UUTs over time (disregarding "empty sockets").

hope this helps,

Norbert

[mkossmann]

---

@Norbert B wrote:

I don't understand your statement about the batch model:

it finally serializes all "parallel" measurements

Could you elaborate this?

Yes, I made a thinko. I thought of an existing testsetup using batch here. using a switch to select the test socket to measure. And I forgot, that we had to use the "batchsync enter serial"  option here.

But there is still the problem that I   need some serialization/locking  for accessing the temperaturechamber.

The only way, I see now is the   "batchsync enter one thread only "  option here that das a "granularity" at Teststand step level. 

We have to realize a temperature cycle with a "down ramp" from 70° to -40° in 20 minutes and 2h at cold temperature with DUT switched off and then the up ramp ( -40° to 70° )in 20 minutes,hen  2h at 70° with DUT switched on and a test loop an running on the DUT (also during the ramp) . We have to  provide one testresult per cycle .   We have allready done such a temperature cycle for only one DUT  (serial modell) in a CVI-Code module. It runs a loop of testroutine calls  with a finishing condition decided by polling the temperature first and a then starting and polling a timer when temperature is reached.

Reusing this C Code module in a Batch model  requires that I add some locking  to avoid the following problem:

The module writes out some request to the temperature chamber, but can't read the result for now, because Teststand switches to another testsocket just before that. Then a another request is sent out and the temperature chamber becomes confused.

I've found so far no option for locking at Teststand  at CVI-Code module level. So I think, I have to rewrite the timing logic  from C into Teststand to realize the locking at teststand step level . Any Ideas to avoid that ?   Or ideas , which would allow us to write the timing logic still as C code module. because we have more experience in writing C Code than in Teststand Code.

[RayFarmer]

if I understand you correctly, you can set a step to run only one thread (this will excute the first and it will skip all remaining threads).

eg setup up your Chamber this only ends to be done once therefore the first call will do this and all the other testsockets will ignore this step.

[mkossmann]

Setting up the chamber is not the big problem but deciding when to finish the measurement.

Currently (for one  DUT) were are using something like that (written as  CV code module I):

Setup temperature chamber for Temperature ramp

Do

  Measure DUT

  Measure Temperature

Until  final Temperature of ramp is reached

Do

 Measure DUT

Until  time is reached

Pass if all DUT measurements are good

But with more one DUT the Measure Temperature  may break, if it is interrupted by switching to another DUT.

I can use Teststands step level locking  by making Measure Temperature a Teststand step  But that requires me to write the do loops and the summarizing for  the result also in Teststand  ( where I have much less experience than with writing in C) To make "Setup temperature chamber for Temperature ramp" a extra teststand step is indeed no problem.

[Norbert_B]

I think i understand what is going on:

You have a module running for a long time and this should work for all sockets.

This is not going to work and it is not suggested.

You should avoid implementing code modules which are blocking for a long time.

So the best solution for your requirement is to elevate the steps you mentioned into your test sequence. Small (limited in time during execution) modules perform the measurements, check for temperature and perform time keeping information. Using flags, you adopt the sequence flow to your needs (e.g. flag "Temperature reached?").

If you stick to large modules, you have to think about parallelism of the modules. For instance for LV modules, this would require to set them "re-entrant". Otherwise, the test sockets get serialized because of the module accesses. In addition to that, you are suggested to implement a "termination monitor" into each module, otherwise you would have to wait for the module to complete if you want to terminate. So terminating within seconds after the module execution will result in maybe 1h waiting time if the module is going to run 1h.......

hope this helps,

Norbert