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
1
1
1
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

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.

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.

 

Setup.png

 

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

 

 

As it can be done in Expression Browser, it is very helpful if we can use Step Name instead of Unique ID with Precondition builder!

 

Precondition Builder Improvement.png

 

Can you specify Step ID.png

Currently, when you rename a variable, you have to rename all the places where you are using the variable manually. It would be helpful to have a "smart rename" option which, after renaming the variable will update its uses.

 

smart_rename.png

I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables.  But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression.  Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar.  It only exists during the evaluation of the expression.

I've encountered on several occassions, especially with complex testing, customers who are frustrated by the inherent 'flicker' that happens when stepping into and out of subsequences of logic. This leads to people opting to not use sub sequences, or creating complex replacements for the execution view that has a more persistant way of presenting the executed step data.

 

I'd like to see an optional setting for execution viewing that allows for sub sequences to be shown as expandable nodes (perhaps defaulted to 'collapsed') so that low level test operators can see the overview results at the sequence-call level, but so advanced users can expand for details if they're interested without added pulldowns or tabs for additional information.  this could be one more API property similiar to showing one-stepgroup or showing all, so that developers can chose whether to be more efficient, or display-heavy....

 

expanded results on sequenceView

 

In scenarios with dynamic sequence loading, the display might simply show a 'no pre-loading possible' sort of message until the execution actually gets to that portion of the sequence.

 

Cheers, 

 

Elaine R.

Handling arrays in TestStand is pretty limiting and more often that not you have to pop into a code module to perform any sort of array handling.

The following is the default functions that can be used in expressions:

[Array
GetArrayBounds(array, lower, upper) Retrieves the upper and lower bounds of an array.
GetNumElements(array) Returns the number of elements in an array.
InsertElements(array, index, numElements) Inserts new elements into a one-dimensional array.
RemoveElements(array, index, numElements) Removes elements from a one-dimensional array.
SetArrayBounds(array, lower, upper) Changes the bounds of an array.
SetNumElements(array, numElements) Sets the number of elements in a one-dimensional array.

]

 

 

I would like to see this expanded to avoided have to resort to using code module.
The following is some suggestion:


Array Subset function
Array Max & Min
Replace Array Subset function
Search 1D Array
Sort 1D Array

 

 

regards

Ray Farmer

I would like to enhance the TestStand Message Box step to add a 'Preview' button.  When selected, it would show how the currently configured message box will look when run.

 

I find that I am often switching around the text, fonts, and other aspects and would like to get that straightened out before run time.  I know you can run the step individually by selecting 'Run Selected Step' but that is tedious, plus you have to take into account preconditions and other functionality.  Normally, I have to remove the precondition (if there is one) as often the step cannot be run by itself.

 

So here is my example with the button added.  Not exactly sure what tab it would belong on.

 

 Message Box with Preview


 

Thanks,

 

Paul

 

Dear NI community,

let me, please, propose the following idea.

 

It would be great, if it is possible to open sequences of the sequence file in different tabs. Currently, only sequence files are opened in separate tab. But, if you need to go between sequences (or subsequences, depends how you name them) of the one sequence file (let's say, to copy-paste some steps from one sequence, to another), one has to click on the sequence in the Sequences tab, and it will be opened in the Sequence View tab, and, meanwhile, the another (previously selected) sequence is not seen. And, one has to click between them in the list there and back, and it's not possible to see two sequences one-to-one at the same time.

 

This is similar to MS Word feature "Open New Window", when one can see the same document but in two windows at the same time. It can increase usability of the sequence editor, and make development a little bit faster...

 

Thanks in advance.

Do you ever have too many custom data types, and it looks something like this

datatype_list.png

This just really sucks when you have 100's of data types to go through.  My list is currently 150 long.  That's a lot of clicking on that little arrow at the bottom.

 

How about something like this:

 

datatype_menu.png

 

Go through and reorganize your types 

<< insert some whiz-bang graphical editor here that allows dragging/dropping of types into groups -- none of this "move up in list" "move down in list" stuff that we are doing now to move step types in/out of groups >>

 

Now when you go to insert a type, you see a tree structure and all your types are organized

datatypes_treelist.png

 

This would be so much easier to find the type I want.

In some cases it could be handy, if you were able to convert a container you've constructed in the variable pane into a type directly from the variables pane.

type_from_variable.png

One case could be, if you chose to store some settings in the sequence file, but the settings are dependent upon fx equipment or the product variant. It can be handy to have a variable with the settings, and an array of settings specific to various configurations from which you can choose. But the 'settings' container and the type in the array of settings containers, of course have to align. And this is best achieved by a custom data type.

Often sequences start out for one configuration only, and later on the need for multiple configurations occurs - and that's why I think it could be handy - if you were able to convert a container, already in the variable pane, into a custom data type.

In order to logically sort sequences within a sequence file, you have to add either a prefix to your sequence names or add dummy sequences between sequence groups:

 

  

 

What would be great is if I could could add sequence groups which let me organize my sequences logically in a tree view. Unfortunately, I can't shoop my vision of that at the moment.

Hi,

 

I came up with a suggestion to improve the TestStand software ( currently using 4.2.1)- may be in the forthcoming versions.

 

1.Is it possible to slightly dim ( or grey) the steps that are skipped while creating the sequence file? This can help the user to know by looking at the sequence as to what steps have been skipped.

 

2. Ability to assign a color to the steps with particular settings: ex: 'preconditions'.

 

Would this help the user for a quick analysis of the sequence file during sequence creation? I am not totally sure but was just a suggestion for improvement. Any expert comments please?

 

Thanks,

 

Yogesh

Expressions offer the following exponential and logarithmic functions:

 

   Exp()    -> Exponential (base e)

   Log()    -> Logarithm (base e)

   Log10()  -> Logarithm (base 10)

 

Computers always calculating digital. I have to handle binary values very often. Please add the following functions for calculating with binary values:

 

   Exp2()   -> Exponential (base 2)

   Log2()   -> Logarithm (base 2)

 

Hello,

 

It would be nice to have a tool such "Trace Toll kit" for TestStand, in order to be abble to view the currently loaded modules. 

 

When you have big Sequences, with many loops, you can get memory problems. Smiley Sad

 

Then you'll have to play with the load options, the results recording, the on the fly reporting .... Smiley Mad

 

It should be nice to had a tools which could show us the memory used by every modules, structures, Globals, fileGlobals, parameters, locals ...

So it would be easier to point to the main memory consumers  !!!! Smiley Wink

 

Or better ... let TestStand access the 64bit world Smiley Happy !

Get rid of the ActivX architecture !Smiley Wink

Memory management should not influence Test creation ... 

 

Thanks a lot.

 

Manu.net

It would be nice to be able to drag a sequence from the sequences pane over into the steps pane and have it automatically insert a Sequence Call Step with the dragged sequence selected. 

When loading large sequence files, TestStand does not display progress and appears to "lock up" both TestStand and the LabVIEW OI.  Sequences with hundreds of steps can take minutes to load.  Operators often incorrectly conclude the application has stopped respoding during long pre-loads.

 

I am suggesting to implement a responsive progress display, allowing the LabVIEW OI to proceed execution, and post the following UI Messages during step pre-load.

 

UIMessageCodes

  1. UIMsg_ProgressPercent–(Value: 11) TestStand step modules post this message to the user interface to notify it to update its progress indicator associated with an execution.
  2. UIMsg_ProgressText–(Value: 12) TestStand step modules post this message to the user interface to notify it to update its progress message associated with an execution.

 

20869i87D31F1755A9EB9F

Let's say I'm building a fairly long compound expression that has some repeated parameters - I would like a way to specify (without creating additional locals) a variable/macro for use just within that expression.

 

For example, instead of:

Locals.CommandLine = "cmd /c C:\some path\that\is\reused"
Locals.CommandLine += " /path C:\some path\that\is\reused"

 

 

I could specify:

#pathmacro "C:\some path\that\is\reused"
Locals.CommandLine = "cmd /c " + pathmacro
Locals.CommandLine += " /path " + pathmacro

 

 

The idea being that with this I only need to update the macros in one place in a long expression.

 

This is a simple example, but hopefully you can see why this would be useful and why I wouldn't want to create lots of locals when the values are required only within the expression.