Create an 'execution' global (parallel processModel)

[CyGa]

Hello all,

Planning to use the Parallel process model to test UUTs, I'll have create each test sequence on the fly according to UUT identification nb.

Each 'dynamic' test sequence will be composed of separate existing sequences files (as subtest procedures). Two of these 'dynamic' might have to run in parallel for different products on the same bench (that's why i think the parallel model perfectly fits to my purpose).

My problem is to find a way to create a 'global' variable onl accessible to one test sequence (so one execution). As Station Globals are shared through executions, I can't use them. Moreover, My main test sequence will be composed of sequence call pointing on independent sequence files : so I can't use my FileGlobals to share information between all sequence files.

How to create this 'execution' global ?

[dug9000]

As long as you don't mind creating the variables dynamically (via the TestStand API) and not having them persisted in any files, you can use Execution.RunTimeVariables (Make your variables subproperties of this object). Similarly you can create thread specific variables on Thread.RunTimeVariables.

Hope this helps,

-Doug

[CyGa]

Hi Doug,

I'll have to script my sequence using already wrtitten .seq files.

In these files, some variables are already mapped to my steps. So I can't create all variables dynamically.

But I might found a way to use the FileGlobals and the scripting in a way that all my MainSequence FG will be the 'execution' global.

My idea is to copy the content of the seq files in Main sequence file calling sequences in the same file (so the seqcall will point on same file sequences instead of pointing on another seq file). If the 'already written' sequences do not have variables with the same ths should work.

Thanks for your ideai anyway !

Is the kind of variables you describe a new feature of TS 2012 ?

[Romain_Duval]

Hi Zyl7,

You could do that just passing the FileGlobal as a parameter as they are passed by ref?

Regards

[dug9000]

Another idea: You could also just put all the variables in the file globals of your main sequence's sequence file and use:

RunState.Main.FileGlobals

-Doug

[CyGa]

Hi Romain,

The idea is that all small sequences should be independant one from another so the scripting would be easier.

So I would like to avoid dealing with data passing while scripting my final sequence.

[CyGa]

Hi Doug,

RunState.Main always point to the ProcessModel client ?

Lets say I have my processmodel client A.seq calling 2 sequences B.seq and C.seq. A, B and C have their own FileGlobals.

A statement in C.seq pointing on RunState.Main.FileGlobals would allow reading the values stored in A.seq's FGs ? Or does this work only if B and C are subsequences in the same file as A.seq ?

[Romain_Duval]

Hi Zyl7,

It depends on the origin of the execution as described in the definition of the Runstate.Main definition:

Runstate.Main:

"Sequence context for the least-nested sequence that is not in a process model. When you initiate an execution using the default TestStand Model entry point, the Main property is the sequence context of the Main sequence. When you initiate an execution on a sequence without using a Process Model entry point, the Main property object is the sequence context for whichever sequence you run."

So for example if you have one FileGlobal called "a" and located in your main SeqFile A, then you will have access to this variable in the subsequence you call from A through Runstate.main even if the subsequence is not located in the A SequenceFile.

The Thread.RunTimeVariables and similarly Execution.RunTimeVariables are not a new features of TestStand 2012  but was a new feature in TestStand 3.0.

I think Dug9000 first option was the best and it works well The only limitation I see is that these variables won't be persistent since you address the execution object and not the SequenceFile object registered on the disk. You can access the RuntimeVariables Container just after creating the new execution for your client sequence as shown here and it doesn't prevent you from using "Template SequenceFile" as it is commonly done and known with "SequenceBuilder" name :

Best Regards

[dug9000]

---

@zyl7 wrote:

Hi Doug,

RunState.Main always point to the ProcessModel client ?

Lets say I have my processmodel client A.seq calling 2 sequences B.seq and C.seq. A, B and C have their own FileGlobals.

A statement in C.seq pointing on RunState.Main.FileGlobals would allow reading the values stored in A.seq's FGs ? Or does this work only if B and C are subsequences in the same file as A.seq ?

---

Correct. It works even if the sequences are in different files. Of course it's not much different than using RunState.Main.Locals, that would work too. Though it might be better to have the variables in FileGlobals to make it a little more self-documenting that those variables are used outside of the sequence.

-Doug