NI TestStand Idea Exchange

Post an idea

It would be nice to have an Auto-populating folder option for TestStand projects much the same way that LabVIEW project do.

Folders added to TestStand projects are snapshots of the folder's contents when added. Any files added to the folder on disk afterwards are not marked for inclusion with the deployment at analysis time. This behavior is fine as a default.

However, there are times when you do want to automatically include all files in a folder. Having an auto-populating folder option would mark the folder and all its contents for inclusion automatically with the deployment at analysis time. After analysis is over the user could still choose to uncheck any files they wish before selecting the build button.

From version to version, it's only natural that developers will be adding new files to established folders. Since the TestStand project doesn't aid in development activities, it's easy for folks to forget to add files while they're developing. We often have a faulty build or two with each release because necessary files aren't making it into the build. We ultimately have to delete the folders in the project and re-add them, then go through the hassle of fixing the paths and included files. An auto-populating folder option that integrates with the build utility would save us time and headaches.

View All (4)

The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.

On many an occasion I've wanted to wrap the following basic functionality:

Run a specific sequence file (with or without a [typically custom] process model)
Wait for it to complete.
Retrieve the result.

It's something I've needed to do in all of the following situations:

Integrating into a customer's existing framework
Integrating into my own automated test framework
Providing a simple API to a customer
Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls

The solution I've ended up defaulting to in the past has been some variation on:

Start with the full-featured C# UI.
Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.

The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.

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!

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

TestStand should use Workspace and Projects properly when determining the folders and files used for deployment. It should not default to reproducing the on disk source structure for your deployment.

I develop in a folder called: C:\Development\ProjectFolder\.
I create a workspace, a project, and add the ProjectFolder to the project.
I load the workspace into the Deployment Utility.
In the Installer Options tab I set my Default Installation Base Directory to "Windows Volume (C:)"
In the Installer Options tab I set my Default Installation Subdirectory to "ProductionSW"

I would expect the Project Folder and its contents to be the ROOT of my deployment placed in the C:\ProductionSW\ folder. My resulting installer should create C:\ProductionSW\ProjectFolder\

However the Distributed File Tree Views show:

View Workspace

Workspace.tsw
- Project.tpj
  - ProjectFolder
    - source Files and Folders

View Source

C:
- Development
  - ProjectFolder
    - source Files and Folders

View Build Preview

Installation Directory
- Development
  - ProjectFolder
    - source Files and Folders

By default when I build the deployment it installs my software at C:\ProductionSW\Development\ProjectFolder\

The Development folder is not in the workspace or project. It is not referenced in any of the source files (as all paths are relative). I understand why it's in the View Source as that's where it resides on disk. However, the workspace/project should be used as the basis for the deployment not where things are on disk.

The source starts at ProjectFolder and that is what I expect to be deployed to my Default Installation Base Directory\Default Installation Subdirectory folder.

If the workspace and project aren't used to define your project code then what good are they in the Deployment Utility?

Type Files have a feature to combine files from an install: files prefixed with 'Install_' get merged file existing file (explained here).

I am building a ModelPlugin, and I would like it to be enabled and configured in the Result Processing after install (users should intentionally opt out of using the installed plugin instead of opt-in). The settings are saved in ResultProcessing.cfg, and there is no merge feature available. Placing my own ResultProcessing.cfg will remove any previous settings the user had configured (or other plugins). I would like to be able to place a 'Install_ResultProcessing.cfg' that gets merged upon TestStand launch similar to type files.

View All (2)

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 (1)

There is rudimentary Command Line Interface (CLI) integration in the TestStand Deployment utility. Its undocumented, and is one flag. "build". Which is useful, but the fact that my only option to determine if the build succeeded is manually parse the build output log is cumbersome and error prone.

In a world where continuous automation and build automation are becoming daily buzzwords, additions to the CLI are sorely missing.

I don't necessarily need to be able to do much from the CLI, but having control and the ability to read back status on a build would be tremendous.

https://forums.ni.com/t5/NI-TestStand/Running-the-deployment-utility-from-the-command-line/td-p/1624948

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:

https://forums.ni.com/t5/LabVIEW-Development-Best/Packed-Project-Library-Pitfalls/ta-p/3523762

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.

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.

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.

Hi,

Several years that I'm facing this issue : I'd love to be able to rename a file when building my TestStand project image.

It would be particularly nice to ease the installation of a Type Palette thanks to this feature (taken from TS help):

TestStand also searches the TypePalettes directory for type palette files with the Install_ prefix. When TestStand finds a type palette file to install with a base filename that is not the same as any existing type palette file, TestStand removes the Install_prefix and adds the type palette to the type palette list. When TestStand finds a type palette file to install with a base filename that matches an existing type palette, TestStand merges the types from the install file into the existing type palette file and deletes the install file. This method is better than modifying the existing type palette file because this method is more modular and flexible for deployment and updates.

So, in my project I made a type palette file xxx.ini. When deploying this file, I'd love to rename it Install_xxx.ini so TS can install/merge it on the destination computer !

This is just an example of the use case, it could be applied to any file within my deployement image.

View All (4)

My team uses Analyzer Rules to enforce best practices for developers across sequence files and workspaces with great results. However we would love to be able to also provide rule checking and warnings for developers on some basic *.tsd file content such as Installer Name field, and build-path & installation-path/image-path, etc... New (or rusty!) developers often miss steps in their configuration and needlessly struggle with badly behaving deployments.

As TSD files do not appear to have an API available from TestStand at this time nor conform to a json/xml syntax internally, for easy parsing via 3rd party tools, some method(s) for 'reading' file (or converting to readable syntax) may also be required in order to build rules effectively?

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Review all idea Exchange and Update status

Add an "Insert Folder From Disk (Auto-Populating)..." option to projects for Improved Deployment Experience

Quick Preloading Modules when no source for PPL

API that doesn't rely on ActiveX UI Components

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

Simplify exporting arrays of properties

Deployment Utility should use workspace/projects as roots for the deployment locations

Combine Configuration Files during Install

Deployment Utility File version auto-incrementation option

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

Merge Stations Globals on deployment

Unattended automated build for TestStand Deployment Utility

Improved TestStand Deployment Utility CLI

Create Installers in TestStand Deployment Utility from Previously Created Images

Prefix Dependencies for PPLs

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

Simulated Devices in TestStand Workspaces

Add ability to rename a file when building the deployement

Quick switch between the release and debug dll

Ability to write Analyzer Rules around content of TestStand Deployment Files (*.tsd)