Multiple Temperature environments in Test stand

[Norbert_B]

You should use the batch synchronization steps and select "One Thread Only" to set the chamber temperature. As Dennis already stated, you should loop inside your MainSequence as often as you have temperature points to test at.

So the general layout of your Main would be:

1. StartLoop 

2. Set temperature (Batch Synch step with "One Thread Only")

3. Perfrom UUT specific tests

4. Goto StartLoop (New temperature)

If there are no temperatures to set left, just don't repeat the loop.

The only thing which does not work as you want to have it is the report. The report is made by the process model only if you leave the MainSequence. Since you are looping inside the Main, the report functionality of TestStand does not work for you.

There are several options to solve this, but i think two of them are the ones which might suit you:

a) Implement your own reporting (worksome!). Advantage: The report is done when you want it and looks exactly like you like it.

b) Do not loop in the Main, but within your process model. This requires quite deep knowledge in TestStand or otherwise you will mess up the model. The points you have to alter/override are: PreUUT and PostUUT. Regarding report you maybe even have to change it as well....

A third option i suggest you to look into would be

c) Use the deafult reporting. Your report will automatically include a full report for each loops iteration, which means a full report for each temperature. This does not concur directly with your request (one report for each temperature), but it contains the same information.

hope this helps,

Norbert 

[WDLV]

Hi, I already use my own reporting that gets invoked after all UUTs at the partuicular temp. are done, not sure how to do it in a loop. Currently I had it set to run at the Post UUT step. I am thinking to have separate sequences that within them utilize the post UUT approach.

Like I stated earlier Step 3. "Perform UUT specific tests" is a different set for different temps. I suppose that also gets solved with invoking separate sequences.

Only question that remains is how do I synchronize so that all test sockets are run before report is processed. I am having trouble visualizing that

[Norbert_B]

You can use the steps from the synchronization palette to achieve this. I suggest you to use the Rendezvous if you need the report in each socket or, similar to the temperature chamber, use a batch synchronized section with one thread only for the report. The trick in the "One Thread Only" approach would be: How do you gather the information about all sockets in order to create the report? This heavily depends on your reporting mechanism and since it is not the default one, i cannot give you an image of a possible approach.....

Norbert 

[WDLV]

The way I gather the info of all sockets is a approach of appending to the report form each individual Thread. So, I have to synchronize to process all the appended data after exiting all threads before going to next temeperature.

[Norbert_B]

TestStand does that already for you. Therefore i am wondering why you have changed the report generation in the first place.

The only reason for staying at the custom made report is that you need a single report file for each temperature. If you can accept a single report file containing the results for all sockets and temperatures, i suggest you to use the default TestStand report.

Reagrding your posting: Each socket is an individual execution with its own report object. Each execution constists initially of a single thread, so if you do not create a new thread within your sequence (Sequence Call with "New Thread" setting), you will stick with one thread (called Execution) per socket. Each socket will pass its report information to the process model which will put together the reports from each socket in order to build a single report file containing all information about each socket.

The only thing the default reporting does not supply is the order you would have: The default reporting would add Socket0, Socket1, .... SocketN. It would not sort by Socket0Temp0, Socket1Temp0, ..., SocketNTemp0, Socket0Temp1, Socket1Temp1, ..., SocketNTemp1, Socket0Temp2, .....

So this is the only challange you have in adopting the default report generation. 

hope this helps,

Norbert 

[WDLV]

the reason is, it is a custom report based on our own test parameter gathering , and most importantly "processing". I have disabled the report generation of Teststand, generating basically a excel report for all sockets at a particular temp after all run at that temp.  I cannot use a "all" report at all temps, all sockets, that will not work for us.

I need to use a batch synch to run the report processing at cleanup of seq. 1(temp1), then seq. 2(temp 2) . Can I do that with a socket count index counter?

[Norbert_B]

TestStand keeps track of the sockets by default. You can find the socket number in the lookup string "RunState.TestSockets.MyIndex".

Just for clarification:

You have N different DUT (device under test) running the same testprocedures for each temperature. If that testprocedure is finished for each DUT, the sequence should create an excel report for each DUT and then proceed to the next temperature. The testprocedure for this temperature is different to the procedure of the previous temperature. But the reporting should take place in the same manner for each temperature?

If yes, you should use the following setup:

Run your client sequence file using the batchmodel. The sequence should be made up using the following "style":

- Set temperature (Batch Synchronization step set to One Thread Only)

- Run subsequence for the given temperature (either multiple sequence call steps using preconditions or a single sequence call step using an expression in order to call different subsequences)

- Run reporting mechanism. Note that you maybe have to use locks in order to prevent race conditions between the sockets if writing to the same sheet

That's basically everything you need. Please note that using the sequence call you can even take account of the testsocket index if necessary.

hope this helps,

Norbert 

[WDLV]

The "run reporting mechanism" step has to be after all N DUTs run at a temp because it operates on concatenated DUT data. And that is what I was asking, if I cound synchronize to run that after N DUTs execute all "subsequence Test steps for given Temp"

[Norbert_B]

This depends if the testsockets have to run the reporting in a sepcial order or not.

If not, simply embed the reporting in a Batch Synchronized Section set to "Serial".

If the order matters, you should "collect" all sockets using Rendezvous and then run the reporting in the given order. This is a bit more complex, but still solvable.

Norbert

[Edit]: Ordering the execution of the reporting would require using Notifiers 

Message Edited by Norbert B on 12-03-2009 03:32 AM

[WDLV]

What do you mean by "special order"?  The batch model determines order of testsocket execution.

After all n DUTs execute sequentially , and finish, the "process report" must be invoked.

If I embed a batch synchronized section for it, set to "serial", will it execute after all testsockets have finished executing?