NI TestStand Idea Exchange

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

The usual Insert Step menu in TestStand:

suggestion1.png

 

What the menu might look like with a Insert VISA step:

suggestion2.png

 

A VISA>>Write step would replace a LabVIEW Action Step such as the one I used below for direct Instrument control from TestStand. Queries would look similar and be able to set limits on the returned value.

suggestion3.png

 

LabVIEW VI for the power supply command to the VISA instrument setup from M&A Explorer.

suggestion4.png

 

This is “PS1” in Measurement and Automation Explorer uses Alias Name.

suggestion5.png

 

Example of Query instrument to an Agilent 34970A using Alias Name “DM1” setup in MAX.

suggestion6.png

 

However, a little more complicated than a single string command from the menu. Might take several Write steps first.

suggestion7.png

 

Possible Uses:

  1. Debugging
  2. Instrument control without additional software or programming languages.
  3. Ability to immediately add new instruments and modify existing sequences without an instrument driver. Demonstrates the quickest possible way to gain instrument control with the least effort (for simple systems).
  4. Simple test sequences can be written right away making it easier for technicians or engineers to write tests.
  5. VISA sequence steps can be dragged to the palette and easily re-used.
    suggestion8.png 

This may be a combo of LV and TS ideas exchanges but it affects TS mostly from my current experience. Issue occurred in LV 2022 called from TS2023. Hopefully already fixed but I know it also existed in LV2016 and TS 2016.

 

The issue is explained nicely in this forum post.

https://forums.ni.com/t5/LabVIEW/Packed-library-contains-folder-structure/td-p/3587329

 

Suggestion is to ignore the OS based heirarchy when selecting a VI in TS and to only use the virtual folder/library structure for selection of VIs to use. This will avoid all sorts of issues of paths changing on rebuild which we've just spent hours debugging.

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.

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