NI TestStand Idea Exchange

When creating custom step types, it is highly recommended to use Post-Step for calling execution module instead of Default Module.

Thus, when instanciating a custom step type, parameters passing is not saved within the sequence but only in the step type definition.

This allows to change parameters passing without having to update all the step types instances.

In some big test benches, it is intersesting to have low-level step types and high step types based on low level step types.

High level step types execution modules are sequences using low level step types.

Since sequence adapter is not available for Post-Step, we are obliged to call the sequence through Default Module.

Thus it can generate problems when adding parameters in sequence call.

I suggess to allow Sequence Call in SubStep creation :

Jean-Louis Schricke, MESULOG

TestStand Architect

I think it would be a great idea to allow the sequence adapter to expand containers like the CVI and LabVIEW adapters do when you are editing the module for the step. 

See attachment.

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

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.

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

LabVIEW recognizes any cluster of <Bool, I32, String> as an error cluster.  TestStand should recognize this as well and default any such cluster output to Step.Result.Error.

With the addition of the Silver controls in LabVIEW 2012 "error out" was changed to follow the style guide recommended naming convention of leading caps and is now labled "Error Out"  which is not intercepted and assigned to step.result.error.

support capture of std output and std error to variables while displaying normal 'dos' window

maybe by integrating duplication or cloning of the std output and std error streams, like the tee function provides in unix

**Added 4/19/2010**

It is nice to have a dos window visible while running executables that take a while to complete.

Often it is important to capture output from executable for parsing.

Currently, if you assign output to a variable, the dos window is not visible.

The usual Insert Step menu in TestStand:

What the menu might look like with a Insert VISA step:

A VISA>>Write step would replace a LabVIEW Action Step such as the one I used below for direct Instrument control from TestStand. Queries would look similar and be able to set limits on the returned value.

LabVIEW VI for the power supply command to the VISA instrument setup from M&A Explorer.

This is “PS1” in Measurement and Automation Explorer uses Alias Name.

Example of Query instrument to an Agilent 34970A using Alias Name “DM1” setup in MAX.

However, a little more complicated than a single string command from the menu. Might take several Write steps first.

Possible Uses:

1. Debugging
2. Instrument control without additional software or programming languages.
3. Ability to immediately add new instruments and modify existing sequences without an instrument driver. Demonstrates the quickest possible way to gain instrument control with the least effort (for simple systems).
4. Simple test sequences can be written right away making it easier for technicians or engineers to write tests.
5. VISA sequence steps can be dragged to the palette and easily re-used.
    

The current interface for DLLs does not nicely accommodate C++ classes.  For instance, there is no inherent mechanism for passing in and out of DLL calls the reference to an instance of a class.

I Hate Wrappers!  (Not the artists...)

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