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

Hi,

 

You are right, the sequence locals don't exist between executions. That's the way TestStand works, it creates executions, executes them, then destroys them. It takes getting used to.

 

LabVIEW tries to make everything more like LabVIEW and keep all the VIs in memory and keep refnums alive between executions. Look at Configure menu>> Adapters>>LabVIEW>> Configure. If "Reserve Loaded VIs for Execution" is checked, it is by default, LabVIEW should behave this way.

 

However, you said, "2) MainSequence - Setup: ConfigureTester.vi (reentrant) with fglb inside (as SubVI)..." If your fglb (is that functional global?) is reentrant, you can't share it's shift register between different copies can you?

 

You are right about the Station Globals and File Globals. They are ok but there are usually more scalable ways.

 

You can create local variables in the Process Model, it is the "parent" of your test sequence and it stays in TestSTand memory between executions. So at the end/cleanup of your sequence you can write to Process Model locals, and at the beginning/Setup, you can read from the same process model locals. If you pause in your sequence, it is something like RunState.Caller.Locals.UUT, or even better RunState.Root.Locals.UUT. RunState.Root. is the highest level of caller/parent. You create Locals there and use the same method GetVal, SetVal to red and write to them.

 

This is really the same as the runtimevariables described by Ray, but they are static and you can see them at edit time.

And really it is like write file and read file, it is parking your variables somewhere outside your execution between executions.

 

In general you have the right idea to manage your threads and variables in TestStand. Try to get all your stuff out of LabVIEW functional globals it is more scalable and less prone to break. (Of course there's always exceptions.)

cc

 

 

0 Kudos
Message 11 of 16
(1,019 Views)

Hi again,

 

The highlighted solution is the best way. I always use this way, but in a more old fashioned way. The Write and ReadEx methods must be new within the last couple of years. Woo they are great.

cc

0 Kudos
Message 12 of 16
(1,017 Views)

If you create a Type TestSocketInfo then you can create a RunTimeVariable using

 

RunState.Execution.RunTimeVariables.NewSubProperty("MyTestSocketInfo ",PropValType_NamedType,False,"TestSocketInfo ",0)

 

then you can set your varaiable

 

RunState.Execution.RunTimeVariables.MyTestSocketInfo.FixtureName = "ABC"

 

hope this helps

Regards
Ray Farmer
0 Kudos
Message 13 of 16
(1,012 Views)

I have attached a modified version of the sequencefile which creates a RunTimeVariable of a Type.

 

I have included the type as part of this sequence file but you would be better creating the type in it's own type file so that it was globally available.

 

I have just filled one element of the TestSocketInfo but if this was store in a local then you could copy the whole type using

 

RunState.Execution.RunTimeVariable.MyTestSocketInfo = Locals.DUT_1_TestSocketInfo

 

 

Regards
Ray Farmer
0 Kudos
Message 14 of 16
(1,009 Views)

OK, my Test Framework is working:) All settings, results, controling parallel executions, customized UUT, serial readings are done (3 barcode readers for 5 test sockets). Uffff:)

 

At the beginning I thought it would take me maximum 2 days to prepare it but since I am quite new to TestStand it took me 7 days.

 

My main problem was about 'forgetting' the states of globals (overall settings, COM ports, DAQ inputs, error explanations...). Those are read in ProcessSetup and kept in LabVIEW global (lots of clusters >20 so I did not implement those as StationGlobals or other resource of TestStand). It is just easier for me to access them as usually I do in LabVIEW. Reason of that 'forgetting' was that I set Project Path (in Model tab) there and link the module to the project, after that I forgot to do alike in MainSequence and it seems to me that this step was accessing some other instance of this global because it was not linked to the project. Can it be true?

 

Same thing as above applied to the functional global, with which I keep control on my parallel tests. Now it works and keeps in memory everything I need. Load Option: Preload when execution begins; Unload Option: Unload when sequence file is unloaded.

 

I also used some RunTimeVariables (thanks to RayFarmer) but I need to get used to them, like am trying to do with TestStand in overall:)

 

Now it is time to implement test steps, so hopefully it will be more pleasent part. At the end I expect some more difficulties since I want to prepare custom GUI with use of SubPanels to load the sequence preview (for single test sockets) when they are used, but this is another story.

 

Thank you all,

Everybody got Kudo?:)

Folon

------------------------------------------
CLA, CTD, CLED @ Test & Measurements Solutions Poland
0 Kudos
Message 15 of 16
(1,002 Views)

It definitely takes a more work to get started in TestStand than in regular programming languages. But it pays off down the road. At some point as you scale up to larger or more numerous tests, your productivity will significantly surpass those who are working in LabVIEW, etc alone.

cc

0 Kudos
Message 16 of 16
(991 Views)