NI TestStand Idea Exchange

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. 

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

When working with multiple long sequences it would be nice to bookmark locations making it easy to find where you were previously working.  The bookmark could be line highlighting or an icon on the left gutter.  Bookmarks would be saved with sequence.  Multiple colors or icon would be available.

During development of sequences I often do "trivial" changes in order to check parts of the sequence that I do not want to save afterwards  (e.g set Run Modes of steps to Skip). It would be very helpful to see the last changes that can be undone before clicking the Undo-Button arrow (the same applies for the Redo Button of course). This feature would have two major advantages, since one could...

• ... decide whether it makes sense to save the last changes or whether those were only for trial reasons and hence should be neglected
• ... undo several changes in one step

This is implemeted in Microsoft Office programs for example (see screenshot from MS Excel) and I use it there pretty often.

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.

Under Station Options, Preferences, add selector for error logging to:

None

Client SequenceFile Directory

Specific directory

check box for: one file for each error

check boxes for parameters to log:

error time

error code

error message

sequence file

sequence

step

step action

MySocketIndex

Right now it is pretty easy (Thanks guys!!!) to go from a variable that is of a custom type, and find it in the types palette.

This is great, and it should just stay the way it is.

The problem comes when you have an array of type "FOO".  When you try to do this trick on the array of type FOO, it doesn't work.  Arrays of type "Foo" are common enough, and it would be great to be able to go directly to the type definition for the array element, something like this:

(I could see removing the "Types" selection right above the new element circled in red -- it has limited functionality even now).

I am a new user of TestStand for about 6 months or so. Please pardon me if this post is duplicate ... I did a basic search to make sure it wasn't.

Test Stand is able to load a cluster from LabVIEW and show its elements, very cool.

It might be awesome if a Container in TestStand can be loaded into LabVIEW that'd do the same.

It would be helpful to be able to change the font colors that are displayed for steps in the sequence editor.  This would allow users to identify steps quicker for more efficient editing and debugging.

Often customers unknowingly use debug DLL and this results in reduction of the test time.

Sequence analyzer tool should give a warning if it detects that the dll used is not a released one.

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:

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

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)

I know that I can write my own sequence analyzer tasks, but I think this one should be default out-of-the-box from NI:

Add a sequence analyzer warning task that checks for usage of obsolete methods / properties / events.  This way we can use sequence analyzer to help find them and make our code easier to upgrade with future versions of TS

Otherwise, trying to find all the obsolete "stuff" is REALLY REALLY annoying -- a lot of searching

A customer noticed odd behavior when modifying custom data types in TestStand.  After reproducing the behavior, I think it's a better product suggestion because it looks as if what the customer notices is more of a design choice implemented by our software developers than a feature that is not behaving correctly.

The customer, David, created a custom type called DavidsType which was composed of a container and within this container was a collection of strings:

He then created an instance of this type in his DavidTest.seq file under the file global variables.  He called the instance MyType.

Then he goes back to the Types pane and modifies the structure of the custom data type to include another string with a default value of "C".

However, when he goes back to view the already created instance of his data type (MyType) within the variables pane of DavidTest.seq, he notices that only the structure is updated and not the default value.

New instances of the custom data type, however, do show up with the default value as shown below by MyType_Instance2.

The problem is that the customer has many instances of this type that already exist within his code.  He would currently have to create new instances of each type to load the new default value or he would have to hunt down all of the current instances and enter the default value of the new string manually.  I understand that the structure is updated, but shouldn't we build/provide an option to scan current instances of the custom data type and update default values for the elements that are new to a custom data type's structure?

I understand that it is expected behavior to load the default values of a custom data type only with a new instance of said custom data type, but I think we should provide an option/tool/function to our customers which updates all preexisting instances with the default value as well as the change in structure to the current types.  Currently only the structure is updated with a null string.