NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Life-time of Locals in TestStand - passing data through subsequent UUTs executions

Solved!
Go to solution

Hello all,

 

What is the best way to pass a data from previous execution of the sequence to the next one (for next UUT)?

 

I thought that local variable (container with some various controls and arrays) stays through the next executions but it appears that it is cleared after Cleanup. Am I missing something?

 

I would like to do something like shift register between subsequent executions. It is easy to do with LabVIEW (also with TestStand and LabVIEW) but I would like to do such thing purely in TestStand.

 

Can someone help me with some advice?

 

Thanks in advance,

Best Regards,

Folon

------------------------------------------
CLA, CTD, CLED @ Test & Measurements Solutions Poland
0 Kudos
Message 1 of 16
(4,092 Views)
Solution
Accepted by folon

The behavior you see is expected.

 

You can store variable information in a file using the Write() function and read it back with the ReadEx() function.

 

You could also use (gag) Station Globals.

CTA, CLA, MTFBWY
0 Kudos
Message 2 of 16
(4,087 Views)

Snowpunter,

 

Thanks for your input.

 

If I am not wrong Station Global is accessible from each running sequence, isn't it?

 

So, except doing some tricks with files (Write() / ReadEx()) or LabVIEW (Functional global / Global) there is no 'normal TestStand' way to send data variables from one DUT to next one execution?

Let's say I have 4 parallel test sockets (with Parallel model) and I want to use a cluster (container) with settings and product counter inside it for each socket separately? No TestStand resource to accomplish that?:)

 

That's weird, but maybe I don't think in TestStand:)

 

Best Regards,

Folon

------------------------------------------
CLA, CTD, CLED @ Test & Measurements Solutions Poland
0 Kudos
Message 3 of 16
(4,086 Views)

Station Globals are accessible by all sequences on that PC and maintain state between executions as they're stored in an .ini file.

 

Once the execution is finished all variables are unloaded from memory. Think of it like once a top-level VI finishes execution and LabVIEW is closed. The value of a functional global would be the default, rather than what had happened previously.

 

The TestStand way of doing this is to use a Configuration entry point to configure bench/test socket settings into a file and then read from that file during run-time.

 

You'd have to do something similiar in LabVIEW to get consisent behavior between opening/closing the application.

CTA, CLA, MTFBWY
Message 4 of 16
(4,077 Views)

There are many ways you can do this.

 

1) FileGlobals - These are per execution globals by default. There is a setting to share them between executions on a per file basis, but the default is a separate copy per execution which sounds like what you want.

 

2) Execution.RunTimeVariables and Thread.RunTimeVariables - See the API help for more details.

 

Hope this helps,

-Doug

Message 5 of 16
(4,076 Views)

Using the RunState.Execution.RunTimeVariables would work for you.

 

Use Option = 0x5 when you first create the variable

eg

 

RunState.Execution.RunTimeVariables.SetValNumber("MyNumber",5,5)

 

 

Then you can use RunState.Execution.RunTimeVariables.<variable_name> in expressions.

ie RunState.Execution.RunTimeVariables.MyNumber++

 

Make use of RunState.Execution.RunTimeVariables.Exists() to avoid any errors.

 

eg RunState.Execution.RunTimeVariables.Exists("MyNumber",0)

 

 

(Note:  PropertyExists("RunState.Execution.RunTimeVariables.<variable_name>") doesn't work in this instance)

 

 

You can use the watch window to view your RunTimeVariables but you have to use RunState.Execution.RunTimeVariables.<variable_name>

or RunState.Thread.RunTimeVariables.<variable_name>.

 

 

 

 

 

Regards
Ray Farmer
Message 6 of 16
(4,066 Views)

Thank you guys,

 

I would rather not use StationGlobals or FileGlobals, I just got a feeling that this is not a proper case to use them.

 

I will give a try to RunState.Execution.RunTimeVariables and if I fail I will use a fglb of LabVIEW and store there ThreadIDs, so it can select / update / remove proper entry for proper test socket.

 

Best regards,

Folon

------------------------------------------
CLA, CTD, CLED @ Test & Measurements Solutions Poland
0 Kudos
Message 7 of 16
(4,062 Views)

Here is a small example.

 

 

Regards
Ray Farmer
0 Kudos
Message 8 of 16
(4,049 Views)

If you just want to know what testsocket a particular thread is in, you should just be using:

 

RunState.TestSockets.MyIndex

 

-Doug

0 Kudos
Message 9 of 16
(4,043 Views)

RayFarmer - thanks for the example, I gave it a quick look and it looks promising.

 

What I need to store there are such containers:

container.jpg

They look like this as LV clusters:

cluster.jpg

 

I hope I can store containers In RunTimeVariables also (not only simple types like strings or numerics) or is it impossible? Tomorrow I will take a look at TestStand API, how to hadle containers. I got a feeling it will be a burdensome work to maintain them (fill / remove / read).

 

Today I was trying to accomplish this task with use of functional globals but somehow I can't force them to stay in memory:( I use ParallelModel with 2-5 test sockets.

 

This is what I do:

1) ProcessSetup - I run there a InitializeTester.vi (not reentrant) and inside I have my functional global (as SubVI) which is initialized with the array (same size as number of test sockets). Load Option: Preload when execution begins; Unload Option: Unload when sequence file is unloaded.

2) MainSequence - Setup: ConfigureTester.vi (reentrant) with fglb inside (as SubVI), where I assign Threat IDs to the array, so afterwards I can use desired entries in the array for specific test sockets. Load Option: Preload when execution begins; Unload Option: Unload when sequence file is unloaded.

3) MainSequence - Main: Check_fglb - and here my shift register is empty.

 

So question is whether (Load Option: Preload when execution begins; Unload Option: Unload when sequence file is unloaded) also apply to the SubVIs (my fglb is a sub)?

I found an example on this forum of using fglbs (so they work;> -> https://decibel.ni.com/content/docs/DOC-6227 <-) but there they are used directly as the actions not as SubVIs. Maybe that is the case? Anyway, I will verify this tomorrow.

 

I appreciate all your patience and help:)

Best Regards,

Folon

------------------------------------------
CLA, CTD, CLED @ Test & Measurements Solutions Poland
0 Kudos
Message 10 of 16
(4,032 Views)