NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

There are many reasons why TestStand is not my language of choice.... I will start with this one... The TestStand Version Selector needs improvements.

If the users are to base the reliability on the interface, then the TVS needs to be much more reliable. When switching from one version to another, the version selector hangs more often than being able to accompish its task. The TVS just sits there pretending to do something... well... it probably was doing something, decided it was lost and then decided to sit and watch the CPU clock cycles go by...

I usually kill the task and try again... By the 3rd attempt, it will somehow manage to switch versions. These attempts give me enough time to write this idea.. After killing the application, I always get the "Unable to determine the current TestStand version" message. This is usually a good sign as the next attempt will probably be a lucky one.

I decided to search the forum to see if others had issues with TVS, and of course, I was not alone. Se the links below:

http://forums.ni.com/t5/NI-TestStand/Operation-failed-popup-when-using-TestStand-Version-Selector/m-p/2354516/highlight/true#M40275

Josh W is not a novice at TestStand...

http://forums.ni.com/t5/NI-TestStand/Problem-launching-TestStand-2012/m-p/2401666/highlight/true#M40716

http://forums.ni.com/t5/NI-TestStand/Microsoft-Visual-C-run-time-error/m-p/860288/highlight/true#M23219

Just how long is being patient? I have waited more than an hour (during lunch) and it still does not swap versions...

I do realize that most issues are related to microsoft visual studio or visual C++, but TSV needs to tell us what is going on or why it is not able to switch version. After all, once it finally changes versions, TestStand is fine. No changes to the PC or any software installation. So the issue clearly points to TVS.

When you improve the TestStand Version Selector, can you also improve the time it takes to change versions? I realize it's too late to improve the architecture of the language where different version could co-habitate together, like LabVIEW, but at least make it a bit faster..

Now that it has selected the approrpiate version, I shall stop my rant... I mean idea and get back to work.

Hopefully all the people who share the same concern will kudo this idea..

🙂

View All (3)

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

View All (2)

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.

Do you ever have too many custom data types, and it looks something like this

This just really sucks when you have 100's of data types to go through. My list is currently 150 long. That's a lot of clicking on that little arrow at the bottom.

How about something like this:

Go through and reorganize your types

<< insert some whiz-bang graphical editor here that allows dragging/dropping of types into groups -- none of this "move up in list" "move down in list" stuff that we are doing now to move step types in/out of groups >>

Now when you go to insert a type, you see a tree structure and all your types are organized

This would be so much easier to find the type I want.

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.

Regards,
Nitz

(PS : Forgive me if anyone has posted this idea already. I couldn't find any such posts)

View All (1)

I would like to enhance the TestStand Message Box step to add a 'Preview' button. When selected, it would show how the currently configured message box will look when run.

I find that I am often switching around the text, fonts, and other aspects and would like to get that straightened out before run time. I know you can run the step individually by selecting 'Run Selected Step' but that is tedious, plus you have to take into account preconditions and other functionality. Normally, I have to remove the precondition (if there is one) as often the step cannot be run by itself.

So here is my example with the button added. Not exactly sure what tab it would belong on.

Thanks,

Paul

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.

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)

New Paste Value

You can copy the value of a selected variable to another element.

But you cannot paste the value into the selected element in an easy manner.

What you have to do is click into the selected variable’s value field and then Paste, but this doesn’t produce the correct result (for strings anyway)......

You end up with is double quotes!!!

Also if you had ‘Copy Value’ on multiple selected elements and pasted them then you get

So it cannot handle multiple selections.

It would have been better if you could have selected the place where you wanted to paste the value(s) and a new menu item became available ie ‘Paste Value’.

This way should also be able to handle multiple selections.

The problem with double quotes shouldn’t occur and should be corrected with the current pasting of values.

View All (1)

VeriStand Adapter

It would be nice to integrate VeriStand into TestStand with a VeriStand Adapter.

This would make developing with TestStand and VeriStand much easier. The adapter would provide a lot of the VeriStand .Net api natively to testand:

- Deploy a system

- Set/Get Channel(s)

- Stimulus Profiles

- etc.

The adapter would be especially nice for integrating the new Stimulus Profiles in VeriStand 2011. It would allow for you to create the Stimulus Profile sequence and the Real-Time sequence. The Real-Time sequences would only be able to use a subset of TestStand steps, and would have to be different than a normal TestStand sequence because they are executed by the VeriStand engine, but the Stimulus Profile sequence could be a normal TestStand sequence.

The integration of the Stimulus Profiles would leverage a lot of features TestStand already has like source control, requirements, reporting, etc. Also, it would just give the user a much more intuitive experience when using the two together. Their test development would be centralized in TestStand instead of having to switch between the two different editors. It would also give better access to the parameters being passed into the Real-Time sequences at the TestStand level.

There are probably more benefits that could be realized by integrating TestStand and VeriStand, and this is a feature I would love to see as a user of both TestStand and VeriStand.

View All (1)

The built-in Wait step currently causes TestStand to simply stop at that step until the specified period has elapsed. For steps longer than a few seconds, it would be nice to have some sort of indicator to show how much time is left to wait (and to show that the computer hasn't locked up on those waits that are more than 15 seconds).

It would be really nice to have a check box option to show some sort of wait indicator, even if it was simply using the progress indicator in the lower right corner of the screen (something that simple could even just always be enabled).

On a related note, could the progress bar be made wider so that there is more resolution as to how much progress has been made? If there was a ten minute wait for something, the bar would be moving very slowly and hard to tell progression was being made.

View All (1)

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.

The NI-VISA Adapter could present steps that would related to the VISA Interactive Control application (Write, Read, Write from File, Read to File, Assert Trigger, Read STB and Clear). This would allow a developer to create a sequence that checks/calibrates a test station consisting of source, sense and fixture loop-back elements with out dependence on a particular adapter or version of an adapter.

I admit that the IVI adapter is already available, but not everyone uses ( or likes ) IVI technology.

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

NI TestStand Idea Exchange

Support Triple-Clicks in text fields

Improve TestStand version selector

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

Re-write LabVIEW code for Full UI and Simple UI

Make TestStand support both local and UTC formats.

Add Result Recording Option "Enabled On Step Failure"

Allow Sequence Adapter to expand containers in the module tab

Add tree structure to data type menu

Custom Step to detect "Step Deletion"

Message Box enhancement with Preview button.

Step Types for NI-DAQmx

Allow the grouping of sequences within a sequence file

Add option to force the report file path expression to be evaluated after the client sequence executes

New Paste Value

VeriStand Adapter

Add progress bar option to Wait step

Make "OnNewStep" its own subStep type

The ability to have line numbers for all steps in the left hand gutter.

Add an NI-VISA Adapter

Folding editor for control flow