From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand Idea Exchange

Post an idea

Modifying names in interface are never good idea, but some times it is must.

No matter is the change made in LabVIEW Front Panel or in TestStand type cluster mapping. Or the cluster type is changed for some other reason. The changes needs to be applied in LabVIEW module call parameters.

When you have multiple sequence files and multiple calls to same VI or with same cluster type in each of them, you would not really want to go trough the steps one by one.

Ideas:

- Cluster mapping changes apllied with LabVIEW Protorype reload

- Cluster mapping changes applied to hole sequence file or/and to all same VI calls in the sequence file

- Need of cluster mapping change applying notified with Analyzer

View All (2)

Since TestStand 2019, it's possible to configure an action step with a LabVIEW Module to switch between using a source VI and using the same one but compiled into a LabVIEW Packed Project Library (PPL).

The option, accessible in two ways, is called "Always run VI in Packed Project Library".

That's a neat possibility since it's allow to switch between a development version with easy debugging of a classical VI, and an optimized and locked production version with PPL.
One non compiled VI
One compiled VI into a PPL
One LabVIEW project
One TestStand step

However, when LabVIEW Adapter is set to Run-Time, a tight coupling between the compiled VI and the non-compiled VI is maintained for no reason.

Example 1)
-A VI is developed and compiled on a development machine A
-It is called as the module of an action step
-The VI, the PPL, the .lvproj and the .seq are pasted on a production machine B with fresh installations of LabVIEW and TestStand
-LabVIEW Adapter set to Run-Time on machine B
-Always run VI in Packed Project Library set on machine B
--> The execution will not start, since the classical error -17600 appears on the call. The reason is because the LabVIEW cache of the machine B does not contains data from the .lvproj. Simply opening then closing the .lvproj updates the LV cache, which solves the issue. However, it makes no sense to depend of the LabVIEW development environment on this production machine since the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled.

Example 2)
-LabVIEW Adapter set to Run-Time
-Always run VI in Packed Project Library
--> If source VI is deleted, it takes a long time to preload the modules. See here

Proposition :
When the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled, it should be possible :
- To not install the LabVIEW development environment (only the LV Run-Time)
- To keep only the PPL (and eventually the .lvproj) and to delete the source VI (no source code on production machine)

View All (4)

View All (2)

The concept of TestStand, a sequence. Sequences of groups. Sequences of Sequences.

Pre Sequence, Post Sequence, Pre Test, Post Test. Run as a process, iterates on product instance. Single Up, Multi Up. Is incredibly flexible.

The paradigm is for test. No reason to constrain it to test processes. The paradigm cannot be adapted for an process that runs sequences, and iterates.

Test Stand can be used as a vehicle to build and manage pipelines for Machine Learning Processing. For both training and inference.

For example - I want to do some ML training with hyperparameter tuning. Queue up the variants and run the sequences, compiling the results.

Better Yet, Andrew NG is pushing data centric AI. Use test stand to queue up data variants, train and eval a model. Auto generate the results.

The BIG Tech platforms all support data pipelines.

TestStand has it built in.

Hi! Feature request that I hope is fairly simple to slide into the next rev. It's incredibly frustrating that a Combo Box's values (for a control wired to the connector pane of a VI) aren't selectable like Enums and Rings in the LabVIEW Adapter. Instead of seeing a drop down with selectable options, I have to open the VI, (open the control if it's a typedef), edit its values, then see what the values are, close that dialog out, close the VI, back to TestStand and put in the value. This is all so I can just hard code a value. This is crazy. I tested this out in 2019 64-bit, btw, so maybe it's available in later versions, if so, please let me know.

Thanks for your time.

View All (1)

View All (2)

Hi,
I would like to show the following problem with the Update Custom Data Type from Cluster tool when updating TestStand container type definition based on LabVIEW cluster.

TestStand creates new container type definition according to the LabVIEW cluster items order. The problem apears after you create the TestStand type definition and then reaorder LabVIEW cluster. After this change in LabVIEW, TestStand will not properlly reorder items in its definition. So for example:

We have LabVIEW cluster { 1My String, 2My Numeric, 3My Boolean },
Then we create TestStand type from it and we have { 1My_String, 2My_Numeric, 3My_Boolean},
Now, we change order in LabVIEW { 3My Boolean, 1My String, 2My Numeric },
TestStand do not see change,
Then we add new item in LabVIEW { 3My Boolean, This is new, 1My String, 2My Numeric },
Update in TestStand will be { This_is_new, 1My_String, 2My_Numeric, 3My_Boolean}.

So at the end we have:

in LabVIEW : { 3My Boolean, This is new, 1My String, 2My Numeric },
in TestStand : { This_is_new, 1My_String, 2My_Numeric, 3My_Boolean}.

IMO items order can be sometimes (if not always) important part of good style. That's why I would like to suggest to update also items order if you select Force Exact Match.

View All (1)

View All (2)

(This idea was created as response to this discussion board topic: https://forums.ni.com/t5/NI-TestStand/ExpandPathMacros-FindFile/m-p/3767542#M56811)

The commands "Engine.FindFile", "Engine.FindPath" and "Engine.ExpandPathMacros" only support one macro:

$(Platform)

but there are other generic paths that could be helpful e.g. when trying to call a third-party .dll (that's my main usecase) or write a logfile:

-------

$(commonprogramfiles) - The actual folder name varies depending on Windows language settings and bitness. No absolute paths possible but a lot third-party .dlls are here.

$(temp)

$(localappdata)

$(appdata)

$(user)

$(public)

$(MyData) - The actual folder name varies depending on current user and Windows language settings

It hopefully shouldn't be too hard to access the windows functions which get the actual names via macros.

Now TestStand 2016 supports enums, I found myself in need of an Enum Step Type to check the value of a Enum.

I have VI that returns the UUT's current status as an enum. E.g. Booted OK, Bootloader, Timeout or Error.

In this case I want to check the UUT has got to the Bootloader...

I intially worked around using numeric limit test with Datasource set to "Val( Enum("Boot_State","Bootloader"))". But then in results it would be nicer to see "error" than the enum constant.

Then I relaised I could use the String test instead.... which is better. Example attached, casting to Str instead of Val.....

View All (3)

View All (1)

View All (4)

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:

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

Apply Cluster Passing Changes - Improvements

Review all idea Exchange and Update status

Improvement of LabVIEW Packed Libraries TestStand options

Quick Preloading Modules when no source for PPL

Native support for maps or dictionaries in TestStand

Python adapter supporting keyword arguments

Python adapter dict or json datatype

TestStand Sequences for Machine Learning Pipelines

Combo box Names and Values displayed like Enums and Rings for LabVIEW Adapter

Select enumeration value directly in SequenceCall

Update Custom Data Type from Cluster Force Exact Match - update items order

Add support to call modules built with .NET Core

Select VI PPL View

Additional macros for "Engine.FindFile", "Engine.FindPath" and "Engine.ExpandPathMacros"

Enum Step Type Test

lvoop class choose implementation of dynamic dispatch VI

Programatically allow to select LV Adapter Development System version

Support "Add Array Item" for Array of Structs in .NET code modules

Host .NET processes outside of TestStand's application space

Allow Custom LabWindows/CVI workspace or project from TestStand