NI Home > Community > NI Discussion Forums

NI TestStand

Showing results for 
Search instead for 
Do you mean 
Reply
Member
folon
Posts: 11
0 Kudos
Accepted Solution

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

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

------------------------------------------
CLD, CIT Engineering Polska
Active Participant
snowpunter
Posts: 283
0 Kudos

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

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
Member
folon
Posts: 11
0 Kudos

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

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?:smileyhappy:

 

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

 

Best Regards,

Folon

------------------------------------------
CLD, CIT Engineering Polska
Active Participant
snowpunter
Posts: 283

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

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
Trusted Enthusiast
dug9000
Posts: 2,107

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

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

Trusted Enthusiast
RayFarmer
Posts: 4,652

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

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
Member
folon
Posts: 11
0 Kudos

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

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

------------------------------------------
CLD, CIT Engineering Polska
Trusted Enthusiast
RayFarmer
Posts: 4,652
0 Kudos

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

Here is a small example.

 

 

Regards
Ray Farmer
Trusted Enthusiast
dug9000
Posts: 2,107
0 Kudos

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

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

 

RunState.TestSockets.MyIndex

 

-Doug

Member
folon
Posts: 11
0 Kudos

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

[ Edited ]

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:smileysad: 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:smileyhappy:

Best Regards,

Folon

------------------------------------------
CLD, CIT Engineering Polska