Batch Test With Parallel TestSequen​ces

Question

Need a little assistance programming a TestStand batch sequence also containing test sequences which must run in parallel with synchronization.
I have a panel containing multiple UUT. Each UUT consist of 2 parts. The test may be divided into 4 groups:
1: Common start up test and programming
2a: Specific test and calibration on part 1
2b: Specific test and calibration on part 2
3: Common test and calibration of complete UUT
My application runs with the batch model (which I normally use and is familiar with), but must in this case also use parallel testing for each UUT. I need to be able to synchronize the parallel test sequences like they where running in normal batchmodel. I also need at some point to synchronize the to parallel sequences for all UUTs.
I’ve succeeded doing that with the enclosed sequence, but I am not sure it’s the right solution. Would like some comments.
Attachments:
BatchTestSeqWithParallelTestSequences.seq ‏72 KB
BatchTest With ParallelTestSequences.jpg ‏82 KB

Answer 1

A couple things regarding your issue:
You should be fine with just the Parallel or Batch model.  Personally, if you don't need to switch out UUTs dynamically then I would go with the Batch model.  Why?  Because then you can use synchronized sections.  Synchronized sections give you the ability to run a particular section of your sequence file (i.e. several or a single step) in Parallel, Sequentially or One Socket Only.  With the parallel model you can kind of get there by using Locks and Queues.  Look in the TestStand Reference Manual under Appendices A and B for more info on the Batch model and synchronized sections.  To access the TestStand Reference Manual go to Start>>All Programs>>National Instruments>><TestStand>>>Documentation>>Manuals.
Regarding your VIs and how they would handle each socket.  I don't think it's a good idea to make a different VI for each socket.  Just have some sort of case inside the VI that if 3 comes in the set the right wires to populate your switching or COM functions.  For instance: Lets say that Socket 1 is executing and comes to the step to call the com_port.vi.  One of the parameters for that VI could be the socket number.  Inside the VI you set the desired com port to read or write based on that parameter.  You can set the parameter in TestStand by using RunState.TestSockets.MyIndex (that will return the socket you are on). 
In fact you wouldn't even need the logic in your com_port.vi.  I would assume that one of the parameters to that VI would be a VISA session to your COM ports.  In TestStand you use the LabVIEWIOControl datatype which has property of DeviceName.  If you set that parameter to be '"COM" + Str(RunState.TestSockets.MyIndex)' then you will achieve the same thing as passing COM3 if you were in TestSocket 3.
Anyhow, this is just a few ideas for you.  Obviously you have to implement what makes sense.
Hope this helps,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~