TestStand Deployment 5-7 hours?

I've been trying to deploy my TestStand system for hte better part of a week, and I am losing patience. I have deployed a few systems in the last few years, but this one has been difficult. I am deploying the sequence and the engine/drivers separately. The engine/drivers deployment builds quickly, so no problems there. The sequence build takes 5-7 hours to build with most of the time "Updating file Links..." I have confirmed that all sequence call pathnames specify <Current Sequence File>. My main sequence has 47 sub-sequences (sequence calls), and my total number of steps is 699. When built, there are 69 support VIs. I don't use an ExpressVIs.
I've done previous builds on another system with similar tests, but the sequence-only builds took < 1 hour.
I am looking for suggestions on how to decrease the build time. Perhaps I am overlooking something that would cause the deployment ot build so slowly.
Thank you
Solved!
Go to Solution.

Hey TBone,
A couple thoughts.
Are you using source code control? If so then I've seen issues similar to yours due to search directories. The linking took forever because it seemed to be finding VIs through the network path and through the drive that was mapped. It seemed like it was getting confused and kept relinking the same VI over and over. Because it saw them at different paths. Kinda like in a semi-infinite loop. It was weird. I refined my search directories to point to specific folders (a pain) but it went a whole lot quicker.
Check your search directories and make sure they are set up correctly. If you have a directory with tons and tons of children and you have selected search subdirectories then it could take forever. Also if you have search directories that are pointing to similar folders just in different ways (i.e. through a mapped drive or through a machine name) then you could see weird linking issues.
If you aren't using any dependancies on a network then unplug your ethernet cable and try building. See what happens then.
Also, I highly recommend deleting any and all older deployments. Because TestStand doesn't package anything up into binaries (i.e. it just copies VIs over) then what you could have is the deployment finding the VI in the original location as well as a deployment you built previously. This will cause it to flip out and go into that weird semi-infinite linking loop. If you don't want to delete them then make for sure that your search directories aren't pointing to old builds.
As a rule of thumb- never build to a folder where you have dependancies or source code. Always build to a user folder that is not in your search directories.
Cheers,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Similar Messages

Unable to include Operator Interface in TestStand deployment

Hello. I have created a test system using TestStand 3.5.
There is only one sequence file, and this sequence calls several VIs
that I have created in LabVIEW 8.0. I would like to distribute
this test system to a target computer, which will then run the default
Operator Interface. No bells and whistles, just plain and
simple. However, I'm running into problems.
First, I created a Workspace file in TestStand. I then added a
Project to it. In the Project, I added all necessary files for my
project (the sequence file as well as all of the custom VIs).
Then I proceeded to follow the TestStand reference manual in order to
deploy my system.
For reference, text in italics is the reference guide and text in bold is my comments.
Deploying the TestStand Engine
1. Launch the TestStand Deployment Utility by selecting Tools»Deploy
TestStand System from within the sequence editor.
I did this, and set up my build how I wanted it.
2. On the System Source tab, enable the Deploy Files in TestStand User
Directories option.
This option collects files from the <TestStand>\...\User
directories, so that any customizations that you have made to process
models, step types, language strings, and so on, will be distributed to
the target computer.
I did this, and copied my Operator Interfaces\NI folder to Operator
Interfaces\User. This would assure (I hope) that I would have the
default operator interfaces included in my project.
3. On the Installer Options tab, enable the Install TestStand Engine
option.
Done.
4. On the Installer Options tab, click Engine Options to launch the
TestStand Engine Options dialog box, which you use to select the
TestStand components that should be present in the installer.
Done. Everything is checked.
In the TestStand Engine Options dialog box, expand Operator
Interfaces»Full-Featured in the tree view.
a. Click the X next to LabWindows/CVI to include the
Full-Featured LabWindows/CVI Operator Interface in the engine
installation. The X should become a green checkmark.
b. Click OK to accept the new settings and close the dialog box.
This is where things go wrong. There is NO Operator Interfaces box in my tree view. It simply doesn't exist.
I've tried several different builds using different strategies.
I've done builds with the CVI operator interface in the User directory,
and I've also tried copying over the files manually. On the
target computer, I've always gotten either an error message (Could not
open the TestStand Engine), or else TestStand opens in evaluation
mode. In both cases, my custom VIs and sequence files are nowhere
to be seen. Can anyone shed some light on this? It's
driving me a bit crazy!
Thanks very much,
Brett Gildersleeve

Hi Brett,
Whenever you deploy your TestStand application to target machines, you will always needs a license. The licenses for distributing TestStand are different than for distributing LabVIEW and LabWindows/CVI code modules.
LabVIEW does not require you to purchase any run-time licenses for a deployment system. You can even run LabVIEW VIs in VI format (not executables) from TestStand without using the development environment and without an additional license.
In order to run LabWindows/CVI code modules, you will need the LabWindows/CVI Run-Time engine which is also available free of charge.
Regarding TestStand, you will need a license for each machine that runs a TestStand sequence. TestStand has three types of licenses which are the TestStand Development System License, the TestStand Debug Deployment Environment License, and the TestStand Base Deployment Engine License.
TestStand Development System License
The TestStand Development System License is required for any test sequence development and/or editing of existing TestStand sequence files that you perform within the TestStand Sequence Editor or programmatically using the TestStand API.
TestStand Debug Deployment Environment License
The TestStand Debug Deployment Environment License gives you maximum flexibility for deploying TestStand and LabVIEW, LabWindows/CVI, and Measurement Studio-based systems. This license allows you to install the development versions of TestStand, LabVIEW, LabWindows/CVI, and Measurement Studio, along with any corresponding add-on toolkits, so that you can debug your test application on your deployed test station. This license does not include the ability to perform any development tasks within the TestStand Sequence Editor or programmatically using the TestStand API.
The TestStand Debug Deployment Environment License has debugging capabilities including settings breakpoints, monitoring variable values, and stepping into test code directly from the TestStand sequence.
(Note: This license does not provide the software but rather gives you the right to install a previously purchased piece of software on the target machine.)
TestStand Base Deployment Engine License
The TestStand Base Deployment Engine License is the minimum license required for all deployed TestStand-based applications. This license allows you to deploy the TestStand Engine, a TestStand Operator Interface, and TestStand sequence files to the single test station for which the license is applicable.
The TestStand Base Deployment Engine License provides simple sequence debugging capabilities, including setting breakpoints and single stepping through test sequences in your Operator Interface. You cannot save sequences and open the sequence editor.
I hope this clears things up.
Best Regards,
Jonathan N.
National Instruments

TestStand Deployment Engine Serial Number

Is there a way to get the Serial Number/License of a TestStand Deployment Engine that is installed on a PC?
The NI License Manager does not report the Serial Number of the Deployment Engine.
I have even tried to search the Window Registry.
We have over 100 TestStand Deployment Licenses in our installed software database. Split between BASE and DEBUG Deployment.
But I can’t find any way to tell/verify which license is on which machine. Just about all are on XP machine that are in need of replacement.
Just about all are TestStand 4.1
Omar

First of all I'm sorry that NI convinced you that a Debug deployment license was a viable option... I actually didn't know people would purchase those. That's funny.
So the license files are stored in %ALLUSERSPROFILE%\National Instruments\License Manager\Licenses. I was hoping the serial number would be in there. But it's not.
One thing you might want to consider to manage this a whole lot easier is to talk NI into giving you a VLM that you can put on a server and adding all your deployment licenses to it. We do this and it has saved us thousands, if not 10s of thousands of dollars. Now we can manage all the deployment licenses on the VLM. It has also forced us to follow the NI license agreement a lot closer than we were.
Sometimes you can't have all the computers on the LAN. In this case you can just assign disconnected licenses but still have VLM manage it for you.
Your last option would be to set up your own spreadsheet and manage it in there.
We were in the same boat as you a few years ago. So we contacted NI and got a list of all the licenses we had purchased in the last 10 years and threw them up on VLM. Then we had IT go through and look for a specific license file with an activated code inside of it on all the machines on the LAN. We got that list and contacted each of the PC "owners" and had them switch to point to VLM. In most cases we found the licenses weren't needed anymore so we could transfer those.
Hope this helps,
jigg
CTA, CLA
teststandhelp.com
~Will work for kudos and/or BBQ~

Problem with deploying FPGA host VIs using TestStand deployment utility

I am using a PCI-7831R FPGA to control an automated test fixture. I have several host VI's that I am calling from TestStand (4.2.1) in order to control the 7831R. The host VI's that TestStand calls are setup as sub-VI's and are used for various things such as opening an FPGA reference (which is bound to a strict type def), downloading and executing the files on the 7831R, reading writing to controls, and finally closing the reference. In the sequence file, I am passing the reference values as a file global so that the host sub-VI's can communicate correctly. I have all functionality working correctly in TestStand on my development PC. When I go to deploy this to a production PC, I get errors when the sequence file trys to load the first host VI. The error basically states that the VI is broken - try to open and run it (which I can't because I have no development license on the production PC). I am currently trying to deploy this to another development PC to see if I can track down where the VI might be breaking.
I have included the lvbitx and strict type def control that the host subVI's reference in my deployment files. I can't think of anything that I might be missing. Is there any good documentation on exactly which files I need to include in the deployment when using FPGA Host VIs (the TestStand reference manual is pretty vague at best)? It seems that any documentation that I read says the TestStand deployment utility will analyze all VI dependencies (other than shared variables). On a side question, is the strict type def considered a shared variable?
Has anyone successfully deployed a sequence that calls host VI's? Any help would be greatly appreciated. If any of the above needs further clarification please ask away and I will be happy to give more details.
Thanks,
Mike

Hi hawkstringer
Do you encounter this problem using a deployed version of your code? Note that the subject of this topic is about deploying an FPGA application.
I forgot I posted here, in the mean time I've managed to deploy my application. I think my problem was solved when I included all necessary drivers and components (but I'm not absolutely sure). I included the following:
NI IVI Compliance Package
NI FlexRIO
NI PXI Platform Services Configuration Support
NI R Series Multifunction RIO
NI DAQmx Core Runtime
NI DAQmx MAX Configuration Support
NI RIO
Good luck!

Why doesn't my TestStand deployment installation show up under my Windows start menu of my target machine?

Why doesn't my TestStand deployment installation show up under my Windows start menu of my target machine?
I have successfully installed working deployments to target machines. However, I was expecting to see the installation listed as "My TestStand System A" in my start menu, but it is not. Am I misunderstanding something here?
Also, if I peform a different second deployment to the target station like "My TestStand System B", all of the LabVIEW files from my previous installation for "My TestStand System A" disappear from the target directory (c:\Program Files\My TestStand System A).
I am using TestStand 4.2.1 Professional on the development station with Windows XP and LabVIEW 2009.
Solved!
Go to Solution.

Thanks Paul,
That solved my second problem and inspired me to search deeper for the answer to my first problem. The answer is in the "Distributed Files" tab, "installer properties", "Create a Program Item" checkbox:
Wouldn't it be nice if this was automatically checked by default for the main sequence files? Wouldn't it also be nice if "Upgrade Code" was automatically regenerated by default whenever we saved the *.tsd file under a different name?
Thanks again,
Eugene
Message Edited by Eugene12 on 05-06-2010 04:27 PM

Can a TestStand deployment built with XP run on a target machine running Windows7?

All,
I knew it would come to this eventually. My very reliable development machine is running Windows XP. I am now facing the situation of building a TestStand deployment to distribute to target machines that are running Windows7. I am trying to head off trouble and troubleshooting that may not be worth it. Will this work?
Thanks in advance for any information regarding this situation.
Troy

Hi Troy,
You shouldn't run into trouble, but you may want to be aware of the differences in directory paths.
Cheers,
KyleP
Applications Engineer
National Instruments

Assessing Command 'Analyze Source Files' via Command Line when running TestSTand Deployment Utility

Our Software Configuration Manager is running the TestStand Command Line Deployment Build Tool (Ref: https://decibel.ni.com/content/docs/DOC-38947).
        When he builds the application, the code will not be at the same location it was in development.
If you are Manually running the TestStand Deployment Utility, This is not a problem because everything is relative in the workspace.   Simply go to the Distributed Files Tab (of TestSTand Deployment Utility) and hit the, "Analyze Source Files" button. This finds the required files and apparently creates an updated hard path to be used during the build (probably in the *.tsd).
PROBLEM: We auto-run the Command Line Deployment Build Tool (Command Line), and we do not have access to the, 'Analyze Source Files' command.
            As a result, our build consist of many warnings and the output is missing many files (the location of the files have not been updated).
If we could access the 'Analyze Source Files' Command via command line, that would fix the issue.
FYI: We use an automatic builder called Quick Build as our builder.
Attachments:
TestSTand Deployment Utility-Distributed Files Tab.PNG ‏76 KB

Unfortunately it looks like Analyze Source Files does not have a command equivalent for the command line based on this article and attached PDF:
https://decibel.ni.com/content/docs/DOC-38947
That may be a good post for the TestStand Idea Exchange for consideration in future versions of TestStand.
Michael K.

TestStand Deployment Not Installing Files

TestStand 3.1
We have created a custom OI and Process Model and we have attempted to
create an installer using the TestStand Deployment Utility. The
problem is that when the installer is first run on the target system,
some files are not being installed. We had a similar problem with
the Distribution Kit functiontionality of CVI 6, and were never able to
fully resolve the issue.
Basically the installer examines files that already exist on the target
machine and will not overwrite them if they have been modified.
The installer is smart enough to examine version numbers inherent to
DLLs and EXE files (and adding REINSTALLMODE=amus to setup.ini causes
these types of files to always be overwritten). However, for
other files such as *.ini and *.seq files, there seems to be no way to
force the installer to overwrite these files.
The workaround that we used previously was to run the installer 3 times
(once to install, once to uninstall which deletes all files including
the old versions that were not overwritten, and then once to actually
install the desired files). Is there a way around this with the
TestStand Deployment Utility? We are actually considering
bypassing the installer altogether and just copying the files in the
image directory that the Deployment Utility creates.
Thanks,
Peter

Hi Peter,
Thanks for the information. I am not sure if the installer will recognize the sequence file version number. Are you deploying a Process Model from the NI folder, or have you copied it into the User folder? Are you adding the Process Model and INI files to a project in your workspace and deploying the workspace or are you deploying them by selecting to Deploy Files in TestStand User Directories on the System Source tab of the Deployment Utility?
In other words, what file specifically are not being installed correctly? What is their path on the development machine and what is the target path?
One last question, if the target is a new system and has not had a TestStand test system deployed to it, how does it have sequence and TestStand INI files on it already? Are you installing TestStand on the target machine before deploying a test system?
Regards,
Eric M

LabVIEW VI causes TestStand Deployment to fail

Hello,
I have a problem with the attached VI. Any time I include it in a deployment, I get an Error that says "Internal Error Code 1 processing VIs... Installer not created due to an Error"
The VI and a simple sequence file are attached.
Attachments:
IsMyProcessRunning.vi ‏13 KB
ProcessTest.seq ‏5 KB

Simon,
The following (below) is the Deployment improvements for TestStand 4.2. I haven't been able to look at the VI of the original post so I dont know of the actual problem but there are still issues with the deployment tool in TS4.2
Regards
Ray Farmer
TestStand Deployment Utility Improvements
The TestStand Deployment Utility now uses improved internal caching to accelerate analysis and build times. Additionally, the LabVIEW VI Options dialog box includes the following new options so you can choose between faster performance and improved error handling:
Check for Broken VIs During Analysis—When enabled, the TestStand Deployment Utility checks for broken VIs during analysis. This option is disabled by default to improve performance. Enable this option when you want to debug VI errors.
Check for Broken VIs After Build—When enabled, the TestStand Deployment Utility checks for broken VIs in the image directory when building an image. This option is enabled by default to ensure that distributed files do not contain broken VIs. Disable this option for better performance if you are rebuilding and have not made changes to VIs.
Remove Unused SubVIs—Removes unused polymorphic subVIs and disconnects type definitions when building. This option is disabled by default for backward compatibility. Enable this option for better performance and to deliver a smaller number of subVIs.
Note Enabling the Remove Unused SubVIs option disables certain editing and debugging options on the deployed system, such as wiring a new type to a polymorphic VI or making type changes across several VIs by editing a type definition.
The Deployment Utility also better integrates with LabVIEW 8.6.1 or later for improved build speeds and deployment of advanced LabVIEW features, such as VIs that include LabVIEW object-oriented programming.
The Installer Properties section of the Distributed Files tab of the TestStand Deployment Utility also includes a new Force File to Install option. Enable this option to force the installers the deployment utility builds to always overwrite existing files.
Refer to Chapter 14, Deploying TestStand Systems, of the NI TestStand Reference Manual and to TestStand Deployment Utility for more information about the TestStand Deployment Utility.
Regards
Ray Farmer

Teststand deployment error

I am getting the following error when I try to create my Teststand deployment files from my workspace:
Error Code:1035
Could not process LabVIEW VIs. Fix any broken VIs before rebuilding. LabVIEW error:
Invoke Node in TestStand - Dist Chg and Save VIs.vi->TestStand - Dist Build LLB Image.vi->TestStand - Build VI Distribution.vi->TestStand - Build VI Distribution AX Wrapper.vi->TestStand - Build VI Distribution AX Wrapper.vi.ProxyCaller
Anyone know what's happening here or how to fix the broken vi's this references?

Hi,
Check that all your VI's are Ok and that there are no broken arrows. One way would be to mas compile your LLB's/VI's that you are trying to deploy.
Regards
Ray Farmer
Regards
Ray Farmer

TestStand Deployment Error Code 1055 when using LabVIEW Storage VIs

After a couple of days of playing with the TestStand Deployment. I final tracked down the VI that was causing this Error.
It was using thethe LabVIEW Storage VIs to save data to a TDM file.
My work around at the moment is to use a Wrapper VI and call this VI by reference.
That way the TestStand Deployment can't detect the Storage VIs.
I'm using LabVIEW 8.6.1 and TestStand 4.1.1 does anyone know if this issue has been address in TestStand 4.2?
Looks like the upgrade might be worth it.
Simon Holman
Software Engineer
Certified LabVIEW Developer
Certified TestStand Developer
measX GmbH & Co. KG.
http://www.measx.com
Solved!
Go to Solution.

Hi Simon,
I tested your sequence file in TestStand 4.2 and I didn't get any error! Which version of TestStand do you have? Can you post a screenshot of the complete internal error pop up?
Usually internal errors can be eliminated with the Clean Reinstall Procedure.doc, where you will remove all NI software and all references to NI software from your computer to start over with a fresh installation!
I hope these informations help you!
Best regards
Suse
Certified LabVIEW Developer (CLD)
Attachments:
Clean Reinstall Procedure.doc ‏32 KB

Teststand deployment error -17500

Just wondering if anyone had seen this error before (also attached jpg):-
Starting Log.
Processing Workspace...
Done processing workspace file
Error Code:-17500
Unknown System Error in TestStand - Read Seq Files in Workspace.vi->TestStand - Find Dependent Files.vi->TestStand - Add File and Dependent Files.vi->TestStand - Process Workspace File.vi->TestStand - Update File Info.vi->TestStand - Distribution Wizard GUI.vi->TestStand - Deployment Utility Splash Screen.vi
+++++++++++++++++++++++++++++++++++++++
My build hasn't been changed - I simply got the latest versions of files from sourcsafe and went for a build. I've tried rolling back to previous versions of sequences and vi's but still get the same error. The error isn't particularly specific so I'm not really too sure where to start debugging it - especially when it appears nothing has changed!
Any replies appreciated.
Message Edited by davidpcl on 04-25-2006 05:28 AM
David Clark
CLA | CTA
CLA Design Ltd
Hampshire, England
Attachments:
Teststand Build Error.jpg ‏44 KB

Hi,
here is a link with the same symptoms as yourself. Doesn't look like it was resolved but may highlight something for you to check.
http://forums.ni.com/ni/board/message?board.id=330&message.id=9578&query.id=86918#M9578
Regards
Ray Farmer
Regards
Ray Farmer

TestStand Deployment Installer Media Spanning

I am creating an installer from the TestStand Deployment Utility. There is a media spanning option that permits selection of various media sizes: CD, extended CD, DVD, etc... I have created a deployment / installer (659MB) that exceeds the threshold for the standard CD (650MB). I would expect 2 volumes to be created in the deployment /installer build directory: Volume 1 and Volume 2. This is not the case, only Volume 1 is created, it exceeds the 650MB limit.
Thanks.

dpg -
Were you able to test this with a custom media size like 250 MB? Both Shawn and I were able to get the 650 MB and 250 MB media spanning scenarios working. I'd like to rule out the possibility that your deployment is so close to 650 MB cutoff that the media is not being separated into 2 volumes.
If the custom media size (250 MB) case also fails for you, then we will have a better idea of what might be causing this.
Manooch H.
National Instruments

TestStand Deployment problems with visarc issues

Recently I attempted to rebuild a TestStand Deployment that I had build just 1 month before and it wouldn't create the deployment. Changes that occurred between the last build and this build was an upgrade to LV 8.6.1 from LV 8.6.
The issue was that the file visarc was not able to be found by the deployment engine and wouldn't progress much beyond the tsw file verification. It turned out that having multiple versions of LV on my harddrive screwed up the linking on this file and caused the deployment to fail.
The following link solved the issue and allow the deployment to be built:
http://digital.ni.com/public.nsf/allkb/833BFD5E9CA0224886257584004DAA4C
I don't really have a question, just wanted to get this out there so fewer people have to sustain the pain that I went through.

Thanks for the input
Regards
Ray Farmer
Regards
Ray Farmer

TestStand Deployment Utility API

Is there any API for the TestStand Deployment Utility I can use in labview to automatically launch a TSD file and build the deployment. I would like to create a little labview program which automates the whole process of creating deployments for me, especially when it is a minor change in subVI underneath, and none of the deployment configuration needs changing.
Any info would be appreciated!

Hi kewsvnet
Sorry the the delay in getting back to you.
There isn't currently a TestStand Deployment Utility API for LabVIEW, the closest I think you can get at the moment is to do a command-line deployment build by calling the System Exec VI.
i.e.
"C:\Program Files\National Instruments\Teststand 2010\Components\Tools\Deployment Utility\DeploymentUtility.exe" build "C:\mydeployment.tsd"
As the string input should build mydeployment.tsd
Note:This is an undocumented internal feature we use for Testing the deployment utility. The interface is very limited - you can do a build but there is no way
to set parameters and no return value so you have to parse the log to determine if the build succeeded. There is further discussion of this here in a previous forum post.
Kind Regards
Chris | Applications Engineer NIUK

TestStand Deployment 5-7 hours?

Similar Messages

Maybe you are looking for