NI TestStand Idea Exchange

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

Currently the message popup step is quite primitive.


It would be good to enhance the functionality of this step.


Proposal: pressing the any button definied should be able to trigger the set of TS commands (as in Statement step) definied for any button.


In this case it would be helpful in that way that developers won't be needed to program separate modules to process the flow control flags and user interface popup.

As in subject:


Now if I put the label inside Selrct-Case-End block the sequence won't run:




Sometimes, you have a lot of cases and the labels would be very useful do describe the cases.


I think they shall be excluded from the the rule that "Only Case blocks can be nested in Select blocks".

Using the stock reportgen_xml.seq file, the text value of the XML node shouldn't contain the characters < or >:


When using LabVIEW VI's to parse this, you (rightly) get errors, so it's incredibly difficult to just search and replace the offending characters with their XML escapes. 


Example node contents from the XML report:


<Prop Name='ReportText' Type='String' Flags='0x400000'>
                            <Value><![CDATA[{0} Locals.i = 0; Locals.i < 2; Locals.i += 1]]></Value>

After a recent attempt to create a virgin system by deinstalling all NI software and installing it again I hit an issue that took quite a while to resolve (FYI: Reference#1295936).

Basically, neither the file system nor the registry was properly cleansed during the uninstallation procedure.

Sometimes this behavior is desired - e.g.. if you want to keep user settings - but sometimes not.


Currently the user is neither given the option to decide whether he wants a "clean" uninstall or one which keeps data saved nor he is given information about the extend of the uninstallation.


An selectable option to create a virgin system (at least regarding NI software) either during deinstallation or later during installation (if residual data is detected) could be helpful.

This applies to all software handled by the NI installation routine, I just put it into the TS-section because there I missed it first.



Could we add a feature to allow the example programs that ship with TestStand 2012 to open up in Windows Explorer directly after clicking an separate option from the help menu?  Currently a help article comes up with a list of the example programs.  Upon clicking a link on one of the example programs the path to the example relative to the <TestStand Public> folder is revealed.  I think it would be easier from a usability stand point to add the ability to open the examples folder for review straight from the menu. 


NI TestStand Examples.png


Example Programs.png




Shawn S.

Imagine this as a scenario:

you write some code to work with the standard out-of-the-box process model. 

Then you need to later run this code using a different process model (or changes are made to whatever process model you are using).  With this new process model / changes to your existing process model you happen to have a new callback sequence, and that callback sequence happens to be named exactly the same as some other sequence in your client sequence file (that you wrote with no intention of it being a callback override). 

Now, when you try to run your client sequence file, you will either get errors because the callback parameters do not match up (for this random sequence that wasn't supposed to be a callback override).


Granted this can be avoided by having good naming conventions for sequences in your client sequence file and any process model callbacks you add, but sometimes you are not in control of one or either of those.


I suggest adding a property of a sequence that flags it as "not available to be used as a callback override" -- this way you can configure all your "never intended to be a callback override" client sequence file sequences as such, and you won't end up in this trap. 


Something like this:




I had recentlty to modify the public interface of one of my custom step.

The automatic type conflict detection diden't work ! I had to modify all my sequence file manually, by only launch the "reload prototype" !

(All versions of my custom step has been upgraded in order to generate a conflict !)

So, i thaught, i could use the "sequence file converter tool" to upgrade existing sequence files ...


But no ! 


The sequence file converter only converts the properties which cannot be modified by the final user. (The one who write sequences)

=> The NI Answer is : All properties that could be modified on a step instance, will not be upgraded by the sequence file converter.

So, neither the default action will never be upgraded, nor all properties ....


AIEEEEEEEEEEEEEEEEE ! Smiley Frustrated What can i do for my customer hundred of sequenceFiles .... Smiley Sad


So, I had customized my custom step in order to lock all properties for the end user (Disable properties) ...

I thaught the Sequence file converter will detect that the step instances could not be modified ... and then it will do the right work !

Even with this lock, the sequence converter don't upgrade my existing sequences !


The NI answer to my problem is : You should do it right from the begining !

It is well known that the projects need didn't change during the software life cycle !!!!!!


So i decide to do my own sequence file converter for my application ... and it works fine ... but i think this need is general ... and could be integrated into TestStand.


I would like, in the sequenceFileConverter, to be abble to :


  1. Select a path which contains recursively many sequences
  2. Select a or multiple CustomSteps to upgrade
  3. And launch an automatic "Force upgrade"


The tool could ask other options like ...


  • Keep properties or apply default
  • Updgrade action interface or not
  • keep existing parameters, and initialize default parameters with default values
  • Apply default parameters


I know very well that the behaviour of such a tool would need many parameters in order to handle all needs.

But, this could be done in many times ...


The first need is something like an automatic prototype reload, with existing parameters reusing, and default values for type mismatch, or new parameters.


Thanks for help.





Recently I have had a number of customers ask me if there was a way to create a timed Message box that did not have buttons on it. Of course I told them that there wasn't any. Their requests did get me thinking and I can see that there are times when a timed message popup could be useful. Essentially it would just display a message and go away after a select period of time. I would love to see one. 




Perry S.


It would be nice if there was a station option that would set the default load option for all created sequence files.  Currently I must either programmatically modify the RunState.SequenceFile.ModuleLoadOption property with a statement in each of my .seq files or navigate to Edit » Sequenfe File Properties and change the feature over and over again.


An example of what I'm talking about is shown here:

Programmatically Update Default Sequence File Load Option



It would be really nice if custom types for a sequence file were displayed in the Sequence Editor variables pane (in addition to being displayed in the Types window).


TestStand Types Suggestion.png

The current interface for DLLs does not nicely accommodate C++ classes.  For instance, there is no inherent mechanism for passing in and out of DLL calls the reference to an instance of a class.

The Additional Results Step property is a great way to add customized results to the TestStand report for a particular step without much effort required.  However, there should be an equally simple way to add additional results too all of the steps in a sequence.  The current options are all lacking:


  1. Create a SequenceFilePostStep engine callback to manually append results to the result list - this feels hacky
  2. Add additional results to each step - this is tedious
  3. Create custom step types - this is also tedious, as a new step type would be required for each step

I think there should be an additional results option available in either the report options or in the sequence file properties window or the report options window.  Configuring the results here would be identical to adding the additional result to every step in the sequence.


Potential implementation of button on report options window:



Additional results button launches a dialog:


Professional Development package should include source code control (SCC) and Requirements Gateway right out of the box.


I know that bundled SCC was a problem in the past that NI wants to avoid, but I feel that a "Professional" development system isn't very professional without it and Requirements Gateway. However, It is very difficult and painful for me to get separate funds approved for important items that really needs to be already there right out of the box.


I already use free SVN, but TestStand does not recognize it, so it is not "integrated".






As in subject: add the possibility to define the datatypes described in .net assemblies.


Now developers, when they create veriables, can choose from between number, string, boolean, object reference and cointainers and arrays of these as well as from between DatabaseColumnValue, DatabesePropery Mapping, Error, Path, Expression, NI_LimitMeasurement, NI_MSgBoxFontData, NI_LV_DeployLibraryItem, NI_TDMSReference, IVI and LabVIEWAnalogWaveform, LabVIEWDigitalWaveform, LabVIEWDigitalData, LabVIEWDynamicData, LabVIEWClusterArray,LabVIEWIOControl.


These two groups of data types are called Custom Data Types ( number, string, boolean, object reference)  and Standard Data Types (rest of them).


I'd like to vote the .net types of data which are defined in .net assemblies were accessible from Standard Data Types menu along the LabVIEW datatypes.



I'd like to propose a new feature for consideration. I'm missing the feature using which I could measure how long it takes to execute the freely chosen block of steps. To do this the new step would be needed.


Let say the step type name would be: "Time elapsed".


User would be able to specify the name for every instance of the step used, in the way as we can use the names in Rendezvous instances. And exactly as it is done in the rendezvous step type it would be some operations associated with that step type.


1. First call of "Time elapsed" step type would be called wit the operation: Create. The one obligatory argument would be the name.

2. Every other call of this step type with reference to the same name, apart from the last one, would be optional. The operation name this time would be Lap Time this time. The step would return the amount of time has gone from either the Create operation or the previous Lap Time operation.

3. And the last call of this step type with reference to the same name should be invoke with the operation called Finish for example, and it would return the time has passed from the first call of the step (with operation Create).

User would be able to create a lot of time elapsed type gauges, distinguish by their names.


This functionality would allow to measure the speed of the sequence during execution.


Example (sudo code):


TimeElapsed.Create("test01") //somewhere in the sequence


TimeElapsed.LapTime("test01") //somewhere in the sub-sequence


TimeElapsed.LapTime("test01") //somewhere in the sequence


TimeElapsed.Finish("test01") //somewhere in the sub-sequence


Values returned respectively could be:









I suggest being able to group steps in a sequence:




Steps that are grouped should in interactive mode be forced to be handled together, e.g. "Run selected steps" would always select all the steps in the group. This way you could re-use certain steps multiple times down the sequence without allowing such steps to be executed by themselves (or the opposite, make sure certain steps were never executed without surrounding safeguards).


Today we'd usually enclose such must-work-together steps inside sub-sequences, but that solution does not safeguard against selecting a single step within that sub-sequence for execution by itself, and sometimes putting steps in a sub-sequence is non-optimal (one such case is when you have disabled tracing into subsequences, but this particular set of steps you'd like to have tracing on - I know there are ways to go about this, but these are cumbersome and non-trivial to spot when editing the sequence).


I wouldn't add any extra configuration options to a group, it should simply be a group/ungroup thing - all settings still being on a per step basis.


The use cases for a group could be expanded into making it easier to select a co-working set of steps for copying and pasting, it would be a good way to document co-working steps and so on.




When deploying from a workspace file, TestStand analyses the VIs it has to include in the deployment package. However, when working with plug-in classes, TestStand will add the parent of a plug-in class, but not its children. Possibly because these are not directly used (they are included at runtime), and thus not recognised during analysis.


I would like to see that TestStand recognises a parent class it includes in the deployment, and then:

  • includes all its child classes that are in the same project file;
  • asks to include possible child classes that are not in the project file.
In every TS step we have the looping feature. I find it very elegant feature which allows us to save implementing full loops for singular steps.
I wonder if some statistical information to the looping feature can be added to the looping feature.
We could image that there is a step with the i.e. LV module which is responsible for acquiring one sample of data. Let say the sampled signal is noisy. It would be fantastic if we can use this singular step which acquire singular sample and the looping feature of the TS step to get multiple samples and to have a statistic the samples taken. The statistic could be:
--standard deviation

Allow for Additional Results to be selectively added to the reports of your choosing instead of all-or-none.



1 - Step settings.PNG 





A - Compiled Step Settings.png


B - Compiled Report Select.png

Now, if the number is exactly in between if two integers, TS rounding function uses bankers rounding method as a tie-breaking rule. Although bankers rounding tie-breaking rule generally secures equal statistical error distribution, in case of a need of rounding numbers with only one decimal place this tie-breaking rule produces output which could be different than - let say a natural - expectation. 
For example if we have a group of numbers like below:
{-2.0, -1.5, -1.0, -0.5, +0.0, +0.5, +1.0, +1.5, +2.0}
the basic expectation is to have them rounded like that (round-half-up):
{-2.0, -1.0, -1.0, +0.0, +0.0, +1.0, +1.0, +2.0, +2.0} 
However, using banker-rounding method instead of the rounding as above we see:
{-2.0, -2.0, -1.0, +0.0, +0.0, +0.0, +1.0, +2.0, +2.0}
I think round half up tie-breaking method option should be added for developers to use.
BTW: (the + and - signs and .0 notation are used just to keep the numbers to be easy to compare)