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

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.

  • Adapters

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

  • Adapters

Currently there is only the "Create type from struct" button available, when there is an parameter, that requires an array of structs, in a .NET call



What would be nice, is to have the features available, that are available when passing clusters to labview:



That is: 

  • The Add Array Item button
  • The Delete/Delete All Item buttons
  • The feature of 'uncollapsing' a struct and setting the values for each field in the struct.


  • Adapters


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:




This idea mostly goes along with this idea.  I use type def all the time in LabVIEW, especially with enums.  TestStand can interact with my VIs with enums, but they are handled as a number.  Furthermore, if the enum gets changed, the wrong value of the enum is often used.  I really like the idea of custom data type of an enum.  The ultimate would be if I only had to alter the enum once (in ctl file) and TestStand would automatically update its data type.  This should be the same for clusters.

Please make possible to select LV Development System version in similar way as it is possible to select Run-Time Engine.

It also should be available in TS API.


That will allow Test Engineers to use code modules (especially those inside .lvlibps) from different versions.

It would be also useful for to set up desired version of LV for code modules without lack of debugging options of Run-Time Engine calls.


TestStand now works incredibly well with LabVIEW Classes, but there is a slight annoyance with the fact that you cannot call a Dynamic Dispatch VI with an empty Object Reference. The implication of this is that when you want to use a .lvclass, for every class instance you have to call a VI that does nothing more than return a wrapped class constant which then populates an Object Reference. Technically this is not a problem, but it means that your Sequence becomes very quickly littered with these VI's and it would be nice if there was a way within the LabVIEW module adapter settings for a class member call if when you first call a Dynamic Dispatch VI that, as within LabVIEW you can just pass in a class constant rather than a previously populated Object Reference.


The Problem - All the LabVIEW calls prefixed with 'NEW' are simply returning a class constant.




A Potentially more integrated way of doing this


The Dynamic Dispatch input has the option of either passing in an Object Reference, or a class constant.


Adapter Settings Modified.png



All compatiable classes are listed in the value box now - either as .ctls, or alternatively as .lvclasses. This could also possibly be more akin to what happens in labVIEW when you call a Class which has available overrides that it gives you a tree view of the class hierachy to choose from.


Another way you could do this is to have a checkbox adjacent to the 'Class Path:' or 'Member Name:' named 'First Call' or 'New' or 'Construct' that then changes the 'Derived Class


Adapter Settings Modified2.png



It would be nice to integrate VeriStand into TestStand with a VeriStand Adapter.


veristand adapter.png












This would make developing with TestStand and VeriStand much easier. The adapter would provide a lot of the VeriStand .Net api natively to testand:


- Deploy a system

- Set/Get Channel(s)

- Stimulus Profiles

- etc.


The adapter would be especially nice for integrating the new Stimulus Profiles in VeriStand 2011. It would allow for you to create the Stimulus Profile sequence and the Real-Time sequence. The Real-Time sequences would only be able to use a subset of TestStand steps, and would have to be different than a normal TestStand sequence because they are executed by the VeriStand engine, but the Stimulus Profile sequence could be a normal TestStand sequence.


The integration of the Stimulus Profiles would leverage a lot of features TestStand already has like source control, requirements, reporting, etc. Also, it would just give the user a much more intuitive experience when using the two together. Their test development would be centralized in TestStand instead of having to switch between the two different editors. It would also give better access to the parameters being passed into the Real-Time sequences at the TestStand level.


There are probably more benefits that could be realized by integrating TestStand and VeriStand, and this is a feature I would love to see as a user of both TestStand and VeriStand.

  • Adapters

To change the adapter settings every time instead of traversing from configure tools menu it would be extremely convienent to launch the adapter  configuration dialog box by just  double clicking on its icon available in the insertion palette.


Present implementation :

Left single click on icon sets it as the active adapter. (Requires 4 clicks)

New request :

Double click this to launch the adapter configuration dialog box.(Requires one double click)



  • Adapters



In current TestStand version (2012), it is possible to view the list of enum values of dotNet adapters parameters.


This is great ....


But it should be nice to add the enum corresponding numeric value in the dropdown list.


This could be helpfull if you had to create a numeric TestStand variable to map to the enum parameter ... and because there are no correspinding enums in TesStand !


Thank for help.


enum 1.png => Better enum 2.png




  • Adapters

See discussion here:


Say I have a LabVIEW Class, and that class contains a method that's a polymorphic VI, and that polymorphic has instances. If I set the instances' access scope to private, and the polymorphic to public, then I can force developers that use the class to use the polymorphic VI (and not call the instances directly). That's awesome. I like that.




Say I'm building a TestStand API that uses a polymorphic and its instances as described above. I create a LabVIEW action step, with a Class Member Call call type, and I target my class. TestStand doesn't support polymorphic VIs, which means neither the polymorphic nor its instances show up in the Member Name list.


This means that, to support my LabVIEW users and my TestStand users, I need to create two separate APIs. The idea is to modify TestStand to allow for Polymorphic VI spacing between the LabVIEW action step type and the polymorphic member VIs.

  • Adapters

The NI-VISA Adapter could present steps that would related to the VISA Interactive Control application (Write, Read, Write from File, Read to File, Assert Trigger, Read STB and Clear). This would allow a developer to create a sequence that checks/calibrates a test station consisting of source, sense and fixture loop-back elements with out dependence on a particular adapter or version of an adapter.


I admit that the IVI adapter is already available, but not everyone uses ( or likes Smiley Tongue ) IVI technology.




  • Adapters



When you use LabVIEW action steps, using enum as parameters, the enum update will generate your step to require a reload.


This behaviour is OK when current enum values are updated .... and the steps use the modified values !

But when adding a new enum value to the enum, the reload should not be automatic.


=> This behaviour doesn't happend with rings ... 


Please make the enums works like rings for the LabVIEW actions steps reload !


Thanks a lot.



  • Adapters

When setting arrays, even multi-dimensional arrays, it is possible to initialize them in single assignment expression. For example, "Locals.Array = {1, 2, 3}" will re-define Locals.Array as a 1D array with elements "1", "2", and "3". This is essentially the same as C-style initialization syntax, which also supports structs.


It would be helpful if containers could be assigned in a similar manner. For example, the illustrated container:




could be assigned completely using "Locals.Container = {True, 1, "foo"}".


Currently, that syntax generates a run-time error, "Expected Container, found Array of Containers".


The only scenario I could think of where assignment gets a little weird is with Object types, but in that case you'll have to be assigning Nothing, the return of a function call, or an existing object from another property - there's no way to define a literal value to assign there, but that's already the inherent nature of Object types.


My use case is often container initialization. There are several kludges around this - keeping an empty copy of the container and assigning it to the working copy to clear the working copy, individually listing out each parameter, and a few others. Another case is when it's useful to assign a constant to module parameter - it's debatable that may be bad form, but would still dramatically improves the ease of skimming parameters if it were implemented. It would be a slight bonus to Sequence adapter in particular, which cannot expand containers in the parameter list, as other adapter types can (go kudos Allow Sequence Adapter to expand containers in the module tab to fix that!).

The menu to create a new variable (right click on variable in an expression edit control and select Create "VariableName") contains all the data types you can use for the variable, however, in the LabVIEW Panel (and other similar panels or dialogs) there is enough context information about the variable to suggest a data type, for example, if the variable is in a control of type Double we know we should create a Numeric variable. TestStand should add the contextual suggestions to the top of the context menu and bold them so that I can more quickly select the data type I want most of the times, then have a separator and put the normal menu so if I don't want that data type for some reason I can still choose the other data types (see attached image).

I am a new user of TestStand for about 6 months or so. Please pardon me if this post is duplicate ... I did a basic search to make sure it wasn't.


Test Stand is able to load a cluster from LabVIEW and show its elements, very cool.

It might be awesome if a Container in TestStand can be loaded into LabVIEW that'd do the same.

When LV throws an error, it's all very easy to catch via callback and/or is auto propigated through the system to Runstate.SequenceError it can be detected.


When LV throws a warning... the data doesn't seem to go much of anywhere in TS... and unlike LV it doesn't propigate from step to step either.


I'd like to catch and log these warnings in my error handlers (naturally with different logic, but I don't want to lose the data either, it's important sometimes!)


from poking around, it looks like my options are:

(1) creating a custom steptype wrapper around all LabVIEW step calls,

(2) editing each VI called by TS manually

(3) some fun expression(s) in the 'add additional result' or 'post expressions' sectionsof each LV step, to create new variables in TS on the fly...  (or using a post-step callback to do the same)


It would be nice if the LV adapter / LV steptypes had some native way of catching this 'almost error' behavior and getting it into the report at least. I don't know if leaning on the error callback is the right answer, since, afterall, these aren't errors... but having a warning callback feels too LV specific...


How about a checkbox in the LV adapter, where you could specify 'treat warnings like errors' and then in the Error callback you could check to see if the bool was false, and punt as desired?


Is there something I'm not seeing that would be a better solution?


--Elaine R.


LabVIEW recognizes any cluster of <Bool, I32, String> as an error cluster.  TestStand should recognize this as well and default any such cluster output to Step.Result.Error.


With the addition of the Silver controls in LabVIEW 2012 "error out" was changed to follow the style guide recommended naming convention of leading caps and is now labled "Error Out"  which is not intercepted and assigned to step.result.error.

It would be nice to see a Help Button on the .NET Adapter that allows developers to see the help for methods they're choosing similar to the help for the ActiveX Adatper.


ActiveX Adapter with help.JPG


NET Adapter without help.JPG

  • Adapters

Currently the Selected Adapterdrop-down list box in tool bar shows only the adapter name example- LabVIEW. If user wants to know if the current setting is using LabVIEW Run-Time Engine or LabVIEW Development System or even the active LabVIEW version, he has to launch the configuration dialog box.


The combobox should also indicate if it is set to use LabVIEW Run-Time Engine or LabVIEW Development System along with the version. Refer image for details.


  • Adapters