NI TestStand Idea Exchange

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:

1. Managing the Output Messages Pane

   • Programmatically clearing messages.
   • Exporting messages to a file.
   • Opening or hiding the pane.

2. Managing UI Settings

   • Programmatically loading a saved layout.
   • Dynamically controlling the layout during runtime.

3. 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.

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.

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.

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)

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)