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.
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.
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...
This is implemeted in Microsoft Office programs for example (see screenshot from MS Excel) and I use it there pretty often.
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.
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.
Current shortcuts for TestStand include Ctrl-D to close executions and Ctrl-F4 to close a sequence file. However, both of those windows show up as tabs in the current GUI layout.
Every modern internet browser allows the user to close a tab with Ctrl-W. This would also be a neat feature when only trying to close one report at a time when viewing the results from multiple UUTs, instead of closing all reports by closing all executions with Ctrl-D.
Under Station Options, Preferences, add selector for error logging to:
Client SequenceFile Directory
check box for: one file for each error
check boxes for parameters to log:
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?
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.
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).
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.
How cool would it be to sequence any LabVIEW VI in TestStand? I realize one could make a wrapper around any VI, but that adds not only a layer of complexity, but customization. I am a staunch follower of the KISS philosophy, and custom wrappers are not so simple; well, at least not as simple as no wrapper at all ; )
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)
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.
The Step Type Messaga Popup .
Usually I use the same text in the Step Name for the Title Expression
and for a long time now I have used NameOf(Step) in the Title Expression so as not to have to duplicate the Step Name.
Now that Templates are available I can save a copy this version to use instead of the default step type. But thats only true for my development PC.
This may not be saved on other development PC.
What would be nice if the default value for Title Expression was NameOf(Step) instead of "untitled".
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.
Create a step type that is similar to the multi-numeric limit step type except that it handles the 3 basic data types: Numeric, String, Boolean.
We use sub sequences as our "tests". Because we don't like indentations on our reports and all of the information is relavent to the "test" and we want it grouped it would be nice for the step type to handle those basic datatypes. Also, the report looks messy with all the indentations....granted that could be overcome with some tweaks to the style sheets and such.
You could have a BooleanArray, StringArray and NumericArray as step properties to hold the data source info.
This step type would eliminate all of the test types.
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.