Where to store variables

[Jackson_Peacock]

Hi,
I'm still in the process of learning TestStand and I'm trying to figure out the best place to store certain variables and constants that are used in our Tester. This includes things like more info on the UUT (SN's for components, what version of software it is programmed with, etc), Config file pathname constants, tester hardware constants, additional report info that is carried accrossed multiple invocations of a sequence, and probably more - I haven't sat down and thought about all of them yet.

I don't wan't to store these in the sequence file because I will have several sequence files. Besides the data really isn't seqence file dedpendant, it's application dependent, and I don't have to make the lab-tech's insure that all these variables
are in every test sequence they create.

It seemed like the Process Model might be a good place to store this. I don't think we are going to be using more than one process model, and some of the info (UUT, report, etc) is already stored there. What do you think?

Oh, and also, I haven't been able to figure out how to get data from the Proccess Model (like UUT SN) while in a step of the sequence (in a TestStand expression or LabView code module). Where is that located in the Sequence Context?

Thank you,
jackson

[Ryan Ramcharan]

Hi Jackson,

You are correct. The UUT information, and all other information pertaining to your test system should be stored in the process model. That way the information is available for any sequence file that runs as a client of your model. To access the UUT info from your client sequence file, there are a couple of ways you can do it:

"RunState.Root.Locals.UUT"

This assumes that the entry point sequence conatining the UUT local variable is the least nested in the call stack.

"RunState.Caller.Locals.UUT "

This assumes that you are in MainSequence that was called by your entry point sequence. You can also use this property recurrsively depending on how many items are on the stack and how far you want to go up the stack. That is, RunState.Ca
ller.RunState.Caller.Locals.UUT would take you two levels up the stack.

[Mark_Ireton]

I think the answer depends on how you want to use and maintain the data for your variables. If the data rarely changes and you primarily use it in the process model, I would put it in the process model. If you have multiple testers, this would give you a central location to maintain the data and share it across the different testers. If your test sequences depend on the data, then you will be required to run the process model. We make our sequences so that they can be run without the process model for debugging and development purposes and have found that practice very beneficial!

If the data varies from tester to tester and tends to change over time, then Station Globals is the best place to put the data. To maintain consistency, I recommend creating cust
om data types that you store in a common MyTypes.ini file. You might want to create some sequences for editing some of the Station Globals from the operator interface. You can also customize the tools menu to allow editing of Station Globals.

You can get to the process model variables with the following property path: RunState.Root.Locals.UUT

Good luck, Mark