NI TestStand Idea Exchange

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

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

 

 

 

 

 

 

 

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

 

 

 

 

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.

 

 

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.

Allow the configuration portion of steps that call DLLs to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).