NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand Array to VI by reference

I have a very large array in TestStand (seq.local) and I need to pass it into many steps (each step is a VI). Using the standard GetValVariant on the LabVIEW palette it takes 11 seconds. How can I speed this up, how can I just reference the existing data in memory without making a copy?

Any help much appreciated.
Certified LabVIEW Architect
0 Kudos
Message 1 of 5
(3,639 Views)
Before I give you some suggestions on how to workaround this I would like to say that it might help out to tell us what version of TestStand and LabVIEW you are using, so that we can try and reproduce the problem precisely. Other than that question, how big is this array that you are trying to access? Are you sure that you are not out of physical memory and you are starting to use your swap file?

I have created a test sequence and vi that do a simple GetValVariant of a 100,000 index numeric array and on my system it takes ~.38 seconds to execute. The sequence and vi are attached to this post (note that the sequence file was made in TestStand 1.0.3 and the .vi in LV 6.1).

Basically, all of the TestStand API vis for accessing property values will create a copy of the array in your LabVIEW vis. Have you tried setting the unload option for each of your LabVIEW steps to unload the vis after each step executes to conserve on memory consumption?

To get around the time it takes to load this array into your LabVIEW steps you may want to use a LabVIEW global variable instead of trying to get the value from TestStand for each and every step. This way you only have one copy of the array loaded into LabVIEW's memory space, and if you don't really need this array in TestStand you may want to consider using a Global variable instead of the TestStand variable altogether. To consider whether you need it in TestStand or not, you should make note of whether you will need to pass it to any other "type" of code module (i.e. dll) or if you are going to include in a report or database. If you are not going to do any of these things, just use a LabVIEW global instead of the TestStand array. (NOTE: the use of global variables is generally not recommended because it will not scale to cases where you perform multi-UUT tests, and it should really only be considered as a last ditch effort.)

To get the type of access speed you would get by dereferencing single memory addresses at will, you would need to use a programming language that supports this, but as you can see there are plenty of ways to get around this problem when programming in LabVIEW. Try out the example I attached to this post to see if you get the same behavior (manipulate the array size if you need to). This should be a good starting point to see if there is something wrong with your system's memory availability or how you are working with the array in your own vi (meaning, that if this example does not take that long, then you may be doing something else causing the long delay like analysis or unnecessary manipulation.) If anything you could also try narrowing down the problem only to the array access in an example vi and sequence and submit it to the forum for us to try out on our systems, but please remember to remove any irrelevant code from the example.

I hope this information helps.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask
0 Kudos
Message 2 of 5
(3,639 Views)
Martins,

There TestStand does not support passing array references into LabVIEW or any other language. Even when TestStand calls a DLL, arrays are copied into a temporary array before being sent to a code module (see page 13-10 of the 2.0 user manual).

However, there may be some things you can still do to speed up the process of moving large arrays from TestStand to LabVIEW. You should get better performance by having TestStand and LabVIEW in the same process.

To test how much of an improvement results from having a single process follow these steps. Select the Start>Programs>National Instruments>TestStand>Operator Interfaces>LabVIEW Menu. This command will load and run a TestStand operator interface under the LabVIEW process. Once you have logged on,
select the configure->adapters� Select the LabVIEW adapter, and insure that the Active X server is set to LabVIEW. If it isn't change it to LabVIEW and OK all of the dialogs. Load your sequence and check the execution time.

If being in the same process is not fast enough, you can also make a LabVIEW DLL. A LabVIEW DLL will always be in process with TestStand and passing an array to the DLL will be faster then using the sequence context.

If neither is sufficient you may need to get more memory or a faster computer.

-Rick Francis
0 Kudos
Message 3 of 5
(3,639 Views)
Thanks for all the advice. I'm using LV6.1 and TesStand2.0, my target array size is 3D - 30,80,6000 DBLs. But TestStand cannot handle large arrays so I split it into 30*2D 80,6000. Saying that I have now given up with sequence locals, too slow.

LabVIEW globals work much faster than sequence locals and binary files, but I need multi-instance functionality. To my mind a LV2 style global should be better than a standard LV global for memory management reasons, I need to prove this though. After proving this I'm planning to create a LV2 global that is dynamically spawned from a VI template, hence giving me multi-instance functionality. I have 256Mb RAM at the moment, from the test performed so far I think I will need at least double this for the target mac
hines.

I have attached the code I have used for evaluation so far (Includes TestStand1 seq files).

Do you think that slitting the large 3D array into smaller chunks will help protect against memory fragmentation problems?
Certified LabVIEW Architect
0 Kudos
Message 4 of 5
(3,639 Views)
I'm new to TestStand and have found a whole host of performance improvement options in the areas you described, thanks Rick.
Certified LabVIEW Architect
0 Kudos
Message 5 of 5
(3,639 Views)