NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Batch Model & FGV

Hello All,

 

How does TS Batch Model work with LV Functional Global variable. I thought each socket would start a separate application instance of the FGV and it would be thread safe.

 

I am trying to run a small test using an FGV and have found out that they don't seem to be independent in each socket.

 

if I do a batch synchronization Start & Exit as it is in the attached Seq File, it does work but I want to know if there is a way to avoid this as I want to use the FGV's in different part of the seq.

0 Kudos
Message 1 of 3
(923 Views)

This is why I generally discourage people from using FGVs with TestStand.  When a VI is loaded into memory in TestStand it is the same as loading the FGV into several different threads inside of LabVIEW.  It is shared by everyone.  A quick fix would be to store your data in an array instead of scalar.  Then pass the socket index into the FGV to determine which piece of data to get/set/operate on.  You can get the socket by using RunState.TestSockets.MyIndex.

 

Another reason I generally avoid FGVs with TestStand is because at any point the engine could unload all modules (you would have to explicitly call it).  This will then cause you to reset any FGVs.

 

Regards,

 

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 3
(831 Views)

It's going to feel like more work (well, because it is) but that's the idea behind being able to pass parameters in and out of subsequences and code modules.

 

If I needed some data specific to an execution I'd wrap it as a class which I could pass into subsequences and into the code modules that need the data. This could also work with regular clusters though that means ideally maintaining a matching TestStand custom type. Scalability is one of the main reasons that globals are discouraged even if race conditions aren't a concern. When developing, if data access is encapsulated to the narrowest scope possible, scaling issues like this are usually avoided.

Message 3 of 3
(822 Views)