Preset instrument only first time on parallel test

[TomDev]

Hi,

I have a parallel test with three threads that do not start simultaneously, I need that execute a preset of the instruments only the first time.

I tried to create a Rendezvous on the first thread for execute a preset instruments and other threads if they are existing jump it.

Are there other alternatives or this might be fine?

I use a TestStand 2014.

Thank you

[~jiggawax~]

I would do it in a callback before your threads get spawned.  Potentially Process Setup or PreUUTLoop.  That is what they are for.

Let me know if you have further questions on that.

[TomDev]

Hi jigg,

I can't modify the "model file", and the PreUUTLoop sequence is called for every threads.

For my case not good.

[~jiggawax~]

You can override the callbacks from your client file. You are correct thought PreUUTLoop occurs for every thread.  In this case use ProcessSetup and ProcessCleanup callbacks.  I've attached a small example demonstrating how to override callbacks.

Let me know if you have any questions about it.

Hope this helps.

[TomDev]

This example is perfect for me for the instrument init!

But I have the same problem during the test, I have three threads but I want show a message only one time.

What do you suggest?

Thank you for your time

[~jiggawax~]

---

TomDev wrote:

But I have the same problem during the test, I have three threads but I want show a message only one time.

What do you suggest?

---

You can precondition any step with this: RunState.TestSockets.MyIndex == 0

Then only socket 0 will execute that step.  However, I should put a huge disclaimer here.  I think this is a very bad bad bad idea.  Parallel testing should not be synchronized.  That defeats the purpose of it.  If you need to synchronize then you should use the Batch Model.

Regards,

[TomDev]

I have a parallel test to run simultaneously different threads but I need change the temperature on the thermal chamber a send a message to the operator! For this reason I would find a way for call just one time this operation.

For now I create a "Rendezvous" only the first thread that reaches and for others I read before the state and do not show the message and then I expect everyone to arrive to the "Rendezvous".

For example: "Lock" -> if(Rendezvous not exist) -> Create Rendezvous (same sequence) -> Message -> End if -> "Unlock" -> Rendezvous (wait all threads)

In that way I do what I need but do not know if it's the right way

[~jiggawax~]

TomDev,

That is probably the most inefficient way to accomplish what you want.  Why don't you use the Batch Model?  It is made for this exact thing and you can use batch synchronization which will perform everything you just described in a single step.  In fact batch synchronization is part of every step if you want it to be.

[TomDev]

I try to use a "batch synchronization" but not work! I don't know why.

Example: Create batch synchronization ("Enter Synchronized section - "One thread only) -> send message -> Exit from batch (Exit Synchronized section)

With this example all thread show the message.

If it is possible and if you have time, can you attach a simple example?

Thank you very much

[~jiggawax~]

It doesn't feel like you are understanding what I am saying here.  When you install TestStand by default there are 3 process models that get installed: SequentialModel.seq, ParallelModel.seq and BatchModel.seq.  SequentialModel.seq is pretty straight forward in that it simply executes on a single UUT or rather a single test socket.

ParallelModel.seq and BatchModel.seq are quite different but both of them can test multiple UUTs or rather multiple test sockets at the same time.

There is a huge difference however in the behavior of the models. Hopefully the following description can explain:

BatchModel.seq is similar to baking cookies.  All cookies go into the oven at the same time and they all come out at the same time.  Ultimately all sockets start and end at the same time.  My rule of thumb is this.  If at any time I need to synchronize (for any reason) then I use the BatchModel.seq. 

ParallelModel.seq is similar to grilling.  You have x number of spots on the grill where you can grill food.  You can put anything you want on any of the spots and some items may get done faster than others.  For instance on my grill I have a hot spot where I can cook 3 burgers in the time it takes a colder spot to cook 1 burger.  Absolutely no synchronization required.  Test sockets can start and stop at will independently of the other sockets.

So my point here is: use the BatchModel.seq so that you can take advantage of the Batch Synchronization stuff you described.  I've attached a small example that demonstrates the 3 different types of batch synchronization.

Hope this helps,