NI TestStand Idea Exchange

Hello,

For the moment the runtime error handling can be managed by using ...

Runtime error options
Ignore runtime error flags
Manually, for action steps, by handling actions returns

It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.

TRY

Steps ...

CATCH

case 35 // Error code = 35

end

case default // All other error codes

end

End

Doing so, could be a way to handle runtime errors, in an other way that the global configured way.

Manu.

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.

View All (3)

I would like to ask to add named types support for TestStand array literals. The current behavior is described as follows:

Declares a one-dimensional array of numbers, strings, Boolean values, object references, or containers. If all elements are of the same type, the result array is an array of elements of that type. If all elements are not of the same type, the result array is an array of containers.

I would like it to be more or less like this:

Declares a one-dimensional array of numbers, strings, Boolean values, object references, containers, or named type. If all elements are of the same type, the result array is an array of elements of that type. If all elements are not of the same type, the result array is an array of containers.

The problem with the current implementation can be seen on the screen.

It is not a bug (BUG 1828580 to be more precise), it is a feature.

In some cases it could be handy, if you were able to convert a container you've constructed in the variable pane into a type directly from the variables pane.

One case could be, if you chose to store some settings in the sequence file, but the settings are dependent upon fx equipment or the product variant. It can be handy to have a variable with the settings, and an array of settings specific to various configurations from which you can choose. But the 'settings' container and the type in the array of settings containers, of course have to align. And this is best achieved by a custom data type.

Often sequences start out for one configuration only, and later on the need for multiple configurations occurs - and that's why I think it could be handy - if you were able to convert a container, already in the variable pane, into a custom data type.

View All (4)

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use.

This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

Currently, there is no unambiguous solution for passing empty Array of X (where X is a different type than 64-bit Floating Point) as a sequence parameter. If we use {} it is assumed to be of type 64-bit Floating Point. To have an empty Array of Strings we can use ambigues Split("",""). I have no idea how to pass e.g. empty Array of Signed 64-bit Integer without creating empty variables.

It would useful to have Empty Array Literals of a particular type e.g.:

{} - default

{}i64 - for Signed 64-bit Integer

{}ui64 - for Unsigned 64-bit Integer

{}s - for String

{}b - for Boolean

{}r - for Object Reference

{}c - for Container

{}TYPE_NAME - for type definition where TYPE_NAME is type definition name; e.g. Path.

There are some macros to specify report file name by expression in report options.

Specifying Report File Paths by Expression - NI TestStand 2014 Help - National Instruments
http://zone.ni.com/reference/en-XX/help/370052N-01/tsref/infotopics/specifyreportfilepath_byexpression/

$(FileDate) contains speces in the string, e.g., "2015 12 15". If you want to delete space, you need to use $(FileYear), $(FileMonth), and $(FileDate) instead.

But there is no similar expression for time, i. e., there is only $(FileTime) and we do not have any macro such as $(FileHour).

SearchAndReplace function doesn't work for the macros. It is very helpful if we have $(FileHour), $(FileMin), and $(FileSec) as standard macros.

Before:

After:

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)

Because of the way .NET applications and assemblies are invoked in TestStand they are a child process of TestStand. This means that they share TestStand's resources. For most applications this is not an issue but if the application or library being instrumented by TestStand is resource intensive this creates a significant problem. In the scenario that served as the impetus for this suggestion we saw performance 1/10 that when running the target application outside of TestStand.

To correct this I recommend the .NET adapter architecture be changed or be able to be configured such that instead of directly instantiating target applications a call to create an object with a .NET adapter would create a separate process that consisted of a TestStand WCF client wrapper process that would host the target .NET process and communicate with the parent TestStand instance via WCF.

Here is a simple block diagram of the intended architecture:

View All (7)

Problem:

I create a model plugin and add some model callbacks to it. Then I want to access those model callbacks from my client file. I have to now add them to the process model so they show up in the list when I go to add callbacks. I get that I can add it as a blue sequence and it will work However, that is confusing to other developers if they don't know the plugin has the callback in it. It is painful to change the process model every time I create a new plugin because the process model could be used on hundreds of machines whereas my plugin may only be needed for 1 or 2 machines.

Solution:

Option 1: Show all callbacks from any plugins in the callback dialog list

Option 2: create a configurable list of model callbacks. Basically add any sequence files marked as model to the list and it will show all the callbacks from the sequence files in the list to the client, unless it cannot find the file in any search directory. Then it wouldn't show.

Option 3: From the add callback dialog allow the user to browse to a sequence file which contains model callbacks

I think adding this functionality will greatly help in making the plugins more abstracted from the process models. Just saying.

Cheers,

View All (3)

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.

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

Try Catch block to handle runtime errors ...

Step Types for NI-DAQmx

Allow the sequence parameter to be used with default value if none specified

Array Literal Support for Named Types

Create Custom Data Type from Variable Pane

Simplify exporting arrays of properties

Empty Array Literal

Using time string in report file path without space character

Add ability to search for instances of custom data types

String value - No comparison

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

Host .NET processes outside of TestStand's application space

Python adapter dict or json datatype

Property loader JSON support

Message Popup step: Add Font Justification Setting

Create a configurable Model Callback list

Add a native DateTime data type to the TestStand Engine

Enable mouse button navigation

Add an NI-VISA Adapter

Define Variables as Constant