NI TestStand Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

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 :

 

SequenceAdapterInPostStep.png

 

Jean-Louis Schricke, MESULOG

TestStand Architect

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.

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.

 

Setup.png

 

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.

 

Adapter Settings Modified.png

 

 

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

 

Adapter Settings Modified2.png

 

 

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 Smiley Tongue ) IVI technology.

 

20623i540AD8DC05484B78

 

Currently, if you have LabVIEW code modules that use maps or sets you have to use something like an Action Engine to interact with the map, you cannot pass a map from LabVIEW into TestStand and vice-versa.

 

Maps are an incredibly useful data structure and having support for them natively in TestStand would be very helpful, not just for LabVIEW but also due to how prevalent maps (dictionaries) are used in Python as well.

 

JorrEl_0-1674075180101.png

 

Microsoft have stated that all future development in .NET will be based on .NET Core, a cross platform development framework.  Therefore the current version of the .NET framework (version 4.8) is the last built on existing .NET technologies, with the next version .NET 5.0 to be built on .NET Core technologies. 

 

Could an adapter that supports calling .NET Core modules be added into TestStand so that users of TestStand calling .NET modules can migrate to .NET Core?

It would be nice to integrate VeriStand into TestStand with a VeriStand Adapter.

 

veristand adapter.png

 

 

 

 

 

 

 

 

 

 

 

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.

 

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:

 

 

TestStand_dotNET.jpg

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:

  1. We have LabVIEW cluster { 1My String, 2My Numeric, 3My Boolean },
  2. Then we create TestStand type from it and we have { 1My_String, 2My_Numeric, 3My_Boolean},
  3. Now, we change order in LabVIEW { 3My Boolean, 1My String, 2My Numeric },
  4. TestStand do not see change,
  5. Then we add new item in LabVIEW { 3My Boolean, This is new, 1My String, 2My Numeric },
  6. 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.

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.

Static enumeration value in a sequence call must be stated as <Enum(String enumType, [String/Number value])>. Please make it possible to select the enumeration directly.

 

 
 

Hello,

 

In current TestStand version (2012), it is possible to view the list of enum values of dotNet adapters parameters.

 

This is great ....

 

But it should be nice to add the enum corresponding numeric value in the dropdown list.

 

This could be helpfull if you had to create a numeric TestStand variable to map to the enum parameter ... and because there are no correspinding enums in TesStand !

 

Thank for help.

 

enum 1.png => Better enum 2.png

 

Manu.

 

I think it can a be a really good idea to review and give feedback on all Idea exchange.

 

You ask us to give feedback but you don't finish the loop.

 

Some idea are mark as new for many years now...

To change the adapter settings every time instead of traversing from configure tools menu it would be extremely convienent to launch the adapter  configuration dialog box by just  double clicking on its icon available in the insertion palette.

 

Present implementation :

Left single click on icon sets it as the active adapter. (Requires 4 clicks)

New request :

Double click this to launch the adapter configuration dialog box.(Requires one double click)

 

 

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.

When choosing a VI for a step, if you browse into a PPL, the view shows the directory structure inside of the PPL.  A better view would match what LabVIEW shows: the Virtual Folder layout.

 

I tend to keep my library VIs in a flat directory structure, but organize them in my project with Virtual Folders.  But the PPL view in TestStand just shows the single directory instead of the nice organization that I set up in the project.

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

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.

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)