Find yourself placing a Sequence Call step and trying to determine the appropriate value to enter for a numeric parameter called "Direction"? Tired of creating sequences with numeric parameters named like the following: "Direction_0_Up_1_Down_2_Left_3_Right"?
The solution is to support the creation of variables with enumerated type within TestStand. Enums could be created as custom variables and then used as wherever a self-documenting variable is required.
Enum type creation:
As seen from a Sequence Call step to a subsequence that uses an Enum as a parameter:
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.
(PS : Forgive me if anyone has posted this idea already. I couldn't find any such posts)
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.
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.
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.
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".
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.
When you develop custom step types in LV, you often need to unload all modules in order to modify your LV code (it's faster than going on your step type definition, clic Properties -> substeps -> specify code module -> edit...).
A keyboard shortcut to 'Unload all modules' would be so nice to even speed up the process !
It is very common to use a typedef as input or output terminal for any VI. If such VI is used in TestStand either as custom step or in a sequence, then teststand requires a relink of step/sequence whenever the typedef values are modified.
Teststand need to resolve this differences automatically, rather than expecting user to relink sequences.
TestStand can support LabVIEW Clusters, but with Object-Oriented LabVIEW development becoming more and more common, and OOP particularly suited to driver development it seems crazy that one NI product does not properly support the other!
One of the biggest benefits I see is that the inheritance property of classes could allow us to create flexible test systems that can have a particular driver changed without having to change the sequence itself.
See this post
It would be nice to beable to define a variable as constant.This could apply to Locals, FileGlobals, StationGlobals.
Once set mark it so as to be easily identifible as a Const.
The API would also need to include either a Property or Method so that one could determine if a variable is a Constant.
I have extended the multi-numeric step type to use the string and Boolean comparisons. We have several tests that require string verification to match the exact string and to verify the string format. Therefore I have added the ability for the multi-numeric step type to use string comparisons, including regular expression for string testing.
NI has gone through a lot work to get the IVI Components integrated within TestStand as step types. I was wondering why NI has not incorporated the NI-DAQmx technology into TestStand as step types. I realize most TestStand developers would just create TestStand Adapters in the sequence step written in CVI or LV to interface to NI-DAQmx functions. Even the more advanced TestStand Developers would create their own custom step types to interface to NIDAQmx. I have just done that to where I have created a framework of custom DAQmx step types that I use as a small subset from all the NIDAQmx functions used from the NI-DAQmx library.
Recently I have had a number of customers ask me if there was a way to create a timed Message box that did not have buttons on it. Of course I told them that there wasn't any. Their requests did get me thinking and I can see that there are times when a timed message popup could be useful. Essentially it would just display a message and go away after a select period of time. I would love to see one.
It is not possible to perfrom manual selection (for example, between different products to be Tested by the sequence file) in TestStand by using the Message Popup.
It would be great if a TestStand Message popup had pull down list or radio buttons or etc. to provide manual selection from a list.
pull down list and the picture paths could be populated from a 2D array, something similar like this LabVIEW VI:
The reason why I requested this feature is that I am developing a Test solution, where we have to
manually select the product to be tested. My test solution will be used by lots of Test Engineers in the future.
I know that this feature can be realized with a LabVIEW VI easily, but this case, I have no control on the arrangement, layout and stile of this dialog box in the future. In LabVIEW, the pull dow list, buttons and picture can be put everywhere
TestStand would provide a standard arrangement for this dialog.
We found a need to customize the NI version of this step to give more functionality. Our edits updates to allow multiple response text boxes (up to 10), and we added an option to configure the response to be a list controls rather than simple strings. Just added a Boolean to switch to list box and then the user just gives comma separated list of options with the default item first as the initial response string.
This is a simple change to the step and allows far greater flexibility for the step type (also it was easy to make the step upgradeable from the exiting step version maintainign the functionality if one or no string responses being used).
These features are very useful for collecting all UUT information during PreUUT rather than having to throw up popup after popup or create a custom module with a popup in it. Would be great if these features could be included in the standard NI step.
It would be nice to have the message popup be more generic so that it can be used in more situations. For example to notify the user that there is a wait in progress. It is currently not possible to remove the button from the Message popup.
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.