NI TestStand Idea Exchange

Community Browser
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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 (


I think it can a be a really good idea to review and give feedback on all Idea exchange.


You ask us to give feedback but you don't finish the loop.


Some idea are mark as new for many years now...

Obviously it's not a great idea to have loads of nested conditional steps, but for longer sequences even with only a few nested conditions, I find it hard to find the matching END for example when an if-statement. Sure I can count the number of lines, but I think it would be a lot easier if the "scope line" that indicates the scope would stand out more and become bold or blue (like the selected line)


Here's are two mockups (bold line)




An alternative indication could be to highlight the ending line of the scope like below.




Having a keyboard shortcut for jumping between beginning and the ending within a scope would also be very helpful!

In Microsoft Visual Studio there's a keyboard shortcut (CTRL + [ ) which toggles the cursor position between the and and beginning of a scope, and it works with all things that encapsulates a scope or a string or expression. e.g. curly braces in code sections, quoted strings etc.

Currently, if you have LabVIEW code modules that use maps or sets you have to use something like an Action Engine to interact with the map, you cannot pass a map from LabVIEW into TestStand and vice-versa.


Maps are an incredibly useful data structure and having support for them natively in TestStand would be very helpful, not just for LabVIEW but also due to how prevalent maps (dictionaries) are used in Python as well.




Modifying names in interface are never good idea, but some times it is must.

No matter is the change made in LabVIEW Front Panel or in TestStand type cluster mapping. Or the cluster type is changed for some other reason. The changes needs to be applied in LabVIEW module call parameters.

When you have multiple sequence files and multiple calls to same VI or with same cluster type in each of them, you would not really want to go trough the steps one by one.



- Cluster mapping changes apllied with LabVIEW Protorype reload

- Cluster mapping changes applied to hole sequence file or/and to all same VI calls in the sequence file

- Need of cluster mapping change applying notified with Analyzer

TestStand File Diff and Merge Utility has the ability to produce reports in XML format with a slew of dependencies on TestStand (stylesheets, button images, etc.) making them not very portable.  Yes, I know they can be packaged with the extra utility, but that's a hassle too.  Now instead of managing a file I have to manage a folder of files.


Additionally, these reports only seem to work with Internet Explorer which I'm hearing is going away. Not sure if it's just me, but Edge's IE mode doesn't seem to work for these reports either.


Can NI do something to address this?

  • Make a browser extension that works with at least chromium based browsers.
  • Figure out a nice PDF format.


Ideally, I want to upload the file type into my code review platform of choice (git, perforce swarm, crucible, network folder share, etc.) and not require my reviewer to have TestStand installed on their machine.

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)

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.




In the TestStand report generator it's possible to show/plot graphs within the report.
Unfortunatelly it's not possible to add axis labels to the graphs.
In my opinion this is a must because a graph without knowing the units of x, y axis is a useless graph.
It would be awesome if this feature could be implemented.

Many thanks
Best regards


when manipulating data between different system, JSON string are very usefull to have a standardize, simple and readable exchange format.


Python or LabVIEW can dump structure (dictionnaires or Cluster) to JSON and vice versa.

It can be very usefull to allow to dump a TestStand variable or container to JSON and vice versa.


It can be good to have also a way to have native function in string functions to read, write or add a specific value in a JSON string.



Git would be a valuable addition to be made to the source code control providers that you have already since it is widely used.

I think it would be a great idea to allow the sequence adapter to expand containers like the CVI and LabVIEW adapters do when you are editing the module for the step. 



See attachment.

When user opens the Offline Processing Utility and at the same time starts to type on the keyboard the user can accidently rename the profile.

(Attached a screen-recording to visualize)

It would be great if there was no selected row or column when starting/opening ORPU. The renaming of the profile disturbs the production since the database logging will not work as expected.


When we start ORPU we already have the '/tray' enabled but somehow its still possible to accidently rename the Profile.

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.


In instances of nested expressions, it would be useful to be able to press tab to indent a line. I propose inserting "n" spaces when pressing tab.


Coding style of course varies, but for readability, I rather dislike the following


Trim(Locals.SomeLocal) == "" ? (Locals.SomeLocal = "foo",Locals.AnotherLocal = "bar", Locals.SomethingOrRather = "zoo") : False

 ...and much prefer this styling:


Trim(Locals.SomeLocal) == "" ? (
                Locals.SomeLocal = "foo",
                Locals.AnotherLocal = "bar",
                Locals.SomethingOrRather = "zoo" ) : False

...but at present the latter is tedious because one has to insert a lot of whitespace manually or worse yet, use another text editor and paste it into TestStand. It would be nice if TestStand's expression editor supported this basic feature available in almost every text editor or IDE.




Mr. Jim




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.

Current settings.PNG


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.

Ordered settings.PNG


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

TestStand File Diff and Merge Utility is not very useful for code reviews on its own.  It seems adequate for notifying the user that a sequence was added, however from the tool itself the user cannot actually review the newly added or removed sequence's contents.  Why is there no + on the item tree to go deeper.



If I have to right-click a sequence and select "Go to location" then why bother with the separate tool to begin with?  Why isn't the diff utility integrated into TestStand's sequence editor itself?  Seems like a side-by-side comparison within Sequence Editor would allow a reviewer to poke and prod around all the hidden settings that are often missed using the existing utility.


Microsoft have stated that all future development in .NET will be based on .NET Core, a cross platform development framework.  Therefore the current version of the .NET framework (version 4.8) is the last built on existing .NET technologies, with the next version .NET 5.0 to be built on .NET Core technologies. 


Could an adapter that supports calling .NET Core modules be added into TestStand so that users of TestStand calling .NET modules can migrate to .NET Core?

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



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)