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

Recently I tried to add in custom error handling to the NI_DatabaseLogger.seq, but because Plugin Sequence files don't support Engine Callbacks, this was difficult.


This idea is to allow model plugins to access Engine Callbacks, so that we can override their behaviour with customised sequences.

  • Reporting and Database Logging

The "Report Options" dialog box provides a lot of flexibilty in the way reports are generated for sequences executing under the Batch model.  A new report can be generated for each UUT, for each socket, etc.  One option that appears to be lacking, is to flat out not generate a Batch Report.  Doing a brief search, I found at two other folks who were trying to do the same thing:


Suggest adding another check box to the Report File Pathname on the Report Options dialog box to disable batch reports.

  • Reporting and Database Logging



As we can read in this very good document, we can add information in header for UUT in Report.

It is mentionned that we can do that for StationInfo in the same way:

"The report below includes the custom data in the AdditionalData container.  The process for adding custom Station data is similar, but uses the Parameters.ModelData.StationInfo property instead of Parameters.UUT."

In fact, it doesn't work in TestStand 2014 and later, certainly the same for 2013 because the default report plug-ins doesn't support it as you can see in the help of TestStand 2016.

Maybe NI can add it like it is done for UUT.AdditionalData. The goal is to avoid to put some Station Info in UUT result to show it easily in reports.


Best regards.




  • Reporting and Database Logging

Why not make it possible for Teststand to generate reports in PDF format?

It would make it a lot easier to send a testreport of a specific board to people not connected to the actual tester.


Today we use XML but this requires the stylesheet to be present on the readers pc.

Graphs are also not showing correct unless you do a manual setup of the settings in Internet Explore.


PDF would make my life a lot simpler




  • Reporting and Database Logging

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%



It would be helpful to be able to provide a regular expression (like Labview Match Pattern) as a string value test limit.  We often look for a pattern of data within a string rather than a constant.

Maybe also a regular expression function within the built in functions within TestStand expressions would be a help also.  This could provide more flexibility if a user needs it.  For example adding option to gain match position, and match length as well as give the option to search in reverse and ignore case.

  • Reporting and Database Logging

As NI has acknowledged (here, here) for more than 5 years, the Build .sql File button creates schemas with errors.  This is even true for the default schemas in the left of the dialog.  Would be great if NI would go ahead and correct this.  BTW - to create default tables in the meantime, a developer should use a SQL file located here:  <TestStand>\Components\Models\TestStandModels\Database



TestStand Database Options Dialog.png

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use. 







This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.




Kyle Mozdzyn

Applications Engineering

National Instruments 

A nice feature of reporting is the ability to form the report file pathname using an expression.  However, since the path is resolved before the client Sequence file is executed, you cannot use properties populated in the client sequence file as part of the report pathname. Currently the only way to accomplish this without modifying the model or reportOptions callback is by including the <UUTStatus> macro in the path expression, which enables a portion of the process model which copies the report to a new path based on the result of the UUT:



I propose that we add an option to force the report path to be re-evaluated after the client sequence to allow users to include properties evaluated in the client sequence file in the report file path without needing to include the <UUTStatus> macro.  (basically exposing the ReportOptions.NewFileNameForEachUUTStatus property in the dialog)



Would like to have the choice of "No Comparison" for a string value test like there is for numeric value test.



  • Reporting and Database Logging

1) TestStand functions Time() and Date() only output local format; they should support both local and UTC format. (Like LabVIEW's Format Date/Time String)

2) TestStand configuration options should have a setting(s) for:
report time format local / UTC
datalogging time format local / UTC



  • Reporting and Database Logging

It would be nice to be able to log all requirement links during execution in the report. I think the option should be similar to "Include Attributes".


Currently, loging requirement links in steps is easy as additional result (preconfigured, just include it in step settings).

But logging requirement links in sequences or sequence files is not easily done. It requires either a dummy step which transfers the requirement list to the step requirements or an overelaborate expression in the sequence call step.


I think a drop down would be a good option:

"Log requirements list:

- For all steps

- For steps and sequences

- For steps, sequences and sequence files"


I am not sure if more options are necessary as empty requirement lists wouldn't appear in the report at all.



  • Reporting and Database Logging

We in our company are done now several test systems where the best process model is Batch Model. Customers however does not want other reports than UUT report from each test socket. Simple skipping of batch report generation is not possible at the moment particularly now when plug-in structure has arrive for joy of us all. For me this wanted feature is late now because I manage to find out solution, with a great support of local NI team. Finally this feature of easy batch report disabling would serve future generations and today newbies. They will save hundres of hours when they don't have to use try&fail -method to skip those few meaningful steps but just make one selection in report options.

  • Reporting and Database Logging

It would be nice if Teststand came with a pre built sequence or example to Generate a Test Report of UUT Results that are already in the database.

  • Reporting and Database Logging

In the report options, when you have selected to include measurements and insert graphs, it would be nice if TestStand could provide an option to display multiple numeric limit test measurements in graphical form. To expand on that, when the value goes outside of a limit, it would be nice to have a red point on the graph to show where this occurred at. 



  • Reporting and Database Logging

The suggestion is to support logging a datetime with millisecond accuracy to an sql database with an NI_DataOperation step.

I tried to implement this, but the milliseconds are not written to the database.

It would be very usefull to support this feature.


The datetime field in the sql database is defined as follows:






The datetime is logged to the database, but only up to the seconds, although the format string is defined as "mm-dd-yyyy hh:ii:ss.sss" and the string does contain the milliseconds e.g. "2-10-2016 11:49:15.505".

Software Details: TestStand  version 2010 SP1, Operating System:  Windows 7

  • Reporting and Database Logging

When a 2d array is added to the report as table, you get the following table:



[0][0]  00

[0][1]  01

[1][0]  10

[1][1]  01


It would be better to have a table like this:

      [0] [1]

[0]  00  10

[1]  10  11


Currently this needs to be implememented in the stylesheet. But for a lot of users, this is a complex workaround.



  • Reporting and Database Logging

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>

  • Reporting and Database Logging


something Kekin proposed with the digital signature made me think, that it'd be nice if there was a  means to suppliment/append to header/footer of reports in general without having to do it with raw statement steps...  (and if this already exists I apologize for not checking first).


I think it'd be neat if there was an approach similar to the 'Additional Results' logic per step that's available.  In the 'ModifyReportHeader' callback, or in the report options somewhere, a user would be able to supply the data within a certain list of available options/allowable types, and the report generator/DLL would handle the formatting/whitespace such that it works for txt/html/xml headers without the user having to do the formatting themselves.  From my experience, most items added to headers consist of (1) supplimental string data, (2) supplimental numeric data (3) small images/logos(in the case of txt, maybe the alt text can be used, or just the path put into the file...?) 




even if the new info was just tucked into the list/table before the failure chain block, it would be a nice time-saver for users who want a generic report but just have one more UUT detail that needs to show up in the header.


  • Reporting and Database Logging

The default process models internally enable/disable the PostResultListEntry callbacks in ways that aren't intuitive to users seeking to quickly edit a callback to customize/override behavior. 


It would be nice to see that instead of simply turning off the callback (leaving users to wonder why their override doesn't work like all the others, except if they read the help/ or think to turn on 'on the fly reporting') as part of the process model based on the options....


(1) leave the callbacks on and move the 'on the fly' logic into an IF defined section within the sequence


(2) make a second PostResultListEntrys  style callback that's explicitly for 'on the fly' that is in addition to other PostResultListEntry behaviors that a user may want to enable/add.


I've had several customers now who have designed custom event loggers / reports around the ProcessModelPostStep callback (with some rather convoluted logic where they dig for results)  simply due to the fact that they couldn't understand why their PostResultListEntry callbacks didn't work.... or that they didn't feel comfortable editing the process model in order to remove the logic that force the callback to be disabled when not 'on the fly' and also keep the 'on the fly' reporting unharmed if they want it later.




Elaine R.