NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Are multiple Batch executions possible?

Should it be possible to run multiple Batch executions simultaneously using
the stock NI Batch process model?

In other words, if I have a sequence file that uses the NI Batch process
model to test 4 UUT in parallel, should I be able to run multiple instances
of this client sequence file simultaneously?

Say I have 3 fixtures that each hold 4 UUT. Each fixture can be loaded and
unloaded asynchronously, possibly while the UUT in another fixture are being
tested. The most straightforward way to accomplish this it would seem would
be to launch a separate 4 UUT Batch execution on each fixture. Essentially,
this would be kind of a mixed Serial and Batch type environment...

Is this theoretically possible using the NI Batch process model?


The reason I ask is that I've attempted to simulate this using the NI Batch
process model and a simple test sequence file, but have not had success.
There seems to be issues with the UUT dialog when I attempt to run more that
one Batch execution (sometimes the second dialog never appears with the
results, sometimes the test socket executions for the second Batch are
'stopped' for reasons I'm not clear on, sometimes both executions seem to
hang, etc).

I am not sure if the issue is with the process model itself or with the DLL
that manages the UUT.

Has anyone ever successfully accomplished multiple asynchronous Batch
executions?

Thanks,

---
Bob
0 Kudos
Message 1 of 12
(4,890 Views)
Try the ParallelModel.seq for the Process Model. That is, in TestStands Configure menu, Station Options, Model tab, select the "ParallelModel.seq". This should allow you to run multiple UUTs at once.

Mike
0 Kudos
Message 2 of 12
(4,891 Views)
Yes, you should be able to run more than one batch at a time.

What does your simple test sequence consist of?

One thing to keep in mind is that if your test sequence uses named mutexes, notifications, or other synchronization objects, that those objects will be shared between all batches and will be the same object in all batches (this might be the problem you are running into). To avoid this problem either use unnamed synchronization objects (store them in reference object variables when you create them and make the name an empty string), or dynamically create the name for these objects such that they are different for each batch (perhaps concatenate a batch id of some sort to the name).

Hope this helps,
-Doug
0 Kudos
Message 3 of 12
(4,891 Views)
> Try the ParallelModel.seq for the Process Model. That is, in
> TestStands Configure menu, Station Options, Model tab, select the
> "ParallelModel.seq". This should allow you to run multiple UUTs at
> once.

Thanks for the reply...

My understanding of the stock NI process models is:

The Parallel model is for asynchronous testing of multiple UUT. Each UUT
may be started stopped seperate from the others.

The Batch model is for synchronous testing of multiple UUT. All UUTs
start/stop testing at (essentially) the same time.

Becuase of our ATE hardware architecture, things are basically asynchronous
at the fixture level, but synchronous at the UUT level. In other words, all
the UUT in a fixture are tested at the same time using the same resources,
but ea
ch fixture can start/end testing asynchronously (each fixture using
its own set of resources OR one set of resources MUXed at the fixture
level).

So thats why I was leaning towards the Batch model as the basis for the
software architecture. I assumed that I could just launch multiple Batch
process model instances, each instance dedicated to a fixture, each instance
configured for 4 (or more) Test Sockets.

However, my initial tests have indicated this may not be possible. It
appears as though the Batch and Parallal models assume there will only be a
single isntance of either of them running at the same time. I don't know if
this limitation is inherent in the models themselves, or if its in the model
support code.

---
Bob
0 Kudos
Message 4 of 12
(4,891 Views)
dug9000,

Thanks for the reply...

> What does your simple test sequence consist of?

Just three steps. One is a step that simulates measurements for all UUT (it
Synchronization setting is "One Thread Only") and two Numeric Limit steps
(not synchronized at the TestStand level) that retrieve each UUT's value.
Things work fine if I launch only a single instance of the process model.

> One thing to keep in mind is that if your test sequence uses named
> mutexes, notifications, or other synchronization objects, that those
> objects will be shared between all batches and will be the same object
> in all batches (this might be the problem you are running into). To
> avoid this problem either use unnamed synchronization objects (store
> them in reference object va
riables when you create them and make the
> name an empty string), or dynamically create the name for these
> objects such that they are different for each batch (perhaps
> concatenate a batch id of some sort to the name).

I don't use any TestStand synchronization steps. The problem does not
~appear~ to be in the client test sequence file. The problem(s) seem to be
in the process model itself (or something silly I'm doing is causing the
process model to get confused).

The exact behavior things seems to vary depending on when I launch the two
process model instances in relation to each other. Most of the time, the
two process model instances appear to be getting stuck in
"ProcessTestSocketRequests" as both instances permanently block on the "Get
Next Request" step. Other times both instances run to completion, but one
instance's Test Sockets are all marked "Test Socket Execution Stopped" in
the UUT info dialog that appears at the end.

---
Bob
0 Kudos
Message 5 of 12
(4,891 Views)
> The exact behavior things seems to vary depending on when I launch the two
> process model instances in relation to each other. Most of the time, the
> two process model instances appear to be getting stuck in
> "ProcessTestSocketRequests" as both instances permanently block on the
"Get
> Next Request" step. Other times both instances run to completion, but one
> instance's Test Sockets are all marked "Test Socket Execution Stopped" in
> the UUT info dialog that appears at the end.

I will try to boil things down to a reproducible sample and post it.

---
Bob
0 Kudos
Message 6 of 12
(4,891 Views)
Ah. The issue seems due to the fact that I'd selected "All Executions Share
the Same File Globals" for the process model. I'd never used this option
before and misunderstood its impact. I thought all 'child' TestSocket
executions spawned from the same instance of the process model would share
the same FileGlobals. Instead, apparently ALL executions spawned from ANY
instance of the process model all share the same copies. In essence with
this option enabled, the process model FileGlobals behave like short lived
StationGlobals.

Looks like I'll need to deselect "All Executions Share the Same File
Globals" and find another way to share values among all TestSockets launched
from the same instance of the process model.

---
Bob
0 Kudos
Message 7 of 12
(4,891 Views)
Bob,

The "All Executions Share the Same File Globals" setting applies only to the steps within the sequence file in which you set that setting. If you want your test sequence to have shared file globals then you just need to set that setting on the sequence file that contains your test sequence, not the process model file. File globals are globals that are only accessible from steps within the same file as the globals themselves so setting that setting on the process model really doesn't do you any good anyway unless your test sequence is within the process model file which is not something I'd recommend.

Let me know if this is unclear or if you need more information on file globals or this setting.

-Doug
0 Kudos
Message 8 of 12
(4,891 Views)
> The "All Executions Share the Same File Globals" setting applies only
> to the steps within the sequence file in which you set that setting.
> If you want your test sequence to have shared file globals then you
> just need to set that setting on the sequence file that contains your
> test sequence, not the process model file. File globals are globals
> that are only accessible from steps within the same file as the
> globals themselves so setting that setting on the process model really
> doesn't do you any good anyway unless your test sequence is within the
> process model file which is not something I'd recommend.

I initially misunderstood the scope of the FileGlobals "sharing".

The reason I set "All Executions Share the Same File Globals" in my process
model was I was that I was planning to - in the ProcessSetup callback of
each process model sequence file - assign each instance of the process model
a unique ID. The TestSocket executions would then query the ID to determine
which instance of the process model the were running on.

Take the example configuration I mentioned in my first post: 3 asynchronous
fixtures of 4 UUT each. Lets name the fixtures "F1", "F2" and "F3". Each
fixture has four UUTs "U1", "U2", "U3" and "U4".

I was planning to launch a seperate instance of the Batch process model for
each fixture, and in each instance's ProcessSetup callback, set a FileGlobal
to the name of the fixture. For example, a TestSocket running for "U4"
could query this value and know it was really "U4" in fixture "F3" vs. "U4"
in fixture "F1", etc.

The whole reason for this process model instance ID was so that each Test
Socket could "know" under which instance of the process model it was running
(for hardware and software MUXing-type reasons). I could find no simple
"built-in" way to uniquely identify each process model instance. Does
anyone know if such a mechanism exists? Is there a way for a TestSocket
execution to "know" which instance of a process model the TestSocket is
running under?

Thanks,

---
Bob
0 Kudos
Message 9 of 12
(4,891 Views)
dug9000,

> File globals are globals
> that are only accessible from steps within the same file as the
> globals themselves so setting that setting on the process model really
> doesn't do you any good anyway

This is not quite true. Using the TestStand API, the process model
FileGlobals can be accessed by Executions launched using that process model.

The TestSocket executions can access the run-time versions of the
FileGlobals in their root process model by calling GetFileGlobals and
passing it a sequence file reference to its root process model sequence
file. A code snipped for a DLL step in the test sequence file might do
something like:

// Get Sequence Context ptr.
TS::SequenceContextPtr pobjSequenceContext = pobjSequenceContextDisp;
// Get E
xecution ptr.
TS::ExecutionPtr pobjExecution = pobjSequenceContext->Execution;
// Get process model SequenceFile ptr.
TS::SequenceFilePtr pobjSequenceFileObject =
pobjExecution->GetModelSequenceFile();
// Get process model FileGlobals property object ptr.
TS::PropertyObjectPtr pobjPropertyObject =
pobjExecution->GetFileGlobals(pobjSequenceFileObject);

After this, pobjPropertyObject now can be used to set/get values in the
process model FileGlobals namespace. If "Seperate File Globals for Each
Execution" is selected, then this is a fairly pointless exercise, as it
apparently has the same effect as setting a Locals variable (IOW no other
Execution can see the new value). Choosing "All Executions Share the Same
File Globals" would all allow TestSocket Executions to directly get/set the
same values seen by the process model and the other TestSocket executions,
effectively making them truly "global".

---
Bob
0 Kudos
Message 10 of 12
(4,710 Views)