NI TestStand Idea Exchange

Community Browser
About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

 

 
 

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.

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?

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.

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

 

When opening a LVOOP dynamic dispach VI in LabVIEW it will present us a 'Choose Implementation' dialog box. Can this dialog box also be presented when the Edit VI.. button is beïng clicked in TestStand? And when the user dubble click the LabVIEW action step?

 

ChooseLVOOP.png

 

 

Please make possible to select LV Development System version in similar way as it is possible to select Run-Time Engine.

It also should be available in TS API.

 

That will allow Test Engineers to use code modules (especially those inside .lvlibps) from different versions.

It would be also useful for to set up desired version of LV for code modules without lack of debugging options of Run-Time Engine calls.

 

Currently there is only the "Create type from struct" button available, when there is an parameter, that requires an array of structs, in a .NET call

2016-07-13_15-53-49.png

 

What would be nice, is to have the features available, that are available when passing clusters to labview:

2016-07-13_15-58-35.png

 

That is: 

  • The Add Array Item button
  • The Delete/Delete All Item buttons
  • The feature of 'uncollapsing' a struct and setting the values for each field in the struct.

 

 

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

It would be very useful to be abe to specify a custom project or workspace when creating a new test using the LabWindows/CVI adapter. 

 

This would allow developers to always ensure that  any custom macros and source files are always included during development

 

 

 

 

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:

 

Untitled.png

 

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

Hello,

 

When you use LabVIEW action steps, using enum as parameters, the enum update will generate your step to require a reload.

 

This behaviour is OK when current enum values are updated .... and the steps use the modified values !

But when adding a new enum value to the enum, the reload should not be automatic.

 

=> This behaviour doesn't happend with rings ... 

 

Please make the enums works like rings for the LabVIEW actions steps reload !

 

Thanks a lot.

 

Manu.

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.

 

 

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.

 

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)

 

 

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.

This would be a useful feature to recover from a unreposive code module. Particularly useful, if the code module communicates with the firmware inside the DUT which could become unresponsive due to unforeseen erronous conditions.

 

This option should be optiional. It should be configurable with different timeout values. Once set and configured, then TestStand shall stop executing the code module, return from it and generate an error.

It would be really nice to be able to call LabVIEW functions (primitives) directly from TestStand steps instead of having to create and call wrapper VIs for them.