From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand Idea Exchange

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

Hello,

 

In current TestStand version (2012), it is possible to view the list of enum values of dotNet adapters parameters.

 

This is great ....

 

But it should be nice to add the enum corresponding numeric value in the dropdown list.

 

This could be helpfull if you had to create a numeric TestStand variable to map to the enum parameter ... and because there are no correspinding enums in TesStand !

 

Thank for help.

 

enum 1.png => Better enum 2.png

 

Manu.

 

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.

 

The menu to create a new variable (right click on variable in an expression edit control and select Create "VariableName") contains all the data types you can use for the variable, however, in the LabVIEW Panel (and other similar panels or dialogs) there is enough context information about the variable to suggest a data type, for example, if the variable is in a control of type Double we know we should create a Numeric variable. TestStand should add the contextual suggestions to the top of the context menu and bold them so that I can more quickly select the data type I want most of the times, then have a separator and put the normal menu so if I don't want that data type for some reason I can still choose the other data types (see attached image).

LabVIEW recognizes any cluster of <Bool, I32, String> as an error cluster.  TestStand should recognize this as well and default any such cluster output to Step.Result.Error.

 

With the addition of the Silver controls in LabVIEW 2012 "error out" was changed to follow the style guide recommended naming convention of leading caps and is now labled "Error Out"  which is not intercepted and assigned to step.result.error.

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.

I am a new user of TestStand for about 6 months or so. Please pardon me if this post is duplicate ... I did a basic search to make sure it wasn't.

 

Test Stand is able to load a cluster from LabVIEW and show its elements, very cool.

It might be awesome if a Container in TestStand can be loaded into LabVIEW that'd do the same.

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.

 

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.

 

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.

 

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.

(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

 

 

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