NI TestStand Idea Exchange

Often working with Full Featured UI and Simple UI codes to create custom interfaces for TS, I noticed that the versions shipped with LV2012 are full of deprecated functions.

Also, most of their implementation go against good LV coding rules.

Re-writing them could be a great idea !

The menu to create a new variable (right click on variable in an expression edit control and select Create "VariableName") contains all the data types you can use for the variable, however, in the LabVIEW Panel (and other similar panels or dialogs) there is enough context information about the variable to suggest a data type, for example, if the variable is in a control of type Double we know we should create a Numeric variable. TestStand should add the contextual suggestions to the top of the context menu and bold them so that I can more quickly select the data type I want most of the times, then have a separator and put the normal menu so if I don't want that data type for some reason I can still choose the other data types (see attached image).

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.

Thanks,

Paul

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.

It would be nice to have some kind of Custom Step which gets triggered when a step is deleted from a sequence. Something very much similar to "OnNewStep" which is triggered when a Step is dropped into the sequence.

We may have an option, say, "OnStepDeletion" to detect the deletion of a step. This will be very helpful in many of the step usages.

The TestStand Flow Control Steps like "IF" and "FOR" use the "OnNewStep" to create an "END" step along with them when they are dropped. But there is no means to automatically remove the created "End" when the "FOR" or "IF" Steps are deleted from the sequence. The proposed "OnStepDeletion" can be handy in such cases.

I hope you all will support this idea as it will make many of the functionalities more efficient. 

Regards,
Nitz 

(PS : Forgive me if anyone has posted this idea already. I couldn't find any such posts)

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%

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.

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.

Currently, if you create a step type and name it OnNewStep, it will execute when an instance of the step is created.  This is pretty confusing to new users - why don't we just have an OnNewStep substep type (like prestep, edit, etc)? Custom steps would then just be meant to be called manually using the Step.ExecuteSubstep() Method as documented in the help.

We could keep the "onNewStep" custom step functionality to maintain backwards compatibility with older step types. 

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....

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.

Having the ability to have line numbers for all steps in the left hand gutter would help in troubleshooting, code reviews, and any time when communicating about a sequence.  There seems to be a gutter there already, so adding there seems to be a place for them already.  Error messages can also post the line number too.



How many of you would benefit from the addition of a feature similar to LabVIEW's Quick Drop?

The functionality that initially comes to mind would be typing to search for your desired step type or step template and dropping it into the sequence you are developing. Please add comments for any additional functionality you might like to see in a TestStand step Quick Drop (for example, you may want TestStand to automatically navigate to the Step Properties of a step after it is dropped from Quick Drop).

Please also add comments for any other situations/scenarios (outside of adding steps to a sequence) where you might benefit from a Quick Drop-like functionality. Thank you.

Hello,

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. 

Cheers!

Shawn S.

The output messages are a good way of sending status messages from the test solution to the end user.  However the control is not available as one of the controls that can be added to user interfaces.

Can this control be made available to be quickly added to a UI and linked to the execution view manager.

Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms.  If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5).  If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.