NI TestStand Idea Exchange

Post an idea

See discussion here: http://forums.ni.com/t5/NI-TestStand/TestStand-and-LabVIEW-treat-polymorphics-with-instances-with/m-p/3064942#M47429

Say I have a LabVIEW Class, and that class contains a method that's a polymorphic VI, and that polymorphic has instances. If I set the instances' access scope to private, and the polymorphic to public, then I can force developers that use the class to use the polymorphic VI (and not call the instances directly). That's awesome. I like that.

but...

Say I'm building a TestStand API that uses a polymorphic and its instances as described above. I create a LabVIEW action step, with a Class Member Call call type, and I target my class. TestStand doesn't support polymorphic VIs, which means neither the polymorphic nor its instances show up in the Member Name list.

This means that, to support my LabVIEW users and my TestStand users, I need to create two separate APIs. The idea is to modify TestStand to allow for Polymorphic VI spacing between the LabVIEW action step type and the polymorphic member VIs.

When setting arrays, even multi-dimensional arrays, it is possible to initialize them in single assignment expression. For example, "Locals.Array = {1, 2, 3}" will re-define Locals.Array as a 1D array with elements "1", "2", and "3". This is essentially the same as C-style initialization syntax, which also supports structs.

It would be helpful if containers could be assigned in a similar manner. For example, the illustrated container:

could be assigned completely using "Locals.Container = {True, 1, "foo"}".

Currently, that syntax generates a run-time error, "Expected Container, found Array of Containers".

The only scenario I could think of where assignment gets a little weird is with Object types, but in that case you'll have to be assigning Nothing, the return of a function call, or an existing object from another property - there's no way to define a literal value to assign there, but that's already the inherent nature of Object types.

My use case is often container initialization. There are several kludges around this - keeping an empty copy of the container and assigning it to the working copy to clear the working copy, individually listing out each parameter, and a few others. Another case is when it's useful to assign a constant to module parameter - it's debatable that may be bad form, but would still dramatically improves the ease of skimming parameters if it were implemented. It would be a slight bonus to Sequence adapter in particular, which cannot expand containers in the parameter list, as other adapter types can (go kudos Allow Sequence Adapter to expand containers in the module tab to fix that!).

View All (1)

It'd would be good if in the Step settings for LV modules we can have a button which can trigger the test saying is that module going to work when we change Development Environment (DE) to Run Time Engine (RTE).

Now, in case like this, we have only a dry information saying TS cannot load the module because probably VI is broken. Problem is, when we switch over to DE VI is NOT broken.

Of course the reason behind is that RTE has not enough information to call one of dependencies, or there is ambiguity in calling a sub-module - for example a dependent sub-module is used called by step earlier.

So, summarising, the test like that would be quite needed (saving time of development), and information returns shall be more detailed indicating the sub-module cannot be loaded by RTE and why.

View All (6)

Currently the Selected Adapterdrop-down list box in tool bar shows only the adapter name example- LabVIEW. If user wants to know if the current setting is using LabVIEW Run-Time Engine or LabVIEW Development System or even the active LabVIEW version, he has to launch the configuration dialog box.

Proposal:

The combobox should also indicate if it is set to use LabVIEW Run-Time Engine or LabVIEW Development System along with the version. Refer image for details.

When deploying from a workspace file, TestStand analyses the VIs it has to include in the deployment package. However, when working with plug-in classes, TestStand will add the parent of a plug-in class, but not its children. Possibly because these are not directly used (they are included at runtime), and thus not recognised during analysis.

I would like to see that TestStand recognises a parent class it includes in the deployment, and then:

includes all its child classes that are in the same project file;
asks to include possible child classes that are not in the project file.

View All (2)

When LV throws an error, it's all very easy to catch via callback and/or is auto propigated through the system to Runstate.SequenceError etc.so it can be detected.

When LV throws a warning... the data doesn't seem to go much of anywhere in TS... and unlike LV it doesn't propigate from step to step either.

I'd like to catch and log these warnings in my error handlers (naturally with different logic, but I don't want to lose the data either, it's important sometimes!)

from poking around, it looks like my options are:

(1) creating a custom steptype wrapper around all LabVIEW step calls,

(2) editing each VI called by TS manually

(3) some fun expression(s) in the 'add additional result' or 'post expressions' sectionsof each LV step, to create new variables in TS on the fly... (or using a post-step callback to do the same)

It would be nice if the LV adapter / LV steptypes had some native way of catching this 'almost error' behavior and getting it into the report at least. I don't know if leaning on the error callback is the right answer, since, afterall, these aren't errors... but having a warning callback feels too LV specific...

How about a checkbox in the LV adapter, where you could specify 'treat warnings like errors' and then in the Error callback you could check to see if the bool was false, and punt as desired?

Is there something I'm not seeing that would be a better solution?

--Elaine R.

View All (1)

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

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

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.

View All (1)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Modify TestStand to be a static link to a particular instance VI via a Polymorphic VI in a LabVIEW action step

Allow containers to be assigned/initialized completely in a single expression

LabVIEW Enum update should not always generate a Module reload ....

Loading LV modules by Run Time Engine (RTE). Test is the LV module going to work with RTE

Adapter drop-down list box in tool bar should show more information.

Launch adapter configuration dialog box from a double click on respective adapter icon in Insertion Palette (present above Step Types list)

Include plug-in child classes to a deployment package

Implement execution timeout option in Adapter Module Configuration/Setting

It would be really nice to be able to call LabVIEW functions (primitives) directly from TestStand steps

A way to trap LabVIEW Warning data the same as LabVIEW Error Data from Steps

DotNetAdapter: Help Button

DotNet Adapter : Add the ability to view the numeric values of dotNet enums ...

Adapters: Exposure to WebServices

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

Sequence adapter available for substeps

Intelligent Variable Creation

TestStand Container Automatically Loaded to LabVIEW

Allow Sequence Adapter to expand containers in the module tab

LabVIEW steps Shoud recognize Green clusters.

VeriStand Adapter