NI TestStand Idea Exchange

Post an idea

Add "Close All" files option

If you have opened a bunch of sequence files (TS2025 sequence editor), closing all of them is frustrating.

you can click on the "x" for each sequence file. With the new placement of the "x" on the tab rather than docked far right in the UI you need to move your mouse for every file that you close.

you can file >> close myfilename.seq for each file (this takes a long time)

you can ctrl+w a whole bunch of times (great if you remember all your hotkeys)

you can right click on a sequence file and choose "close all but this one" and then close "this one" (cool trick, but you need to remember it)

you can go to Window >> close all windows. (this is great, but not a place that makes sense based on other software UIs)

I propose adding File >> Close All menu entry. This would essentially do what Window >> close all windows selection does, except that it is in the location that people will look for it based on experience with other software packages. This way TS behaves more like what we expect from other software packages. My experience makes me look for "close all" in the file >> menu somewhere next to the file >> close this file entry.

This is a carryover from an earlier idea that got halfway implemented (when the close "x" got moved to the tab).

Right now in TS2025 out of the box sequence editor, if you have a file name that is really long, it just gets truncated in the tab. This makes sense if you have lots of tabs open and are going to be competing for space, but if there are only one or only a few files open, there is lots of extra space that could be used to clarify the file name.

Request is: if you have extra space in the UI for tab sizes to get bigger, make the tabs large enough to display the full file name without truncation.

Recently I was trying to configure the Python Adapter programmatically as part of a package (.nipkg) install to configure TestStand for my operators. I am trying to get programmatic access to the Python Adapter configuration in TestStand to Read and write these values. I am most of the way there, I am just struggling with the "Python Module Viewer" section, getting the Application Path and the Arguments.

Configure >> Adapters >> Python

Python Module Viewer

In TestStand statement step I am doing

RunState.Engine.GetAdapterByKeyName("Python Adapter").asPythonAdapter

And this gives me access to everything else.

Linked to Service Request: 03715194

View All (5)

With the removal of the GAC from TestStand, it's now the user's responsibility to include common .NET assemblies in their source to be leveraged in TestStand. It would be great if I could go the menu, launch the Nuget Package Manager, download packages from nuget.org (and my local Artifactory repo), and unpack these assemblies into a specified target folder.

While I'm primarily focused on .NET and nuget, the same thing could and should be provided for VI Package Manager and lvlibs, lls, vis, etc.

View All (4)

Currently, you have to choose between these options on each file (and the only indication of the choice is in the sequence file properties dialog). Both options can be quite useful in the Parallel and Batch Model (of course there isn't much of a difference in the Sequential Model). Clunky workarounds also exist like using Shared File Globals and having arrays for anything per-execution or using Separate File Globals while putting anything shared in Station Globals or in LabVIEW Functional Globals, but I think native support for both in the same file would be much cleaner and easier.

This could be just having two "FileGlobals" categories in the Variables pane (I prefer this), or it could be a right-click option on each individual File Global.

View All (2)

Sequence Editor Public API

I would like to suggest adding a public API to the Sequence Editor in TestStand.

Recently, I watched a recording featuring members of the TestStand R&D team, where they explained that users often request various features in the Sequence Editor, even though they already have access to the TS API and TS UI Controls, which allow them to create their own custom user interfaces. Meanwhile, building a custom operating system just to play Heroes of Might and Magic is not standard practice — we buy a fully functional system and run the game on it. Similarly, when writing sequences in TestStand, we purchase a framework along with a ready-made GUI that should provide a comprehensive set of features for creating test sequences. The Sequence Editor is a paid tool, and since users pay for it, it should offer value out-of-the-box without requiring additional development of functionalities that users believe should already be standard.

For this reason, I believe that a paid GUI like the Sequence Editor should be enhanced with an API that allows programmatic control of its functionality.

Examples of functionalities that interest me:

Managing the Output Messages Pane
- Programmatically clearing messages.
- Exporting messages to a file.
- Opening or hiding the pane.
Managing UI Settings
- Programmatically loading a saved layout.
- Dynamically controlling the layout during runtime.
Changing Pane Colors
- Many users currently complain about the lack of a dark mode in TestStand. A partial dark mode can be achieved by changing the background colors of panes. Most (if not all) panes have a Color property that allows color changes, but for some reason, this doesn’t work in the Sequence Editor (I attempted to achieve this by retrieving references to panes through the Application Manager returned by Engine Internal Options, but unfortunately, without success).

These are just examples of features that would be useful to me today. However, long-time TestStand users could likely identify many more ideas for such API. A public API would open the door to much more advanced and personalized use of TestStand, while simultaneously increasing its value for a wide range of users.

View All (1)

Since TestStand 2019, it's possible to configure an action step with a LabVIEW Module to switch between using a source VI and using the same one but compiled into a LabVIEW Packed Project Library (PPL).

The option, accessible in two ways, is called "Always run VI in Packed Project Library".

That's a neat possibility since it's allow to switch between a development version with easy debugging of a classical VI, and an optimized and locked production version with PPL.
One non compiled VI
One compiled VI into a PPL
One LabVIEW project
One TestStand step

However, when LabVIEW Adapter is set to Run-Time, a tight coupling between the compiled VI and the non-compiled VI is maintained for no reason.

Example 1)
-A VI is developed and compiled on a development machine A
-It is called as the module of an action step
-The VI, the PPL, the .lvproj and the .seq are pasted on a production machine B with fresh installations of LabVIEW and TestStand
-LabVIEW Adapter set to Run-Time on machine B
-Always run VI in Packed Project Library set on machine B
--> The execution will not start, since the classical error -17600 appears on the call. The reason is because the LabVIEW cache of the machine B does not contains data from the .lvproj. Simply opening then closing the .lvproj updates the LV cache, which solves the issue. However, it makes no sense to depend of the LabVIEW development environment on this production machine since the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled.

Example 2)
-LabVIEW Adapter set to Run-Time
-Always run VI in Packed Project Library
--> If source VI is deleted, it takes a long time to preload the modules. See here

Proposition :
When the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled, it should be possible :
- To not install the LabVIEW development environment (only the LV Run-Time)
- To keep only the PPL (and eventually the .lvproj) and to delete the source VI (no source code on production machine)

The settings field can easily become too long to see every active option and there's not necesarily any consistency between steps if they have differing options. What I mean by that is if you only set the "Do Not Record Result" (my favorite) option in one step, it will be on the left of the settings field. But if you now set several options on another step, the settings are not lined up so that it becomes hard to see at a quick glance which steps I forgot to not record (because TS still doesn't default to not recording steps). You have to analyze the settings line for each step.

I propose something more graphical and ordered. Here's my idea of at least ordered. The text could be replaced with icons representing each setting.

Then it would be graphical, ordered, and concise. What more can you ask for?

View All (9)

As someone whom regularly maintains custom process models for my team, there are times when I wish to harvest data from 'any MainSequence run' without requiring my individual developers to remember to set specific custom-parameters or 'runstate.root.* or Locals.ResultList[] values within their test programs correctly every time.

It would be great if there were hooks, beyond simple parameter passing, that could allow me to dynamically 'reach in' to active execution context of MainSequence ideally 1x at start and end of MainSequence execution (i.e. just after context fabrication, and just before context garbage collection).

In this way, I could use API to monitor data that usually gets garbage collected before the model can 'see' it.

i.e. if I see they have a local variable in their test, Locals.Debugging_Active == true, perhaps I could catch that at the framework level, and update the report header to say 'possibly not production data!', even if developer forgot to correctly set the 'is Validation Data' flag that is formally available.

In an ideal world we would have strict process & TS style rules to enforce that all developers must set key variables as part of their executions, but also having a scrappy way to catch test-internal context issues within process model (even if this does break the paradigm of immediately garbage collecting sequence specific internal data) would be a great fall-back strategy for teams where they have 1 or 2 test experts and a much larger pool of non-expert test developers using TestStand.

View All (2)

When building any type of distribution it would be nice to have the following actions

1) Pre-Image Build Script -> Execute windows command or batch file

2) Post-Image Build -> Execute windows command or batch file

3) Post-Distribution Build -> Execute windows command or batch file

The purpose of the three entry points is to allow the user to preform actions of their choosing.

Action #1 is to be run just prior to Starting Analysis to allow the user to preform any automated actions prior to analyzing the build project.

Action #2 is to be run after the deployment image structure and all files are created on disk but before the distribution package is create. The purpose of this action is to allow the user to inject any files, update files, preform verification or hashing and so on. In my specific use case, I need to create a file that has relative paths and a hash value for each file being deployed. This process is automated but currently run manually prior to a package build.

Action #3 is to be run after the Distribution package is made. Automate any file steps such as uploading the file to a network location, or generating an automated email.

Each action should call the script with parameters such as path info, deployment name or provide a list of variables that users can choose to have added to the command line for each action.

If the action script or command returns a non-zero value the Build process should terminate.

Re-Posted from (https://forums.ni.com/t5/NI-TestStand/TestStand-Deployment-Utility-Scripts/td-p/4373139)

View All (1)

When creating custom step types, it is highly recommended to use Post-Step for calling execution module instead of Default Module.

Thus, when instanciating a custom step type, parameters passing is not saved within the sequence but only in the step type definition.

This allows to change parameters passing without having to update all the step types instances.

In some big test benches, it is intersesting to have low-level step types and high step types based on low level step types.

High level step types execution modules are sequences using low level step types.

Since sequence adapter is not available for Post-Step, we are obliged to call the sequence through Default Module.

Thus it can generate problems when adding parameters in sequence call.

I suggess to allow Sequence Call in SubStep creation :

Jean-Louis Schricke, MESULOG

TestStand Architect

Hi folks,

When writing TestStand UI components using LabVIEW, there are a lot of scenarios where using a callback VI to handle a TestStand event is the right move. As of writing this, that's the only way.

There have also been plenty of times when I would have preferred to handle a TestStand event directly within a LabVIEW event structure. In these kinds of scenarios my code would be less complicated if we had the ability to directly register TestStand engine events with LabVIEW's "Register for Events" node.

Years ago when learning TestStand, I tried to do this out of intuition and I was kind of surprised that it wasn't supported.

Below is an illustration of what I'm proposing.

View All (4)

Support Unicode

Right now, you really can't reliably use anything other than a basic ASCII character set in TestStand, which means that some SI units (such as ohms) cannot be represented in their preferred way (with an omega). It also means that you can't put non-english characters in your sequence file and reliably have them show up if your sequence file is opened on a different computer with a different language localization (which causes a huge problem if your customer demands support for non-English languages, and has more than one site -- that speaks a different language -- around the world).

Make TestStand support Unicode, so we can use the full greek character set for things like units, and so we can type characters from any language in our sequence files, and not have them change to a different character if we open them on a computer with a different localization.

TestStand UserManagement Update

Provide a UserManagementCallbacks.seq to replace the currently hard-coded built in TestStand User management so that we can implement our own site-specific user management.

Sequences should allow for

1) Retrieving and returning of a user container from a database or file of our choosing (login)

2) Storage of new user credentials to a database or file of our choosing

3) Adding a New User with the option to reject (i.e. we don't like the name "!#%ThisGuysName!!!")

3) Deleting a User with option to reject deletion (i.e. we don't want to allow deleting user "Administrator" or "ThisReallyImportantUser"

4) Updating User Information

5) Logout, return a default user or shutdown on logout.

6) Retrieving of All Users available for login.

7) Check if a UserExists

This would be in addition to the FrontEndCallbacks that handle the Login/LogOut process.

View All (1)

Looking at any step result, there's a TS.StartTime property, but it's referenced against the "the number of seconds since the application initialized the TestStand Engine"

What this means is that each step result is referenced against a somewhat arbitrary and changing epoch that isn't recognizable outside any one instance of the TestStand application, let alone by external applications.

I'd like to propose adding TS.StartTimeUnix, which contains the absolute time the step started.

I've added this in our model customization plugins, but to convert the epoch to UNIX I have to perform this calculation:

Seconds(False)-Seconds(True) + Parameters.Result->TS.StartTime

Why I'm asking for this:

In our step result database table, we've added a column for STEP_START_DATE_TIME which is absolute UTC time. To populate this I have to go through the gymnastics above. I revisited this code today and thought, "What silliness. This should be something natively supported." (Other than that I have no strong opinion on the matter)

View All (7)

Create a TestStand context help pane

When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help. While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help. I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.

This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users). Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.

Hi,
I would like to show the following problem with the Update Custom Data Type from Cluster tool when updating TestStand container type definition based on LabVIEW cluster.

TestStand creates new container type definition according to the LabVIEW cluster items order. The problem apears after you create the TestStand type definition and then reaorder LabVIEW cluster. After this change in LabVIEW, TestStand will not properlly reorder items in its definition. So for example:

We have LabVIEW cluster { 1My String, 2My Numeric, 3My Boolean },
Then we create TestStand type from it and we have { 1My_String, 2My_Numeric, 3My_Boolean},
Now, we change order in LabVIEW { 3My Boolean, 1My String, 2My Numeric },
TestStand do not see change,
Then we add new item in LabVIEW { 3My Boolean, This is new, 1My String, 2My Numeric },
Update in TestStand will be { This_is_new, 1My_String, 2My_Numeric, 3My_Boolean}.

So at the end we have:

in LabVIEW : { 3My Boolean, This is new, 1My String, 2My Numeric },
in TestStand : { This_is_new, 1My_String, 2My_Numeric, 3My_Boolean}.

IMO items order can be sometimes (if not always) important part of good style. That's why I would like to suggest to update also items order if you select Force Exact Match.

View All (2)

NI TestStand Idea Exchange

Add "Close All" files option

Make FileName Tabs Larger in Sequence Editor

Provide programmatic access to "Python Module Viewer"

Integrate Package Managers into Sequence Editor

Native support for maps or dictionaries in TestStand

Have Both Separate File Globals Per Execution and Shared File Globals in the Same File

Sequence Editor Public API

Examples of functionalities that interest me:

Improvement of LabVIEW Packed Libraries TestStand options

Visual settings in the steps pane instead of a (sometimes) mile-long text list

Allow ProcessModel to obtain/retain MainSequence context before & after Call MainSequence step

TestStand Deployment Utility Scripts

Sequence adapter available for substeps

Support TestStand Engine Events Using LabVIEW Dynamic Event Registration

Support Unicode

TestStand UserManagement Update

For each StepResult, add StartTime with UNIX time offset

Create a TestStand context help pane

Update Custom Data Type from Cluster Force Exact Match - update items order

Select enumeration value directly in SequenceCall

Support for multiline comments in Sequence steps