ni.com checkout is currently experiencing issues.

Support teams are actively working on the resolution.

NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Deployment Utility Slow

Hi All,

 

Every once in a while I use the deployment utility to create an installer for our test set-up.

When I want to view the distributed files tab, it requires me to analyze the files. The analyze for me is very slow (around 15 minutes).

 

My workspace only consists of three sequence files, with each some sequences inside. Also I am using classes for my custom vi's.

 

Also I notice a huge performance difference between analyzing when I switch between LabVIEW development and run-time, where development is way faster then run-time.

 

Is there any way to speed things up? When I look at my task manager, the LabVIEW process uses only 25% of my CPU.

I am running TestStand 2016 SP1 (32 bit) and LabVIEW 2015 SP1 f7 (32 bit)

 

Thanks for the help.

 

Erik

0 Kudos
Message 1 of 7
(3,127 Views)

This is generally related to search directory issues.  The analyzer in the deployment utility uses the same search directories that your editor and UI use.  Make sure that you don't have any deep hierarchies in there that the analyzer has to traverse down.

 

Another thing to do is make sure all of your VIs are compiled for the correct version.  You know how when you open a VI and it takes several minutes to find all of its dependencies?  That is basically what is going on in the analyzer.  If you open your VIs and they do this then they aren't compiled correctly.

 

How deep are the VIs that your sequences are calling?  If the VI trees are deep and many then I could see it slowing down the analyzer.

 

Hope this helps,

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

The vi's that are called are not in a big hierarchy, maybe 3 or 4 folders deep. But I don't think that's very deep. But these vi's call other vi's which are located in the instr.lib directory. Are the subvi's also a part of the hierarchy depth?

 

When I open my project with all the vi's it takes about 3-4 seconds to load. When I open a vi then, the vi is almost opened directly (I did not test all vi's). Is there any way to check if the vi's are compiled correctly?

 

 

0 Kudos
Message 3 of 7
(3,093 Views)

You can always mass compile your VIs.

 

There are 2 types of hierarchy here: VI Hierarchy and Folder Hierarchy

 

In TestStand if you set a search directory to a deep folder hierarchy and have it search subdirectories this can slow down all aspects of TestStand....because it has to traverse the entire hierarchy to find each file.  For instance if you put C:\ in your search directories and checked the search subdirectories box TestStand would screech to a halt.  My point in my first post is that if you want to speed up deployment keep your search directories as close to your dependencies as possible.  Also, any hierarchies should be put at the bottom of the search directory list as TestStand goes from top to bottom.

 

VI Hierarchy is the number of descendants a VI has.  You can view these in LabVIEW by clicking View>>VI Hierarcy.  Because you are deploying the VI to a new location then the TestStand deployment utility has to go retrieve all of the descendants and relink them to the new location.  In most cases moving them to a the SupportVIs folder.  So basically if you have a VI with hundreds of descendants it could take longer than a VI with just a few.  Mass compiling your VIs helps this process go a lot faster because the deployment utility doesn't need to sit there and recompile all of the dependencies and relink them.

 

Hope this helps,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 4 of 7
(3,083 Views)

I have my vi's in a SVN repository. When I mass compile everything, SVN shows that some vi's have changes, but others don't. Is this an indicator for vi's that are compiled correctly, and vi's that don't?

0 Kudos
Message 5 of 7
(3,075 Views)

That normal when you mass compile.  Is it still doing the same behavior?

 

Also, I should note that I never build unless my LabVIEW adapter is set to development.  I can't explain why because I don't know what is going on in the deployment engine, but I do know that it is always faster.  My guess is that they have to switch back and forth between dev and run-time and that takes a lot of time...not confirmed though.

 

Regards,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 6 of 7
(3,070 Views)

Sorry for my late reply, after mas compiling everything it still performs slow.

 

When you deploy with the adapter set to development, how do you use the runtime on a deployment system? Because then you need to have a license for each station to run the labview development adapter.

 

 

0 Kudos
Message 7 of 7
(3,049 Views)