NI TestStand Idea Exchange

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

Several Customers may benefit from a tool that can be able to migrate TS2017 Custom Python step type to TS2019 built-In python step type.

Some TS sequnces may have hundreds of sequences and test steps that required a lot of work for the migration.

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

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

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)

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

 

If I call a python function within the TestStand Python adapter the arguments for the functions must be according the order of the function which isn't Python like. This means the order of the arguments in TestStand must be exactly the same as in the Python function, the name of the argument is ignored.
It would be really nice if the TestStand Python adapter would support Keyword Arguments as well.

https://www.scaler.com/topics/python/types-of-function-arguments-in-python/

keyword_arguments4.png

The fact that TestStand has now a Python adapter is just amazing.
One thing I'm currently missing is the dict or json datatype which can be used to transfer bigger property data between the python script and TS.
Currently tuple is supported but is limited especially if you have a array property with container in it.

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.

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