TestStand VI sub-VI search, LV Run-Time

[daniel_vi]

Hi,
I am developing a sequence in TestStand 3.5 that makes a step call to a 3rd party custom step type.
This custom step type is a uneditable VI run on deployment systems with LabVIEW 8.2 Run-Time.

When I run the VI directly, it loads relatively quickly.  However when I first run the teststand sequence referencing this VI, the VI search window appears and it takes a long time to find all the necessary sub-VIs.

I've tried adding search paths through TestStand, but this doesn't help.  I also tried changing the LabVIEW search paths on a development version, but again this didn't reduce the search time.

Is there any way to force the VI to absolutely reference it's sub-VIs, or a different place to specify search paths?

Thanks in advance,
Daniel

[JettR]

Hey Daniel,

    I looked into this issue and found that LabVIEW only stores file paths in relative format.  There does not appear to be a method to force your deployed VI to use absolute file path references for its sub-VI locations.  However, I would suggest that you copy your sub-VIs to the directory that your top-level VI is in to speed up the search time.  Since the first search path location is the top-level VI’s directory, this should speed up the time it takes to find all of your sub-VIs in your deployment system.  I hope this helps!

[daniel_vi]

Hi Jett,

Thanks for looking into this for me.  Unfortunately the long searches are happening for library VIs (vilib, instrlib, niScope), so it seems like a bad practice to move pieces of those libraries into the 3rd party VI collections VIs.

Thanks for the help,

Daniel

[RayFarmer]

Hi Daniel,

The first place a VI looks for its sub VI's is in the original positions when the VI's were saved. Then it starts using the search paths.

Is this happening with using the SeqEditor or the Operator Interface?

Regards

Ray

[daniel_vi]

In both places.

My company purchased a 3rd party LabVIEW based software package for acquiring and analyzing signals through a digitizer.  This package includes a TestStand custom type, which basically opens a high level VI in the 3rd party package.

My OI loads my sequence file (OI compiled at C:\Program Files\<myapp>\<myapp>.exe, sequence file at C:\Program Files\<myapp>\Test Sequence)
The 3rd party custom step type is used in the Pre UUT Loop (3rd party VI installed by their installer at C:\Program Files\<3rdparty>\<3rdParty sub-folder>\<3rdparty>\<3rd party main VI that takes a long time to load>.vi

When I dbl-click the 3rd party main VI and open in LabVIEW, the sub-vi load time is ~ 1 second.
When I run my TestStand sequence through TestStand directly, the load time is ~30 seconds
When I run the compile OI in LabVIEW run-time, the load time is also ~30 seconds

The VI's that it is taking a while to find are mostly in the <vilib>, <instrlib>, and niScope library directories.

Hope this clarifies the situation more,

Daniel

[RayFarmer]

Hi,

Is this VI the first VI that TestStand invokes?

TestStand does take a bit infinite time to launch labview. Try having a dummy VI before this VI or have LabVIEW already running and see if its still taking time to search for subVI's.

Regards

Ray

[daniel_vi]

There are LabVIEW adapter steps before the 3rd party VI is called

[JettR]

Hey Daniel,

   I have two potential options for you.  The first option involves setting the Load Options of the step that is calling the top-level VI to Preload when opening sequence file.   You can access this option by selecting the step that calls the top-level VI  in the sequence editor and selecting  the properties tab in the step settings.  Once there, select Run Options on the left and then change the Load Option to Preload when opening sequence file.   This will shift the ~30 second load time to the start up of the Operator Interface.

The second option involves compiling this code into a .dll.  If you open this Top-level VI in LabVIEW and add it to a project, you will be able to compile this code into a .dll.  You can refer to “Distributing Applications with the LabVIEW Application Builder” at http://zone.ni.com/devzone/cda/tut/p/id/3303 for a general overview of how to use application builder.  Once you have built everything into a .dll, you can call this code module from TestStand without all of the pre-loading overhead of LabVIEW.  Have a great afternoon!

[JettR]

Hey Daniel,

   There is yet a third option that could potential speed up the pre-load time for this VI.  If the VI was written in another LabVIEW version than you are currently running it in, I would suggest a mass-compile on the top-level VI and all of the non-library sub-VIs.  To perform a mass compile, open up LabVIEW and select Tools » Advanced » Mass-Compile…, then select the directory where these VIs are located.  Make sure that all of the VIs are not read-only because the mass-compile will throw an error.  After you have successfully mass-compiled the directory, try running the VI through TestStand again.  I look forward to hearing how these suggestions work for you.

[daniel_vi]

Hi JettR,

The first option (Run Options->Preload) just moves the delay to earlier in the load period.

Unfortunately since the VI with long sub-vi load time is a 3rd party install, and due to the way we are imaging the stations we deploy to, options two and three won't be practical for my case.

Also because the "Top level VI" we've been refering to is a 3rd party password-protected VI, and it's not being called as a LabVIEW Adapter step in TestStand, options 2 and 3 sound much more difficult.  I can build a DLL successfully, but I can't edit the custom TestStand test type that the 3rd party provider includes in the TestStand "...TestStand 3.5\Components\User\StepTypes\<3rdparty_types\<3rdparty>" directory to call the compiled DLL instead of the VI.

It seems like my specific situation this will be something we have to live with.  It is not a big problem on the line where the programis started once a shift, it's more just an annoyance for development/debugging when we are restarting the program every 5 minutes - but at this stage in the project debugging work is minimal.

Thank you both for all your effort on this issue.

Regards,

Daniel