NI TestStand Idea Exchange

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

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

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)

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.

The built-in Wait step currently causes TestStand to simply stop at that step until the specified period has elapsed. For steps longer than a few seconds, it would be nice to have some sort of indicator to show how much time is left to wait (and to show that the computer hasn't locked up on those waits that are more than 15 seconds).


It would be really nice to have a check box option to show some sort of wait indicator, even if it was simply using the progress indicator in the lower right corner of the screen (something that simple could even just always be enabled).


On a related note, could the progress bar be made wider so that there is more resolution as to how much progress has been made? If there was a ten minute wait for something, the bar would be moving very slowly and hard to tell progression was being made.

Almost all of our analog measurements are specified in %: example


a Power Supply DMM measurement limit is 24.00Vdc +/- 5%


We typically have 100+ measurements like this in a project



Why not include it in the default step types as an optional selection?

I sure would use it, so would my team.


I agree that it should not alter existing programs using the default step, but I believe that this feature should have been in Teststand when it was first released.


I have run across this in both analog measurements, and the results from an ADC

Think a limit of 0x234 +3%, -7%



When opening a version of TestStand which is not the current version, an error dialog shows. It would be helpful if this dialog included a button to open the version selector and/or a button to open the active version.




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.

Handling arrays in TestStand is pretty limiting and more often that not you have to pop into a code module to perform any sort of array handling.

The following is the default functions that can be used in expressions:

GetArrayBounds(array, lower, upper) Retrieves the upper and lower bounds of an array.
GetNumElements(array) Returns the number of elements in an array.
InsertElements(array, index, numElements) Inserts new elements into a one-dimensional array.
RemoveElements(array, index, numElements) Removes elements from a one-dimensional array.
SetArrayBounds(array, lower, upper) Changes the bounds of an array.
SetNumElements(array, numElements) Sets the number of elements in a one-dimensional array.




I would like to see this expanded to avoided have to resort to using code module.
The following is some suggestion:

Array Subset function
Array Max & Min
Replace Array Subset function
Search 1D Array
Sort 1D Array




Ray Farmer

When loading large sequence files, TestStand does not display progress and appears to "lock up" both TestStand and the LabVIEW OI.  Sequences with hundreds of steps can take minutes to load.  Operators often incorrectly conclude the application has stopped respoding during long pre-loads.


I am suggesting to implement a responsive progress display, allowing the LabVIEW OI to proceed execution, and post the following UI Messages during step pre-load.



  1. UIMsg_ProgressPercent–(Value: 11) TestStand step modules post this message to the user interface to notify it to update its progress indicator associated with an execution.
  2. UIMsg_ProgressText–(Value: 12) TestStand step modules post this message to the user interface to notify it to update its progress message associated with an execution.



I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables.  But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression.  Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar.  It only exists during the evaluation of the expression.



For the moment the runtime error handling can be managed by using ...


  • Runtime error options
  • Ignore runtime error flags
  • Manually, for action steps, by handling actions returns

It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.



    Steps ...

    Steps ...


     case 35  // Error code = 35


     case default // All other error codes




Doing so, could be a way to handle runtime errors, in an other way that the global configured way.




Because of the way .NET applications and assemblies are invoked in TestStand they are a child process of TestStand.  This means that they share TestStand's resources.  For most applications this is not an issue but if the application or library being instrumented by TestStand is resource intensive this creates a significant problem.  In the scenario that served as the impetus for this suggestion we saw performance 1/10 that when running the target application outside of TestStand.


To correct this I recommend the .NET adapter architecture be changed or be able to be configured such that instead of directly instantiating target applications a call to create an object with a .NET adapter would create a separate process that consisted of a TestStand WCF client wrapper process that would host the target .NET process and communicate with the parent TestStand instance via WCF.


Here is a simple block diagram of the intended architecture:






It would be nice to make Sequences public or private within a SequnenceFile.

With this you where able to make powerful SequenceFiles librarys.  The biggest advantage of this

is you can show the consumer of the library only the "important" public sequences. The

private ones where invisible. This will help to avoid errors.






I have a bunch of times that I need to round a numeric variable in TestStand

example: Locals.A = round(Locals.B)


However, it's actually more complicated than that because I need to round it at the Nth position after the decimal point (for example).   This means my expression becomes something like Locals.A = pow(10,-Locals.Digits) * round (Locals.A * pow(10,Locals.Digits) )   (for Locals.Digits == 3, this means that Locals=A becomes 0.123 when Locals.B is 0.1234)

This is a lot more code than I really want to write.  If I am doing the same thing in MS Excel, I just say $B5 = round($B4,$A$1) or something like that.  Notice how the digits of precision to round to is built into the round function.  I'd love if TestStand round function could be expanded the same way

Round(Number, [option], [Digits])

Custom TestStand UI suggestion.


I would like the same functionality as with Sequence Editor when double clicking on Sequence Call step (already configured) and it goes into the Subsequence directly and you can view the SubSequence.


I would like to see that functionality in the TestStand Custom UI when double clicking on the Sequence Call step with Sequence View Manager and it goes into the Subsequence so it can it viewed. 


This would come in handy when debugging a subsequence and setting break points in the subsequence and then viewing variables during execution.

The output messages are a good way of sending status messages from the test solution to the end user.  However the control is not available as one of the controls that can be added to user interfaces.


Can this control be made available to be quickly added to a UI and linked to the execution view manager.

Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms.  If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5).  If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.



When you develop custom step types in LV, you often need to unload all modules in order to modify your LV code (it's faster than going on your step type definition, clic Properties -> substeps -> specify code module -> edit...).

A keyboard shortcut to 'Unload all modules' would be so nice to even speed up the process ! Smiley Tongue

When I get called to look at an issue that has occurred with a test, the account logged into TestStand is typically a restricted user (i.e. Operator). Since the Operator account has very limited options, in order to really do much immediate troubleshooting I need to stop the test and re-run it in the Administrator account. At best this is inconvenient and inefficient if the spot the error occurred is late in the test. However, it is extremely frustrating when it's an intermittent run-time error and I can't do any real-time debug because Operator is logged in. The only real alternative I can think of (when the problem is intermittent) is to leave it logged in as Administrator so I can debug whenever it happens to occur. This is not really an acceptable practice in most cases.


It would be fantastic if there were an override that let's an Administrator provide the proper credentials to perform the desired task that would normally be off-limits to the Operator. The basic premise of this suggestion is similar to the functionality within Windows; if you try to connect to a secured location or perform a task that requires administrator privileges, a dialog box pops up asking you to enter authorized credentials.


I run into many situations where I wish this feature was present. The issue is not always within TestStand (could be a database connection issue, etc.), but it is TestStand that throws the error and in Operator mode the only option is "Run Cleanup". Significant time, effort, frustration, and efficiency could be saved if I could simply enter my credentials as an administrator to perform the tasks I need to do.





On an unrelated side note, I find it humorous that "TestStand" is considered a misspelled word when using the forum spell checker.  🙂



It would be nice to have a tool such "Trace Toll kit" for TestStand, in order to be abble to view the currently loaded modules. 


When you have big Sequences, with many loops, you can get memory problems. Smiley Sad


Then you'll have to play with the load options, the results recording, the on the fly reporting .... Smiley Mad


It should be nice to had a tools which could show us the memory used by every modules, structures, Globals, fileGlobals, parameters, locals ...

So it would be easier to point to the main memory consumers  !!!! Smiley Wink


Or better ... let TestStand access the 64bit world Smiley Happy !

Get rid of the ActivX architecture !Smiley Wink

Memory management should not influence Test creation ... 


Thanks a lot.