NI TestStand

Showing results for 
Search instead for 
Did you mean: 

errors in TestStand Deployment process

Hi everyone!

I've almost completed my project development process and now it's time to build a Deployment file in order to deploy in station system. I've have used "MSI-Based Installer" as an option of Output Type.. but I have no reason for that , so I may use other option too.. I'm not that much familiar with the Deployment settings and the process so let me copy here some screenshots of my setting in TestStand Deployment Utility. in addition I've used LabVIEW code modules. 
please let me know what I'm doing wrong here and what should I have consider..

thank you in advance



LabVIEW Version: 2018-64bit

TesStand Version: 2019-64bit

in "Mode" tab I've set:



in "System Source" I've set:

System Source.JPG


in "Distributed Files" tab I've set:

Distributed Files.JPG


in "Installer Options" tab I've set:

installer option.JPG


and finally in the "Build Status" tab I get this error:

build status.JPG


0 Kudos
Message 1 of 5

TestStand deployment can certainly be tricky and has caused a lot of pain for a lot of people historically.  Before I talk about what is going wrong with your deployment I'd like to mention that NI Package Manager is really the only way to deploy TestStand nowadays. It makes life so much easier if you know what you are doing.  Now on to your issue:


  • I noticed that you are including both the .lvlib and the .lvlibp files in your deployment.  You should only need one, unless you are calling both of them from TestStand, in which case you should fix that and only call one (preferably the .lvlibp file).
  • In TestStand your adapter for LabVIEW needs to be set to Development Environment.  The deployment utility uses that to analyze sequence files to relink and compile VIs.  This is most likely what's causing that issue.
  • Another key is that your search directories need to be set up properly so that TestStand can "see" all of the code directly called by a sequence file.  I'm assuming this is correct if you have it working in the sequence editor.
  • If you open your .lvlibp file in LabVIEW are any of the VIs broken?
  • There are other things to try but I would start with those.  Also, the goal with deploying TestStand is to try and isolate the problem.  Turn off the installer when isolating.  It just adds longer build times and is unnecessary for debugging.  This is because TestStand creates the image first and then uses that to build the installer.  Most of the time if you can build the image the installer is easy.  So to isolate the problem start removing things from your build.  Unchecking things on the Distributed Files tab.  And see what builds.


Hope this helps,

~Will work for kudos and/or BBQ~
Message 2 of 5

thank you ~jiggawax~ for your kind reply 💙


1- I call .lvproj file as my project path and I call the the VI via .lvlib as my VI path.. so I removed .lvlibp file from the LabVIEW Project file, but when I delete the .lvlibp file from the folder, I get an error when the Deployment Utility perform Source File Analyzes..






2- I changed the test stand adapter setting for LabVIEW and set to LabVIEW Development System but get the same 18002 error.


3- I think the search directories are fine because as you mentioned I have it working in the sequence editor.


4- There is no broken VI when I open the .lvlibp file


5- When I uncheck all things on the Distributed Files tab and hit the build button, the build process finishes successfully.. but I didn't get the reason why we did that.


6- Is it possible to perform the deployment in an easier  way? as you mentioned .. with NI Package Manager?


7- I have installed TestStand and LabVIEW and tested the whole UUT test process on the test station system (which is a MSI All In One PC) but the execution speed is almost half of the execution speed on my Development system.. will the deployment help it? 



thank you in advance

best regards


0 Kudos
Message 3 of 5

I don't know why but i've never used the project path like you have.  I've found that it tends to screw things up.  And in fact it looks like your relative path for the VI seems a bit off.  I would remove the project path from the VI call and just call the VI straight up.  I know they've had bugs with the project paths in the past but I'm not recalling what those were.


On point number 5 from your previous message.  The point was to uncheck one thing at a time to see what the culprit really was and try and isolate the issue.


If I were in your shoes I would take the .lvlib and build it into a .lvlibp.  And then just call the .lvlibp directly from TestStand.  This way the deployment utility doesn't have to build any LabVIEW code.  Unless you are calling other VIs that are not in the .lvlibp, then you'll have to figure out how to deploy those.


Also, can you share your LabVIEW Options from the Deployment utility.  On the Distributed Files click on the LabVIEW options... button.



~Will work for kudos and/or BBQ~
Message 4 of 5

Hi Jigg thank you for your reply and excuse me for my delay. I have faced another problem so the deployment process is going to be postponed. but actually it is a little bit headache to deploy.. as you mentioned in your earlier message. I will try to back to deployment as soon as I solve my new problem 💙



best regards


0 Kudos
Message 5 of 5