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

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.

 

When LV throws an error, it's all very easy to catch via callback and/or is auto propigated through the system to Runstate.SequenceError etc.so it can be detected.

 

When LV throws a warning... the data doesn't seem to go much of anywhere in TS... and unlike LV it doesn't propigate from step to step either.

 

I'd like to catch and log these warnings in my error handlers (naturally with different logic, but I don't want to lose the data either, it's important sometimes!)

 

from poking around, it looks like my options are:

(1) creating a custom steptype wrapper around all LabVIEW step calls,

(2) editing each VI called by TS manually

(3) some fun expression(s) in the 'add additional result' or 'post expressions' sectionsof each LV step, to create new variables in TS on the fly...  (or using a post-step callback to do the same)

 

It would be nice if the LV adapter / LV steptypes had some native way of catching this 'almost error' behavior and getting it into the report at least. I don't know if leaning on the error callback is the right answer, since, afterall, these aren't errors... but having a warning callback feels too LV specific...

 

How about a checkbox in the LV adapter, where you could specify 'treat warnings like errors' and then in the Error callback you could check to see if the bool was false, and punt as desired?

 

Is there something I'm not seeing that would be a better solution?

 

--Elaine R.

 

Hi,

 

As in subject.

 

It would be good if TS would have an adapter which takls with WebServices.

 

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

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.

 

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.

It would be nice to see a Help Button on the .NET Adapter that allows developers to see the help for methods they're choosing similar to the help for the ActiveX Adatper.

 

ActiveX Adapter with help.JPG

 

NET Adapter without help.JPG

support capture of std output and std error to variables while displaying normal 'dos' window

maybe by integrating duplication or cloning of the std output and std error streams, like the tee function provides in unix

 

**Added 4/19/2010**

It is nice to have a dos window visible while running executables that take a while to complete.

Often it is important to capture output from executable for parsing.

Currently, if you assign output to a variable, the dos window is not visible.

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

 

 

The current interface for DLLs does not nicely accommodate C++ classes.  For instance, there is no inherent mechanism for passing in and out of DLL calls the reference to an instance of a class.

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.

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 

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