From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

 

Setup.png

 

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.

 

Adapter Settings Modified.png

 

 

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

 

Adapter Settings Modified2.png

 

 

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

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.

 

TestStand context help pane.png

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 currently use property loader to load calibration data from a file during test.  I populate this file using export.  The problem is that now I want to write a calibration sequence as well and there is no property exporter step to do this programatically in TestStand.  I will end up writing my own code to create this to emulate the way that Import/Export does it but it would be nice if this was supported as a 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

 

I think that this simple change to the sequence file callbacks dialog would make it far more simple and intuitive.

 

new:

 newcallbacks.png

 

current:

 

callbacksDialog.png

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.

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":

 

TestStand Idea Exchange - Enable Result Recording On Step Failure.png

 

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

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.

AddViewToSGviewer.png

 

 

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"

 

viewexistsinSFview.png

 

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:

 

addedView.png

 

 

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,

For some reason I was certain this was already in the idea exchange, but I couldn't find it -- so I'll post it.

 

Select Case structures are frustratingly difficult to use if you want one case to support multiple values.

 

In text languages you can often do something like

 

Switch (Foo) {

Case 1:

execute this code;

Case 2:

execute this code;

Case 3:

Case 4:

Case 5:

execute this code;

Case 6:

execute this code;

Default:

execute this code;

}

 

Notice that the case for 3,4,5 is all the same, and I just need to put it in place once.

TestStand can't do this.  You need to do something like this:

how to do select case on multiple values

which is horribly difficult to write, maintain, and understand what is happening.  It would be MUCH easier if select case on multiple values worked like this:

SelectCaseImplementA.png

where it looks just like other text based languages, although it takes up quite a bit of realestate on the screen.

or maybe something like this:

SelectCaseImplementB.png

where I can just type in a comma separated list of allowed values.  The similarity with text based languages disappears here, but it is much smaller on screen (but notice how it shows nicely in the description field) and lines up better with LabVIEW notation.

 

 

Note: LabVIEW already supports doing this, and also supports ranges of values (eg 3, 5..10, 12 for numerics) which would also be nice, and also supports case sensitive and insensitive comparison for cases. 

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.

We have several sequences which are too long to execute (test stand crashes during the initial load) using the preload option.  These are often sequences with 50-100 subsequences which define contiguous tests to be performed.

If Test Stand had a 64 bit version additional memory would be a solution to this problem.

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

 

obsoleteAnalysis.png

It would be great to have the ability to create an independent TestStand configuration that is valid in a workspace context. That would allow project specific search directories, StationGlobals an several other configuration items you normally don't want to share across projects on the same test station.

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.

viewtype.png

 

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:

 

viewtypearray.png

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