NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Deployment utility slow build time

Solved!
Go to solution

I am not very experienced with the deployment utility. I used it to create a deployable image, full deployment, using a workspace file. I did not exclude any files from vi.lib, user.lib, or instr.lib.

 

The build took about 70 minutes. That seems a bit long. Are there any rules of thumb for what slows things down?

 

I have some sequence files of the form "model1.seq", "model2.seq", "model3.seq", etc. They only differ by the file name. Could I perhaps only include one of them in the distrubuted files tab and then add them by manually to the distribution?

0 Kudos
Message 1 of 4
(2,094 Views)
Solution
Accepted by topic author stephenb2

The TestStand Deployment Utility (TSDU) is definitely something that takes getting used to.  Here are a few tips and tricks for shortening your build times:

  • Set up your search directories so that they find the majority of your VIs immediately.  The TSDU uses your search directories to find dependencies.  The more narrow you can make them the faster it will go.  For example don't just use a deep hierarichal path that blanket covers everything.  Instead consider a bunch of shallow paths.
  • Build a different installer fot he TS engine and all of the drivers and run time engines.  This should be a one time build.  This way you don't have to copy 2.5G every time you build.  The end user will need to install both installers but you can get them patches and fixes quicker.
  • Compile your VIs. Compiling your VIs will eliminate the need for the TSDU to do this.  Underneath the hood the TSDU i s copying all of your VIs to a temp directory and adding them to a temp project.  Then it runs a source distribution on that project.  Having them compiled already will make this go faster. (at least I've seen it go faster)
  • Consider dividing your build into smaller chunks if possible.  We us NI Package Manager and divide our code up into test modules.  Each test module is a package.  A test module represents a small task.  Something like a current draw test or a power meter test.

 

Hope this helps,

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

The suggestion of having a separate TS Engine/drivers/etc. installer is a great one. It's a lot of stuff that rarely changes. I also have the development environment on the test stations, and it uses the same directory structure.

 

My code only build is now < 10 minutes.

 

Some observations:
1. I have a lot of python scripts and bat files that get called in a step call executable step or via LabVIEW using a system exec. Those need to be added to the workspace file individually but clutter it up. Perhaps I should probably put those in a scripts directory and just add the directory to the workspace file?

2. I chose to create an image install because it is a given that I will have to remote to the test station and debug in developer mode from time to time. Any thoughts of what to do in that kind of situation?

0 Kudos
Message 3 of 4
(1,995 Views)

@stephenb2 wrote:


1. I have a lot of python scripts and bat files that get called in a step call executable step or via LabVIEW using a system exec. Those need to be added to the workspace file individually but clutter it up. Perhaps I should probably put those in a scripts directory and just add the directory to the workspace file?


It doesn't really matter where they are on disk as long as your search directories can find them quickly and easily.  But yes for maintenance and readibility sake it is wise to put all the scripts in the same location.

 


@stephenb2 wrote:

 

2. I chose to create an image install because it is a given that I will have to remote to the test station and debug in developer mode from time to time. Any thoughts of what to do in that kind of situation?


So think of images as the EXE in LabVIEW.  An image is all of your TestStand code and dependencies collected into a single file hierarchy and relinked.  Even if you create an installer it uses the image.  The installer is just one way to get it to the deployment machine.  You can definitely just create an image and copy it over if you need.  How you run it (i.e. whether you use dev or deployment license) is irrelevant to how you deploy it.

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