NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

In a parallel process model... where do I store Runtime "Global" variables such as hardware Refs?

Solved!
Go to solution

I am setting up my parallel model and I'm just getting to the point where I am initializing my hardware; this hardware will be shared by the multiple parallel executions.

 

Where do I store runtime variables created programmatically (for instance, options from INI files)?  If I store them in station globals, they are treated as permanent changes to the station globals and this causes TS to save them into the station globals configuration... I don't want these variables to be stored permanently.

 

I started out by creating my own runtime container in runstste.root.locals, but it looks like this is not easily accessible from the other executions, which have their own runstate.root space.  How do I get access to the other execution's space?  Will I have to modify the process model to pass this information through?

 

The parallel examples don't seem to init hardware in the process setup, but then how do you share a VISA session or other reference?

0 Kudos
Message 1 of 3
(551 Views)

Of course, I search for 20 minutes, then ask, then search again and find it.

 

Either:

1) Update the sequence file properties to share File Globals across executions

or

2) Use Queues/Notifications to share the references.

 

Message 2 of 3
(545 Views)
Solution
Accepted by topic author Jed_Davidow

Hello,

 

You may also consider using TemporaryGlobals. You will have to add property programmatically into this 'special container', but in my understanding, it should be accessible throught the whole station (didn't yet test your case with parallel model).

 

There is an example here, that may be adapted quickly to the parallele model, to validate the principle : Using TestStand Temporary Globals (Engine.TemporaryGlobals) 

 

Note you will have to handle the 'end of execution' problematic, by resetting all sessions (or not) or by removing all created properties at execution cleanup. If not, you may find references from the previous execution of the parallele model entry point. Using dynamically created properties, this can be the tricky point.

 

Hope this helps,

Message 3 of 3
(517 Views)