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.

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

It isn't uncommon to deploy customized TestStand options, such as search directories, on a deployment computer.  It would be much easier to do this if the search directories in TestStand were stored in their own .ini file rather than in TestExec.ini.  You can obviously set the search directories in TestExec.ini quickly using the built-in search directories GUI, but when distributing the TestExec.ini file to the deployment computer, you have to be careful that none of the other options contained in the file don't inadvertently cause problems when executing TestStand deployments.  A separate .ini file for search directories would clearly remedy this situation.

I think that this simple change to the sequence file callbacks dialog would make it far more simple and intuitive.

 

new:

 newcallbacks.png

 

current:

 

callbacksDialog.png

When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help.  While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help.  I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.

 

This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users).  Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.

 

TestStand context help pane.png

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.

 

When monitoring values within a loop in TestStand, it is often desired to only record step failure results.  It would be useful to have a "Result Recording Option" of "Enabled On Step Failure":

 

TestStand Idea Exchange - Enable Result Recording On Step Failure.png

 

This is possible through various means (SequenceFilePostResultListEntry callbacks and other custom code).  However, I believe this would simplify TestStand sequence development significantly.

Hi there,

 

This post is just in order to know why there is a user interface available in LabVIEW language (simple or full-featured) suitable for sequential model and NOT for Batch and Parallel models, while these are available in CVI language ?

 

The customer, who is an allaince member and a famous TestStand user (MESULOG) submitted this idea because he had to translate code from CVI to LabVIEW, and thnik this would be a great thing to add to the next release.

 

Cheers,

 

Mathieu,

 

 

 

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:

 

 

TestStand_dotNET.jpg

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%

 

 

Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.

For example:

TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.

With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".

Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.

Thanks!

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.

How many times have you found yourself typing double backslashes "C:\\Windows\\System32\\cmd.exe" or even worse, going through a copied path to change every backslash to a double backslash (and inevitably missing one), just so you can pass a file or directory as a constant to a code module or another sequence?

 

string issue.png

 

I'd like to see a symbol for 'explicit string' in the TestStand expression language, much like C# does with the @ symbol.

So if we typed @"C:\windows\temp" we would actually get the string "C:\Windows\temp" instead of "C:\Windows<tab>emp".

 

To really go the extra mile on this:

  • Drag and drop could be enabled, so that any file dragged from another window into an expression box would automatically paste the filename.
  • A browse button could be added to the expression browse dialog which would bring up the usual file open dialog and insert the selected filename.
Message Edited by Josh W on 06-14-2010 12:57 PM
Message Edited by Josh W on 06-14-2010 12:58 PM

Please support triple-clicking like in LabVIEW or Firefox...

 

A double-click selects the word at the click position (OLD behavior),

a triple-click selects the whole text (like <CTRL>+<A>, NEW behavior)

 

Thanks!

It would be nice to be able to "fold" control flow blocks (like if - else -end, while - end etc.). Despite the vertical lines connecting the control flow steps on the same level, it is sometimes very hard to find where a long control block actually ends or what the condition for the "end" is you are currently looking at.

 

In such cases it would be helpful, if the entire control flow block could be hidden under its first line, tree-view like with a +/- icon to show/hide the interior of the block.

 

Regards

 

Peter

Please allow the TSDU to password protect Sequence Files on build.  This functionality is already present for VI's in the LabVIEW Options.  Why not make this possible for the Sequence Files as well?  If I need to protect my VI's with passwords, I probably would like to do this with my sequence files as well.

It would be nice if the Step Settings for a Sequence Call step's Module tab would also list the calling sequences comments field and the parameter comments in addition to the prototype information. This would allow sequence calls to easily present information on the expected use of the sequence, along with parameter information (ranges, default options, etc) that would be useful to the developer. I've created a simple mockup of what I'd like to see here:

 

19657iFA3E1FCBE0E24E08

 

By adding these features, sequences can contain their own 'help' information which would allow the developer to configure the call without having to leave the step module dialog.

 

Thanks,

 

-Jack

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.

There is no way to programmatically clear the Output Window in TestStand.  It would be beneficial to be able to clear it through the API and through an expression function.  The only way to clear it right now is manually.  This benefit would allow developer's to configure the system to only see messages from their current run, only show one message at a time so you could iteratively overwrite it to show measurements changing for example, or many other benefits.

I have noticed that the TestStand shipping examples are often overlooked when looking for ways to accomplish things with TestStand.  This is not the case (as much) in LabVIEW and CVI, and I feel that this is because TestStand does not have an example finder.  I would like to see some method of accessing the shipping examples through the sequence editor environment, such as:

 

1-1.png

Another problem with the current setup is that the only way to know what the example demonstrates is the name of the folder.  This makes it easy to overlook examples that would be helpful. 

 

I propose adding a TestStand example finder with these features (in order of importance):

 

  • Provide a description for each example (most of this info can be pulled from the sequenceFileLoad callback dialogs in a lot of the examples)
  • have keywords for the examples, and allow searching
  • for more advanced examples, provide a batch file to load all necessary components 
  • Provide links to the NI community and developer zone to encourage participation

Hello,

 

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.

 

TRY

    Steps ...

    Steps ...

CATCH

     case 35  // Error code = 35

     end

     case default // All other error codes

     end

End

 

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

 

Manu.

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.