NI TestStand Idea Exchange

Post an idea

TestStand Sequence Grouping

We have multiple sequences in a file to perform steps that are common to particular subsystems. It would be nice to have the ability to group sequences within TestStand. I could envision this to look like a treeview or folder/file structure within the Sequence Pane. Currently, we have to use a common naming convention to group the sequences together like below:

GPIO_Inputs_[Seq1]

GPIO_Outputs_[Seq1]

GPIO_Outputs_[Seq2]

Communications_CAN_[Seq1]

Communications_Ethernet_[Seq1]

Communications_Ethernet_[Seq2]

Communications_UART_Port0_[Seq1]

Communications_UART_Port1_[Seq1]

Communications_UART_Port1_[Seq2]

With grouping, it could look similar to below:

Communications

CAN

[Seq1]

Ethernet

[Seq1]

[Seq2]

UART

Port0

[Seq1]

Port1

[Seq1]

[Seq2]

GPIO

Inputs

[Seq1]

Outputs

[Seq1]

[Seq2]

In addition, there could be a toolbar menu item to switch between showing the grouping or all so you could sort to find

View All (7)

If you are using a custom environment file for TestStand 2016 and later, it would be great if, on startup, the splash screen indicated the loaded Env file name and path.

As you can see below, in our custom TestStand RTOI we are showing the loaded environment file on the splash screen when it loaded. The TestStand 2019 splash screen is shown for comparison.

Download All

The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.

On many an occasion I've wanted to wrap the following basic functionality:

Run a specific sequence file (with or without a [typically custom] process model)
Wait for it to complete.
Retrieve the result.

It's something I've needed to do in all of the following situations:

Integrating into a customer's existing framework
Integrating into my own automated test framework
Providing a simple API to a customer
Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls

The solution I've ended up defaulting to in the past has been some variation on:

Start with the full-featured C# UI.
Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.

The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.

When user opens the Offline Processing Utility and at the same time starts to type on the keyboard the user can accidently rename the profile.

(Attached a screen-recording to visualize)

It would be great if there was no selected row or column when starting/opening ORPU. The renaming of the profile disturbs the production since the database logging will not work as expected.

When we start ORPU we already have the '/tray' enabled but somehow its still possible to accidently rename the Profile.

When TestStand launches, it determines the active LabVIEW version and copies the TestStand API VIs into <LabVIEW>\vi.lib\AddOns if not already present. (SOURCE)

I suggest there should be an additional step here and TestStand should call that LabVIEW version to mass compile these VIs.

Currently, the VI version remains unchanged which means when you open a LabVIEW code module which uses these, you'll sometimes find you have a 'dirty dot' due to unsaved changes because of the recompilation. It also means that you wouldn't be able to run a sequence using the LabVIEW Run-Time Engine until you've switched to Development and converted the VIs.

This is a minor annoyance but it would be nice if TestStand could cut out the additional version conversion step.

I do wonder whether the transfer of the TestStand API VIs into the vi.lib could actually occur when LabVIEW is installed if a TestStand installation is detected. Perhaps this might be relevant for other addons which existing LabVIEW installations have.

View All (4)

Property loader JSON support

The property loader step allows the source location to be defined via an expression. However, if that expression does not evaluate to a file on disk at compile time you get an error. This isn't always desired behavior, for instance, when used in a plugin architecture.

The current workaround is to include a dummy file which could unnecessarily complicate the software & deployments. A dummy file also has the potential to mask errors that should be presented to the user.

The only validation TestStand does of the property loader source location file is that it exists. It doesn't do any validation on the file contents. So is there any benefit? TestStand properly throws an error if the expression doesn't evaluate to a valid file.

Alternatively, a developer could deselect the sequence analyzer rule "Property Loader source should be proper", but this would disable it for all analysis not just the ones that use expressions

Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.

For example:

TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.

With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".

Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.

Thanks!

View All (4)

Hello,

CSV Input Stream allow to parse CSV files to input data into a Stream Loop for instance. By default, the separator is a comma (,). I use a non english version of Excel to edit a CSV file, and every CSV format write a semi-colon as separator (;):

A;0;0;2
A;10;30000;5
A;20;15;7
B;75;42;1
B;100;12;0

Using an expression, I am able to dynamically (at run-time) change the property SeparatorChar:

Locals.MyInputStream.AsCsvFileInputRecordStream.SeparatorChar = ";"

I think it could be more convenient to have a direct access to this parameter in the configuration pane, allowing also to check the content of the file before execution with Parse Record Prototype funtions.

Best regards,

View All (3)

Expression Variables

I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables. But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression. Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar. It only exists during the evaluation of the expression.

Hi all,

There are times, for instance, when I am paused at a breakpoint and I want to copy the full name expression of some deeply nested variable that only appears at runtime.

I wish there was an option on the context menu that would allow me to copy the full path of some variable.

For instance, in the following illustration I want to be able to copy the string

"Parameters.ModelPluginConfiguration.Plugins[0].PluginSpecific.RuntimeVariables.PerSocket[0]"

I've added a context menu option called "Copy Path", but maybe that's the wrong nomenclature.

Am I ignorant of some functionality that already does this? (Besides typing it in the watch window?)

Thanks as usual,

Mr. Jim

View All (3)

View All (8)

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,

Add Tools to Custom Toolbars

View All (3)

Hi there,

This post is just in order to know why there is a user interface available in LabVIEW language (simple or full-featured) suitable for sequential model and NOT for Batch and Parallel models, while these are available in CVI language ?

The customer, who is an allaince member and a famous TestStand user (MESULOG) submitted this idea because he had to translate code from CVI to LabVIEW, and thnik this would be a great thing to add to the next release.

Cheers,

Mathieu,

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 TestStand Idea Exchange

TestStand Sequence Grouping

Remove bold text for Label Description in Step Settings

Loaded Environment File indicated on TestStand splash screen

Improvements to API and examples to make it easier to run TestStand Sequences headless from LabVIEW

API that doesn't rely on ActiveX UI Components

No selection of any field inside Offline Processing Utility (ORPU) when application starts

TestStand API LabVIEW VIs should be automatically mass compiled when copied into \vi.lib\AddOns

Quick Preloading Modules when no source for PPL

Property loader JSON support

Remove Property Loader Source Location File Requirement

Add support for relative paths and Environment Variables in the Installation Destination for Installers

Clickable Links for Cross Referencing Steps or Sequences from an Expression Comment

Expose SeparatorChar property in NI_NewCsvFileInputRecordStream configuration pane

Expression Variables

Copy Full Variable Name Expression From Context Menu

Order Types Alphabetically in Type Selection Context Menu

Create a configurable Model Callback list

Add Tools to Custom Toolbars

User Interfaces available in LabVIEW : Why Sequential model and not Batch or Parallel ?

Try Catch block to handle runtime errors ...