07-08-2019 04:22 PM
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?
Solved! Go to Solution.
07-09-2019 10:01 AM
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:
Hope this helps,
07-16-2019 11:03 AM
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?
07-16-2019 11:15 AM
@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.