NI TestStand Idea Exchange

Post an idea

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

ie.

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.

View All (4)

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.

Thanks!

When deploying from a workspace file, TestStand analyses the VIs it has to include in the deployment package. However, when working with plug-in classes, TestStand will add the parent of a plug-in class, but not its children. Possibly because these are not directly used (they are included at runtime), and thus not recognised during analysis.

I would like to see that TestStand recognises a parent class it includes in the deployment, and then:

includes all its child classes that are in the same project file;
asks to include possible child classes that are not in the project file.

Hello,

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

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)

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 !

Thanks.

Manu.net

View All (1)

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.

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.

View All (9)

Simulated Devices in TestStand Workspaces

Simplify exporting arrays of properties

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.

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

Merge Stations Globals on deployment

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.

View All (7)

Automatically Select Workspace File

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.

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.

Eugene

View All (12)

NI TestStand Idea Exchange

Teststand/Labview/CVI/Switch Exec etc.. Licence selection

Quick switch between the release and debug dll

Add support for relative paths and Environment Variables in the Installation Destination for Installers

Include plug-in child classes to a deployment package

Create Installers in TestStand Deployment Utility from Previously Created Images

It would be nice if the TestStand Deployment Utility provided native support for customizing the icon of a deployed sequence file

Allow to move localization ini files, somewhere else than in defaut Teststands paths ...

Remove search directories from TestExec.ini

TestStand Deployment Utility should support shortcuts to All Users Desktop Directory.

Option to store an independent TestStand configuration with workspace

TestStand Deployment Utility: Have the root directory as an Installation Destination in the Distributed Files tab

Simulated Devices in TestStand Workspaces

Simplify exporting arrays of properties

Merge Stations Globals on deployment

Pop up to stop or at least probit Deployment on Development machine

Automatically Select Workspace File

Make it possible to edit Stationglobals from the Teststand Base Deployment License

MySequenceFile About box splash screen

Cross-linking the wrong LabVIEW VI code modules

Include Configuration files, such as TestExec.ini by default in Deployment Utility