Is there away to run parallel executions of different test sequences?

[Ray.R]

Actually... we're looking at a few solutions...

We have the ability to test up to 4 cards at a time.
Each card could be the same or they could be different (variants). Meaning they culd have single or multiple processors and a list of features..

So basically, the 4 UUTs could have one or two sets of tests running simultaneously.

The challenge is this:

The test sequence is to report for each UUT what test indeed ran (from a list of tests from that product).

1. If a test is skipped, then don't report it (hey... I didn't make the rules... only implementing them 😉 )
2. If a test failed, then it reports what failed.
3. If the test passed, then we all smile 😄

I was thinking of setting a loop with a number of iterations that comes from the UUT... because IT tells TestStand which tests will be running because IT knows what it has... ( I did say there was a challenge )

So.. I was considering the idea of changing the name of the step in runtime so that TestStand reports the name of the test and the result (if it ran).. I was also considering programically removing the equivalent to the boolean (??) ( checkmark = > Step Property = > Post Actions = > Report Results ). That way, if a step is skipped, then it is not reported.


BTW... do you have any suggestions on implementing this in a easier fashion 😉

BTW... we were talking about running up to 4 UUTs in parallel (possibly) running different test sequences.. That was my original idea until I found out additional constraints..

Thanks Ray..

😄

R.

PS: I remembered that you like TestStand challenges...

[LU_SDRON]

I have been doing this for some time now. I created a "master sequence" that asks the user how many of each of 3 different circuit packs will be tested. The sequence then calls up to 3 new executions of sequence Alpha, up to 3 executions of sequence Beta, and up to 6 Executions of Sequence Gamma. The master sequence uses no process model and the "subs" us the sequential model. I have created Scan Serial number and Status banner windows that color code, label and position themselves to match the test fixture. The execution displays are also color coded and labeled. I use the sequential model to minimize my work. If I tried to use more than one model I immediately increase my maintenance load. All of the engineers that I support use the sequential model.

[RayFarmer]

Hi JLV,

Is this still an issue for you?

Ray.

[Ray.R]

Thanks for the follow up, Ray.

Actually, we implemented a clever solution.

Each socket contains two threads. There can be 4 sockets for a total of 8 threads.
Each thread creates a copy of the configuration, dll's, etc. and storess it in it's own folder.
The tests run in parallel.

A precondition verifies the setp to see if it was meant to be evaluated, otherwise it is skipped.
Once the global test report is generated by TS for each opf the threads, it is parsed to removed skipped tests and simply reports PASS/ FAIL and overall outcome for each socket.

KISS principle..

😄

[LabVIEW_Brad]

Seems like this thread has grown for a while...

Just stumbled onto this problem myself. I'm using LabVIEW 7.1 with TestStand 3.1. My question is about how the parallel model is structured. Why does the sequence "Create Test Socket Execution" inside "Initialize TestSocket" store the path to your test sequence inside "Runstate.ProcessModelClient.Path"??

I am new to TestStand so bear with me... It seems that this location is the same for all test sockets running. Why doesn't the path get stored in the "Parameters.ClientSequenceFilePath"? By putting it here, you can open and close sockets (I'm doing it by calling Process Model Sequences through LabVIEW, terminating and initalizing different testsockets and providing new sequence file paths). Now I can run completely different sequences through seperate test sockets running at the same time.

One thing I found is that you need to have desired sequence open in TestStand for this to work. Main question is why is the path taken from "Runstate.ProcessModelClient.Path"? Are there problems that I'm going to run into by changing this?

-Brad