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 Authors
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I think it would enhance readability if, in the step settings of a label step, the label description text were no longer bold.

I cringe every time I fill one of these out or read it back to myself.

(Yes, I'm aware of the ability to mouse over the step itself and read the tooltip)


Maybe my use case is unusual, but I'll often write a few sentences in there to describe what a sequence or code block does.




Mr. Jim



Ow, my eyes:



You can run TestStand sequences headless currently from LabVIEW, but it would be nice to have more detailed documentation and examples on how to do it properly since it is not straightforward.  There are some end users that do not need to see the TestStand execution in the operator interface and just want to run a sequence without showing all of the TestStand UI components.



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)

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.




Many SW-Tool providers have realized that how comfortable it is for a programmeruser to work with dark backgrounds. Microsoft did it in 2013 for visual studio and now browser companies are doing the same. Unfortunately, I can Change background color of MAX and TestStand. This makes longer working painful for eyes.


An example of such a bakground is attached with the message.


Such a feature will improve ergonomics.


Thank you



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.



Let's say we have a parameter to a subsequence of a named type, and we want to create a so-named Local or FileGlobal with the same type.

One way to do this with our current workflow is to:

  • Type the same property name in the parameter value
  • Right-click the parameter
  • Click on "Create Locals.whatever"
  • mouse over the types menu
  • Glance through most of the types, select the custom type


I'm proposing a simpler workflow for cases when you just want to duplicate or "clone" the property with the same name and type in Locals or FileGlobals:

  • Right-click the empty parameter value
  • Select "Create Locals.whatever" or "Create FileGlobals.whatever"

The respective menu options would appear if the so-named variable does not already exist.

The subproperty is created in the Locals or FileGlobals with the same type as the parameter.

We have multiple sequences in a file to perform steps that are common to particular subsystems.  It would be nice to have the ability to group sequences within TestStand.  I could envision this to look like a treeview or folder/file structure within the Sequence Pane.  Currently, we have to use a common naming convention to group the sequences together like below:












With grouping, it could look similar to below:





















In addition, there could be a toolbar menu item to switch between showing the grouping or all so you could sort to find



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.


  1. I develop in a folder called: C:\Development\ProjectFolder\. 
  2. I create a workspace, a project, and add the ProjectFolder to the project.
  3. I load the workspace into the Deployment Utility.
  4. In the Installer Options tab I set my Default Installation Base Directory to "Windows Volume (C:)"
  5. 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?

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:

  1. We have LabVIEW cluster { 1My String, 2My Numeric, 3My Boolean },
  2. Then we create TestStand type from it and we have { 1My_String, 2My_Numeric, 3My_Boolean},
  3. Now, we change order in LabVIEW { 3My Boolean, 1My String, 2My Numeric },
  4. TestStand do not see change,
  5. Then we add new item in LabVIEW { 3My Boolean, This is new, 1My String, 2My Numeric },
  6. 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.

I would like to see the possibility to add Tools (Menu > Tools) to Toolbars. See the recording below:



As you can see from Tools section I can select only "Customize". It could be great to have the ability to use custom tools when customizing toolbars and menus.

If you are using a custom environment file for TestStand 2016 and later, it would be great if, on startup, the splash screen indicated the loaded Env file name and path.


As you can see below, in our custom TestStand RTOI we are showing the loaded environment file on the splash screen when it loaded.  The TestStand 2019 splash screen is shown for comparison.

Download All

Static enumeration value in a sequence call must be stated as <Enum(String enumType, [String/Number value])>. Please make it possible to select the enumeration directly.



Problem description:

The parameters out of the step settings window and the called subsequence are not linked. If you delete any parameter out of the middle of the parameter list and the calling sequence use the "default" flag for this parameter(s), this default flag(s) will be shifted to the next parameter in the list and the original value will be overwritten. To reproduce this issue:


  1. Create a test sequence
  2. Create a subsequence and add six parameters (type does not matter)
  3. Insert "Sequence call" in the Mainsequence and configure it to the previous created subsequence
  4. In the "StepSettings" window configure the parameters of the called sequence. Parameter 1+2 with any value. Parameter 3+4 with default checkbox. Parameter 5+6 with any value
  5. Save your work
  6. Open the subsequence and delete the parameter 3+4 (these two that are configured with "default" in the calling sequence")
  7. Go back to the MainSequence and click on the sequence call of the subsequence (reload option is visible in the step settings window)
  8. click on the blinking red reload button

You can see that the name of parameters you have deleted in the subsequence disappear, but the "default" flag(s) are shifted to the parameters 5+6 and the previous configured values were overwritten. If you delete any parameter that is configured without the default flag the deletion works fine. 


Problem: If you want to delete a parameter that is used in many subsequences by searching for it and delete it directly out of searchResult window, you cannot guarantee that your sequence is running without any problems


Idea: Add a "checkup function" on the "reload" module in the stepSettings menu that all parameters are checked by name and value before any values will be overwritten. This checkup has to be done on each change of the called subsequence

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?

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

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.

The property loader step allows the source location to be defined via an expression.  However, if that expression does not evaluate to a file on disk at compile time you get an error.  This isn't always desired behavior, for instance, when used in a plugin architecture.




The current workaround is to include a dummy file which could unnecessarily complicate the software & deployments.  A dummy file also has the potential to mask errors that should be presented to the user. 


The only validation TestStand does of the property loader source location file is that it exists.  It doesn't do any validation on the file contents.  So is there any benefit?  TestStand properly throws an error if the expression doesn't evaluate to a valid file.


Alternatively, a developer could deselect the sequence analyzer rule "Property Loader source should be proper", but this would disable it for all analysis not just the ones that use expressions

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.

TestStand is in dire need of a way to quickly and effectively find broken steps in long sequences.


I'm working on large sequence files which often call and utilize other long sequences. Needless to say, I often need to address steps which have become broken due to code rework. As of now (TS 2017), there are only two ways for me to know if a step will not run.

  1. Text is red within the Step Settings window.
  2. Sequence Analyzer reports an Error.

I would like to suggest a third option, one that would be more readily available than either of the other two options. If the step itself was highlighted, text reddened, or somehow otherwise flagged as an error, then the operator won't have to hunt through each of the step settings windows or the sequence analyzer results. All the operator would have to do is open the sequence file and notice that a step appears out of place.


It would be nice if sequences could also show if they have broken steps.


Included is an example of how this might look.



Download All