NI TestStand Idea Exchange

Community Browser
About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 
Post an idea

The separate compiled code flag is great when using VIs and source code control.


However TestStand (2016 SP1) deployment utility builder does not warn if the separate complied code flag is set - This means the VI will not run with the TestStand Deployment Licence without a LabVIEW development system installed. 


I do think the the Deployment utility should have a checkbox to force include the compiled code in all VIs and Controls so it can be run easily with the TestStand Deployment licence and LabVIEW runtime engine. 


Suggested because I have pulling my hair out wondering why a VI on a deployment machine won't run. 

Turns out a type def control had separate compile code flag set!  I even wrote code to clear this flag on VIs and all subVIs - it never occurred to me to check controls!


Also please update the error message in TestStand:


Parameter 'UUTServiceType': -This was a bit of a clue... but the TestStand type matched when I recreated it.
Unable to load VI 'Dialog - Prompt to connect' with the LabVIEW Run-Time Engine version 17.0.
The version of a subVI might not match the version of the run-time engine and the Version Independent Runtime feature is disabled or a VI dependency might be missing.
Try the following steps to troubleshoot the issue:

1. Open the VI in the LabVIEW development system. If the VI is broken, fix any errors in the VI.
2. Force compile the VI by clicking the run arrow while holding the 'Ctrl' key.
3. In LabVIEW, select File >> Save All to ensure that all subVIs are saved in the same LabVIEW version.

4. Check that the separate compiled code flag is not set on the VI or its dependent subVIs and controls (typedefs) when using the LabVIEW Runtime engine. 
Error Code:

-17600; Failed to load a required step's associated module.

Step 'Prompt User to Connect UUT' of sequence 'MainSequence' in 'My testsystem.seq'


{edit1} I also have just realised that running the code with the LabVIEW runtime in adaptor settings worked fine on my development PC as the control's code was in my local object cache. So I was also wondering why it worked fine on my development machine and not on the deployment machine when using the LabVIEW runtime.

Therefore the Runtime adapter should have a setting  to either Disable the Runtime using the local object cache

or an option ot clear the local object cache before running the sequence. This means this issue would have been reproducable on my development machine with the LabVIEW runtime adapter. 


I feel this idea is almost is close to being a bug.... 




  • Deployment

It isn't uncommon to deploy customized TestStand options, such as search directories, on a deployment computer.  It would be much easier to do this if the search directories in TestStand were stored in their own .ini file rather than in TestExec.ini.  You can obviously set the search directories in TestExec.ini quickly using the built-in search directories GUI, but when distributing the TestExec.ini file to the deployment computer, you have to be careful that none of the other options contained in the file don't inadvertently cause problems when executing TestStand deployments.  A separate .ini file for search directories would clearly remedy this situation.

  • Deployment

Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.

For example:

TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.

With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".

Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.


  • Deployment

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use. 







This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.




Kyle Mozdzyn

Applications Engineering

National Instruments 



For the moment Localization files are to be placed in TestStand public or TestStand user paths. Smiley Sad


It should be interesting to move them in a custom directory, which could be configured in the stations options.

(Or defined somewhere in a TestStand project) Smiley Happy


Doing so, would simplify the deployment processus ... and Localization files would not be treated as global files, but project files.

=> When you have to handle with many TestStand project, you could have a directory for each project ... with multiple localizations files different by project !


I think the mechanism of file managment of TestStand should be modified, in order ...


  • To suppress the global files
  • To manage such a kind of project ... (A workspace) ... containing all the file he need !

Doind so, would simplify the deployment process ... to a simple directory copy ! Smiley Very Happy



  • Deployment

It would be great to have the ability to create an independent TestStand configuration that is valid in a workspace context. That would allow project specific search directories, StationGlobals an several other configuration items you normally don't want to share across projects on the same test station.

It is common to want to place a shortcut to a TestStand User Interface or even a TestStand sequence file on the Windows Desktop for each user of a computer.  This is done by placing a shortcut in the Windows All Users Desktop directory.  Currently, the TestStand Deployment Utility only allows you to create a shortcut on the current user's Desktop.  It would be really nice if the TestStand Deployment Utility allowed you to also create shortcuts on the Windows All Users Desktop so that everyone using the computer could see this shortcut on his or her Desktop.

  • Deployment

I know that I can deploy station globals by adding the ini file to my workspace but when deploying them I want the Station Globals to be merged with the existing station globals on the deployed machine.  Please add this as a feature to the deploy utility.


  • Deployment

Although BuildTSD allows for builds from the command line, they are still not automatable because someone must be logged in for the run to work. All of our other build tools (Visual Studio, Eclipse, MPLAB, Quartus, NIOS, Matlab, etc.) allow for headless, remote, automated builds which support our move toward continuous integration, continuous deployment, and agile development.

Currently, the Installation Destionation options are as follows: 




There is no way to install files to the root directory, or its subdirectories, with the exception of those already present in the Installation Destination. For instance, make it possible to install a file to the following directory: C:\ProgramData\IVI Foundation\IVI



I have seen multiple customers who have encounter the following error:



Error: The following VIs or Project Libraries have duplicate names
You must change the names or add them to project libraries:


The issue sources from installing a TS deployment onto your development machine. It is not recommended.  And though the deployment will be able to execute, it can also cause undesired linking errors, as shown in these cases. As a result, some of the VIs called are looking to SupportVIs (even in your development sequence), and other VIs called are looking for the same named VI in vi.lib. There can't be two different VIs with the same name, unless they are in two different libraries.


I suggest that we implement a warning when such an installation is started or even an error which prohibits installation fo the deployment.

  • Deployment

It would be nice to be able to create installers from existing images that were created previously using the TestStand Deployment Utility.  It would also be nice to be able to pause the TestStand Deployment Utility between the image creation and the installer creation.

  • Deployment


* Why not include Configuration files, such as TestExec.ini by default in Deployment Utility?


* Also using default settings, nothing appears in the Start Menu/All Programs menu on the target machine. Why not have the main sequence file to be installed so that it appears in the Start Menu/All Programs menu on the target machine?




  • Deployment

Recently I have been involved in 2 Projects which deployed the test solution to PCs with disconnected deploy licenses

On both projects it was very labour intensive, there were some strange failures that were seen , related to the different licences and which were only highlighted when running with LVRTE and Teststand base deployment license. On each occasion it felt that even though the development machine had proven the solution it still required significant effort to prove and integrate the deployment image 


My suggestion is to allow the developer to configure their development PC NI licence manager to replicate the PC that will run the deployment.

The Development machine would obviously need to have the development suite licences, all child licences related to the development licence would be available in the NI Licence manager . The developer would then have the option, to configure the licence manager to use the desired licenses. Ie TestStand Base deployment & switch executive deployment.


With a TestStand solution on a development machine the deployed image could then be tested before its deployed to its destination PC


1.The adaptor settings can be changed for the code modules to Run Time

2.The TestStand Search directories can be configured to use the deployment target image

3.And the licencing could be changed to replicate the deployment PC 


Realise that points 1 & 2 above should iron out most of the issues with the deployment licence and its mainly on new deploys that the integration is painful, but having the option to select the licence to test on the development PC will help a lot to speed up the integration.




  • Deployment

I use the Stationglobals.ini to define my hardware settings on the test PC, like comport number and so on. It is running Teststand Base Deployment.

If I want to edit the settings it's only possible if I copy the stationglobals.ini to my development PC which has the full license, edits the settings, and then copies the file back to the test PC. Before I copy the file to my development PC I need to make a backup of the original file, so I don't get the settings on the development PC overwritten. Then afterwards I have to re-establish the backup.


This is a lot of copying back and forth, which is quite annoying.


Please make it possible to edit the Stationglobals.ini directly on the test PC with the Base Deployment Engine.

See Also

Simulated Devices in LabVIEW projects

Project and Workspace Context in MAX


Link to those ideas in next post


We can already create tasks, channels and scales in a LabVIEW project but, We cannot then use MAX to run those Tasks and we must use MAX to create a simulated device on a development machine.  After a few projects the Max configuration becomes cluttered.  Deployment and importing of the hardware configuration can get problematic to say the least! 


On the other hand- if the Hardware, Data neighborhood and IVI session set-ups could be added to the workspace, deployment would be a snap! just import the *.nce from the workspace without having to create one from MAX and exclude items not concerned for the deployment.


For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by deployment in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.

Often, multiple sequence files are deployed on the same test computer.  A convenient way of differentiating between them is by changing their icons.  Although this can be accomplished through custom commands invoking VBScript, it would be nice if the TestStand Deployment Utility provided native support for customizing the icon of a deployed sequence file.

  • Deployment

Even though we already have an About box for TestStand, it would also be nice to have one for the active TestSequence file as well. The Help menu would have a new item called "About MySequenceFile ...".


MySequenceFile About box splash screen:



The information in this screen should be loaded directly from a single FileGlobal string whenever a sequence file is made active. This can probably be done already by those that know how, but it should be already part of TestStand by default.




0 Kudos

There is a major flaw with packed project libraries in LabVIEW.  That is that they pull the dependencies in to the same folder as the PPL.  For example if you use advanced math functions then lvanlys.dll will be put in the directory.  The problem is that LabVIEW doesn't like it when you try to load multiple files with the same name.  So if I have a test system with multiple ppls that use the same dependencies I could potentially run into collisions.  There is a document here that discusses a solution for this:


I would like to see the option to prefix my dependencies for PPLs.  This could easily be added to the Packed Project Library Options dialog. 

  • Deployment
0 Kudos

It would be great to have an option in the TestStand Deployment Utility to clear the ReloadLastWorkspaceAtStartup flag in the TestExec.ini file when making a deployment.  


I usually keep the flag set to save a step when developing code, but when I'm getting to the stage where I need to deploy to continue development and testing, not having this cleared results in an error that pops up on every first launch after installation.