NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

Hello all TestStand fans,

For my recent project i had to modify the frontEnd callback.

=> According to the TestStand help, the only path where this file can be created is in TestStand default path or in the corresponding user path.

.... But no where else !!!!

It would be nice to be abble to configure the frontEndCallback path in the configure options !

=> Doing so, the path of this callback could be placed everywhere ! (In the configuration path would be nice !)

=> Doing so, it would be possible to create a frontendcallback for each configuration !

I am a TestStand developper, a NI partner, not a TestStand end user.

My work is to provide custom sequencer for my customer.

On my computer i had to manage many different sequencer !

If file are threated as global ... i had to customize my computer to switch among my different sequencers ! (Or to create virtual PC's : Virtual box / VmWare ... )

If all TestStand configuration files where identified in the "Configuration directory", my only work to switch from 1 project to an other would be to point on a different Configuration path !

I think that if it is impossible to do so, today, is because this callback is loaded before the "Station configuration" is loaded ?

My ideas should be applyed to all global files ...

Station callbacks
Localization file
... i dont't know the behaviour of all files !

Please get rid off all "Global files" !
Replace them by files, with path configuration in the "Station options" ... and located in the "Configuration path"

Doing so, will also simplify the deployement process !!!!

=> A single path copy ... is quite easyer as a complicate deployment process !

Thanks for your help.

Manu.net

View All (1)

Hello all TestStand users,

How often i had to debug my sequences ... to find out after many minutes that some of my steps are Skipped !

It would be nice to highlight the skipped steps by default ... (Without having to customize something in TestStand)

By using a stroked font to view the step détail (~~STEP SKIPPED~~)
By using a red, flashy color (STEP SKIPPED):smileyhappy:
Or better, both ... (~~STEP SKIPPED~~):smileyvery-happy:

Thanks for your help ...

Manu.net

View All (1)

Enable mouse button navigation

View All (3)

The settings field can easily become too long to see every active option and there's not necesarily any consistency between steps if they have differing options. What I mean by that is if you only set the "Do Not Record Result" (my favorite) option in one step, it will be on the left of the settings field. But if you now set several options on another step, the settings are not lined up so that it becomes hard to see at a quick glance which steps I forgot to not record (because TS still doesn't default to not recording steps). You have to analyze the settings line for each step.

I propose something more graphical and ordered. Here's my idea of at least ordered. The text could be replaced with icons representing each setting.

Then it would be graphical, ordered, and concise. What more can you ask for?

View All (9)

View All (1)

I am trying to edit step variable properties from step to step.

I edit Step.Foo.Bar.Bing.A in the first step.

I click to the next step, it also has Step.Foo.Bar.Bing.A in it, so I edit that value.

I click to the next step, it doesn't have that variable, so I see nothing.

Click to the next step. @#$%@#$. Expand Foo. Expand Bar. Expand Bing. Edit variable A

Click to next step. Still expanded. Edit variable A

click to next step. No variable matching that value.

Click to next step. @#$%@#$%. Expand Foo. Expand Bar. Expand Bing. Edit variable A

This constant Expand the tree is really annoying. I'd love to be able to set an attribute of a container to say "always expand this completely whenever It shows up", or a sequence editor wide configuration of "always expand all properties when you browse to them" which would work fine unless you have "show hidden properties" enabled, and then you have the whole Step.TS.* tree visible, so maybe a "expand all custom properties" or "expand all non-hidden properties" or something like that. Or maybe a way to click on the "+" expanding symbol for that node in the property browser that would completely expand that node

Right now, custom substeps (edit substep in particular) only supports one step at a time. (I can only invoke the edit substep if exactly one step is selected). However, I have a case where I have a dozen or more steps in a row that are all the same custom step type, and I want to perform the custom edit event on all of them. This means going through each one individually, which takes a while. I'd love to be able to select all of them, and then invoke the edit substep call for all of them at once. The "cheap" way to do this would be to just invoke the edit substep of the first one, and then once that is done to go to the next, and the next, and finally you are done (but this is still annoying to the user). What would be nice is to be able to pass an array of sequence context values in (one for each step that is selected), and then your edit code could manage all of the steps however it sees fit. If multiple different step types are selected, it could just default to not allowing a multi-step custom edit, but ideally if all of the steps selected shared a common edit substep entry (name and module) it would allow it.

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.

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.

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

Often times a sequence file ends up containing dozens (or even hundreds) of sequences. Currently they all show up in the sequence editor Sequence Window as a flat list. It sure would be nice to view them organized in folders so that, for instance, all my sequences dealing with Rs485 communications or whatever could be group together in a "folder" called "RS485". Also it would be great if there was a displayable property for each sequence showing the date/time last modified. Then you could sort the list on that and see which sequences have changed. (really helpful if you have multiple guys who might be making changes.)

Create a TestStand context help pane

When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help. While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help. I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.

This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users). Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.

Intelligent Variable Creation

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

Add a Property Exporter step type

Trim whitespaces in TestStand Step

Hi!

I was working on a project which required LabVIEW 2011 and TestStand 2010. The software had lots of LV modules already created. I reused some of them. However, I needed to trim whitespaces in TestStand which were coming from the string outputs of these LV modules. Nevertheless, I was surprised to discover that there is no TRIM string function in TestStand at all. I had to create a simple VI which just trimmed the whitespaces. I couldn't modify the previously created modules because they were used elsewhere and could affect the outcome of the other test systems. Why does TestStand lack this simple functionality?

Regards,

L_A_B

View All (3)

TS does not allow the ability to rename steps that are of the Flow Control type (i.e. If, Else, For, While, etc.). In a report, these generic names are then used, making it very difficult to know what condition the step was evaluating to determine whether to enter or continue within the flow control block. A step name would normally give the reader of a report some indication as to what is being tested or reported on. This is not the case for these step types.

For example, an "If" step that is determining whether a condition is met (and whether to enter into the subsequent steps within the flow control block) simply shows up in the report as:

Step	Status	Measurement	Units	Limits
				Low Limit	High Limit	Comparison Type
If {True}	Done

There is no indication of what it evaluated to determine it was True, meaning someone reading the report has no idea what the purpose of the step is. As designer of the test, I can look through the sequence to determine exactly what it was doing, but a report is a useful tool to be able to show to someone not familiar with the test and allow them to be able to see what happened. A report gives the reader the history of the test. Without knowing what a step is for, a lot of the "story" being told by the report is either lost or becomes much harder to follow.

I would assume there is a reason as to why these step types are not able to be renamed, but I'm not familiar with what that would be. It would be nice to be able to modify, or at least add to, the step name so that the report gives some indication of what it was that it evaluated. If that is not possible, there should be a simple way to include the parameter/expression being evaluated with the step name in the report. This can be somewhat accomplished using other methods, such as the Additional Results of the Properties tab, but this is not intuitive or clean and I would think this behavior should actually be default, not something the user has to manually create and enable.

Regards,

When monitoring values within a loop in TestStand, it is often desired to only record step failure results. It would be useful to have a "Result Recording Option" of "Enabled On Step Failure":

This is possible through various means (SequenceFilePostResultListEntry callbacks and other custom code). However, I believe this would simplify TestStand sequence development significantly.

station globals view type definition

I've got a bunch of variables in StationGlobals. Many of them are types. I want to edit the type of one of the variables to add a parameter.

Workflow --

Open StationGlobals pane by clicking the "world" icon along the top.

Find the variable instance. I right click on the variable instance, and this is the listing I get

Darn. I was hoping to be automatically linked to the type definition.

Frustrated, I was convinced I had right clicked on instances of types before and been able to directly link to the type definition for that variable. So I go to my empty dummy sequence file, and try doing the same thing from the variables pane of "Sequence File 1"

Ah Ha!!! that's what I wanted.

So how about this -- why don't we just take this "Right click -> view -> type definition" ability that exists in the variables view, and get that feature added to the station globals view, kinda like this:

The current keyboard shortcut for Undo in TestStand and LabVIEW is "Ctrl+z", which is pretty standard in most programs.

In TestStand the ReDo shortcut is "Ctrl+y", but in LabVIEW the ReDo shortcut is "Shift+Ctrl+z". Both of these are relatively common among various programs, but it would be nice if the two programs used the same shortcut for such a simple and common task.

In LabVIEW, "Ctrl+y" already does something else (VI History), but in TestStand, "Shift+Ctrl+z" does not seem to have any functionality. This means that "Shift+Ctrl+z" could also be used in TestStand without breaking any backward compatibility ("Ctrl+y" could also cause a Redo action to avoid breaking that functionality for those who are accustomed to it).

Other NI software may benefit from this standardization as well, but I am referring to LabVIEW and TestStand in this post.

I know it's a simple thing, but as much as one switches back and forth between the two integrated programs it would be nice if this was common functionality!

Thanks,

View All (3)

NI TestStand Idea Exchange

FrontEnd Callback path should be modified in the configure options ....

Please highlight the skipped steps ...

teststand property search please

Enable mouse button navigation

Visual settings in the steps pane instead of a (sometimes) mile-long text list

Select Case End steps shall allow the Label steps to go between them.

automatically expand property browser tree

edit substep supports multiple steps

When calling Dynamic Dispatch VI's Allow A Class Constant To Be Used As An Alternative To The Object Reference

Organize sub-sequences in a sequence file more like file directory structure

Create a TestStand context help pane

Intelligent Variable Creation

Add a Property Exporter step type

Trim whitespaces in TestStand Step

Update the Callbacks Dialog to use Checkboxes

Change in LabView typedef should be automatically resolved by TestStand

Allow renaming (or at least ability to add to the default name) of flow control steps (if, else, while, etc), or define report naming of steps.

Add Result Recording Option "Enabled On Step Failure"

station globals view type definition

Standardize Undo/Redo keyboard shortcuts