NI TestStand Idea Exchange

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

The Database Options dialog in TestStand 2013 and 2016SP1 (the versions I have tried) have the key focus set to the 'OK' button. Pressing the 'Enter' key at any point while navigating that dialog will close it and not save the changes.


This becomes very frustrating when editing the 'Command Text' of a database statement as you might want to insert line breaks to make editing/reading the statement easier.


I have had this happen at least 10 times already today and is very frustrating and is only a very minor change to the Database Options dialog.


Hopefully we could get it as a patch?

In TestStand you can create a comment in a variable, but that comment will be deleted even if the data type of the variable is changed. This does not make too much sense because it happens that the customer needs to change  the data type, and then he has to re-write the comment completely. This feedback comes straight from multiple customers and it makes sense that it should be so.


Thank you everybody. Best,



For our test we use 48 TestSockets in a Batch process model.

Every TestSocket will gather data for every millisecond while the test of maximal 3 minutes is preformed. A few times per second we like to call a LabVIEW VI and preform some tests on the last few seconds of this data. To give the CPU some time to do other things a 100msec wait time is in between all the tests. While LabVIEW only needs the last few seconds of the array to preform the test, TestStand will take a subset of the array and give this to LabVIEW. But this subset it already taken more than 1.5 seconds in TestStand.


Attached is a small Benchmark test that shows (and hopefully explain) this behaviour.

We just make an local array of 180000 data points. (3 minutes with 1msec sample rate)

A for loop of 100 times is done to average the results.

In the loop two VI's are called.

  • One with 100msec wait.
  • The second to receive the array. In LabVIEW the array isn't touched.


If we just start with an array from 10000 data points. (the first 10 seconds)

This will take 107.5 msec and about 12.5% of my CPU resources.

Seems good, but the data grows to about 3 minutes, lets test 180000 data points.

This will take 138.5 msec and about 40% of my CPU resources.

We already use 40% of my CPU without doing anything more than give LabVIEW the data.


As we don't need the complete data array, it seems not smart to copy everything to LabVIEW. TestStand is capable to take a subset from the numeric array and send this part to LabVIEW.

So if we want to analyse the last 5 seconds, we give the data to LabVIEW like this:

Locals.Array[175000 .. ]

This is only half of the data as the first test, so expected it will be about same in execution speed.

The average execution is now 1.6 seconds, so 1.5 seconds is used for the array subset.

Also the CPU is fully taken by this process. This way our application can't work.


As a workaround I send in the complete array into LabVIEW and take a subset in there. This is at the moment faster than take a subset in TestStand, but I would expect that this process can be faster done inside TestStand.


I would like to post the idea of an optimized array subset function.

This will optimize the performance of TestStand greatly while working with larger array's.

Especially if you have more TestSockets than CPU cores, like me.

Currently you must set the path to the folder that teststand will load its inital configuration through the options.  This means that it is not possible to change this via the cmd line wehn launching sequences.  Tehre are several work around for this (none of which are very good).


The 'best' solution to this issue would be to add "/configPath "c:/projects/tests1/" " as an option on the cmd line and allow teststand to use this instead of the path hardcoded int he registry.

The TestStand Deployment Utility lets you select the following locations for the installation destinations of individual files:


File Installation Destination.png


However, you can select the following for the default installation base directory:


Default Installation Base Directory.png


It would be really nice if both lists of available installation locations were the same, both in terms of locations and naming conventions.  The most glaring omission in the file installation destination list is the Windows Volume location.

The Start Modal Dialog VI currently needs to be placed on the block diagram of the VI that needs to be modal.  This means that you can't put it in a subVI with logic around it.  If a VI reference input were added to the VI (with the default being the calling VI) then you could keep the same functionality but have the option of calling this from a subVI.  


For those that are running into this, there used to be a workaround here:

But the link in this forum is now broken.  I'll post back if I find the answer.  

If there's a way to do this already feel free to ignore this suggestion 🙂


I have a process that spawns N parallel measurements for a given DUT at one point during code, and then has a series of wait steps later, to collect all the results / errors / etc.


I have a reaonable timeout, with error generation enabled on the Wait steps as a safety mechanism in event a process hangs (rare, but not impossible). During normal execution these timeouts never trip, and all runs beautifully.


If I set a breakpoint/single-step my execution to troubleshoot one of the measurements during design/debug, often times it takes a while before I 'resume', and when I do, the timeout on the parallel wait immediately trips with error.


would there be some way to make the Wait step's timeout logic 'pause' while execution paused and 'resume' when sequence is executing normally? that way the error I'm trying to trap during debug won't get confused with an irrelevant error for 'you took too long'...


i know I can put conditional logic on the timeouts to discard the error if running inside the debugger, but it'd be cool if the step was just smarter in general


--Elaine R

Although LV ring type represents itself like that:




TS presents it like a number:




Please resolve the names from the ring type in the step settings.



The behavior of the TestStand - End Modal should be changed.  The current behavior is for it to not execute if an error occurred before it runs.  Instead, it should always execute, even if an error occurred before it runs.  With the current behavior, if an error gets passed to the VI, it can cause TestStand to hang.  In general, close or end functions and VIs should always execute even if an error occurred before they run because unintended consequences such as errors, crashes, or hangs can happen if they don't execute.  Yes, you can use the Clear before the TestStand - End Modal and Merge Errors function to work around this behavior, but it would eliminate the need to do this if the behavior of the VI were changed.

The current placement creates confusion about what you’re actually closing out of when you click it. It makes me hesitate and wonder what I am about to close. 


If you click it when there are multiple files open, it just closes out of the tab on top. If you click it when there is only one file open, it closes out of the whole pane, including the Sequences and Variables windows.




It would eliminate any ambiguity if the X for each file were on the tab for that file and if there were a separate X for the pane, like you typically see in tabbed programs.


You could also just put an X next to the pin on each little window instead, like the X in the Step Settings pane and the Insertion Palette in the screenshot above. 

Right now it appears the sequence analyzer has no really effective automation options?


I can use the command line to launch the Sequence Analyzer, but I really want to run this puppy headlessly against a codebase every 24 hours similar to how VI Analyzer works.  Ideally, yes, I'd love a full API, but for the short term, would it be possible to expand the command line?


what we have currently is:

AnalyzerApp.exe "C:\My Documents\MyProject.tsaproj"  to get the window open with the right project in it.

what would be seriously helpful would be to add: some sort of "-Run -Report "C:\Reports\MyProjectReport.xml""  additional tags?


In general I'd love for the tool to (1) launch, (2) run project, (3) save off file, and (4) close without further nagging on the part of a user.


 Extra kudos would be given if it could generate a standard-out message with some quick stats, if someone was feeling really gung-ho. Perhaps a # of rules, run and # of errors & warnings found?  I can just as easily rake the xml output, so these aren't required, but I am in dire need of a way to automatically _get_ that xml output.


If the tool already does these tasks than please feel free to say so?  I've combed the help in the versions I have installed, and so far have come up with nothing. I'm currently shopping around for a thin ui-robot to get the job done...


Like described in this article I have to build Custom Data Types manually to pass enum strings to TestStand.

It would be very nice if I could import LabVIEW Enum TypeDefs into Teststand as Custom Data Types. This way I could save a lot of time.



Browsing through NI documentation I could not see whether logging test results in STDF format is already available or not, and for which SW versions.

I believe there must be some updates for NI document (from 2007) under the following link:


Could anyone please clarify the status?


Currently we are looking into the this as it might be very interesting topic to introduce in our production, where we have the following SW running:

- NI Teststand 4.2.1 & 2.0.1

- LabView 2009 SP1


Best regards

Dejan Lisinac



Everytime you want to update the UUT container, the report generation sequence has to be revalidated. Smiley Mad


Please modify these behaviour ! Smiley Tongue


These behaviour could be perhaps modified by adding a sub container in the UUT container : UUT.Custom

These container could be "non typed" in order to be customizable without side effect. Smiley Very Happy


Thanks a lot!

It would be nice if TestStand provided basic file I/O functions (open, close, read, write) to complement the other functions already available.

Now, when error happens (not during the execution but during the parsing) TS sequence editor displays message like below.




This message can be very meaningless and misleading as it doesn't indicate what is really wrong, it doesn't lead to any file.

It is very difficult to track, because it can happen that after switching the to the development mode this step can be perfectly fine.


Request: please do better description and explanation why particular VIs doesn't work with the RTE.

This function returns Boolean type, not a number type.


The words the index of shall be removed.





Exactly as in the subject.


Sometimes the names variables are long and could be deeply nested into containers.


Now it is difficult to use them as both windows: the main one and Selected are unresizable.


After proposed change the property loader would have all default features(behaviours) as you can expect from the window at this place.


Current situation presented on the picrure below.






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






For the moment Localization files are to be placed in TestStand public or TestStand user paths. Smiley Sad


It should be interesting to move them in a custom directory, which could be configured in the stations options.

(Or defined somewhere in a TestStand project) Smiley Happy


Doing so, would simplify the deployment processus ... and Localization files would not be treated as global files, but project files.

=> When you have to handle with many TestStand project, you could have a directory for each project ... with multiple localizations files different by project !


I think the mechanism of file managment of TestStand should be modified, in order ...


  • To suppress the global files
  • To manage such a kind of project ... (A workspace) ... containing all the file he need !

Doind so, would simplify the deployment process ... to a simple directory copy ! Smiley Very Happy