NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

Hello,

With the strongest possible emphasis I would like to propose the following new command line arguments for the ORPU. These are desperately needed.

/minimized Launch ORPU truly minimized without having it steal window focus.
/no-splash Launch ORPU without splash screen
/silent Launch ORPU in the tray, without a splash screen and without having it steal window focus.

This is a profoundly useful tool and we are adopting it on dozens of stations around the world... but not having these improvements is really frustrating for operators and these improvements appear to be low hanging fruit. No thanks, I don't want to recompile the ORPU for several very good reasons.

Please help us out by carefully considering the daily use cases for this tool.

References:

https://forums.ni.com/t5/NI-TestStand/How-do-I-get-the-TestStand-Splash-Screen-to-not-appear-when-I/m-p/3120481

https://www.ni.com/docs/en-US/bundle/teststand-api-reference/page/tsref/using-command-line-arguments-with-the-offline.html

Feature request 523524

View All (7)

View All (2)

When developing custom TS sequence analyzer methods, it would be beneficial to be able to control how the message gets reported. Specifically sometimes I would like to automatically add the message into the "ignored" list.

Reasoning -- I have determined that there is a problem with the code, but based on other stuff I think the user really intended and needs the code written this way, so I still want to flag that I found it, but have it in the ignores list so that the user won't by default see the reported message, but if they go to the ignored list they can see it.

Example: If I were doing the #NoValidation directive from scratch, I would have written the rule such that if the "expression validates correctly" rule would check the expression validity regardless of any #NoValidation directives. Then it would report the message (assuming it has a validation error). If the expression contained #NoValidation it would be automatically put into the "ignore" list. This way we have the ability to see that the expression did not validate properly, but recognize that the user has included a flag in their code to specify "this is OK and I want to ignore it" so it goes into the ignored list. -- All done automatically by the analyzer code module without the user having to manually click on the ignore menu item in the Analysis Results window.

View All (4)

The behavior of the TestStand - End Modal Dialog.vi should be changed. The current behavior is for it to not execute if an error occurred before it runs. Instead, it should always execute, even if an error occurred before it runs. With the current behavior, if an error gets passed to the VI, it can cause TestStand to hang. In general, close or end functions and VIs should always execute even if an error occurred before they run because unintended consequences such as errors, crashes, or hangs can happen if they don't execute. Yes, you can use the Clear Errors.vi before the TestStand - End Modal Dialog.vi and Merge Errors function to work around this behavior, but it would eliminate the need to do this if the behavior of the VI were changed.

In every TS step we have the looping feature. I find it very elegant feature which allows us to save implementing full loops for singular steps.

I wonder if some statistical information to the looping feature can be added to the looping feature.

We could image that there is a step with the i.e. LV module which is responsible for acquiring one sample of data. Let say the sampled signal is noisy. It would be fantastic if we can use this singular step which acquire singular sample and the looping feature of the TS step to get multiple samples and to have a statistic the samples taken. The statistic could be:

--averaging

--mediana

--standard deviation

--etc...

View All (5)

Save in Previous Version

TestStand can save a sequence file in previous versions but that option is not very evident. Currently when you go to File >> Save As, the option to chose from is "Files of Type". I propose that a change to "Save in Version" or something to that effect be implemented. This change will make things a lot clearer for the user as it will be self explanatory. Another option will be to make it its own menu item under file>>. I hope see this in future versions of TestStand.

I think it would be a cool idea to put an extra configuration entry point in the Sequential Model (or all the shipped process models) by default. Inside of it would be a simple call to an empty callback. This way users can override the callback to get custom sequence file configuration setting.

This would be useful for storing info like: DAQmx addresses, GPIB addresses, etc... off to a file. Sorta like machine specific configuration info. That way during execution the file can be read in and used. However, if it's empty then people can use it for whatever they want.

I understand that I can go in there and edit the process model and make my own but it would be nice to just have the default already there.

You could call it Sequence File Configuration or something.

VISA Step Insert for TestStand

The usual Insert Step menu in TestStand:

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

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.

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

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

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

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

Possible Uses:

Debugging
Instrument control without additional software or programming languages.
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).
Simple test sequences can be written right away making it easier for technicians or engineers to write tests.
VISA sequence steps can be dragged to the palette and easily re-used.

A TestStand configuration wizard

I would like to see a TestStand configuration wizard that would walk a developer through a checklist of all of the most important configuration settings and generate recommended changes.

It is best for a developer to be already familiar with Best Practices as in the following link:

Best Practices for Improving NI TestStand System Performance

http://zone.ni.com/devzone/cda/tut/p/id/7559

However, it would also be nice to have assistance in recording WHY certain choices are made as shown in this image:

Eugene

View All (3)

As someone whom regularly maintains custom process models for my team, there are times when I wish to harvest data from 'any MainSequence run' without requiring my individual developers to remember to set specific custom-parameters or 'runstate.root.* or Locals.ResultList[] values within their test programs correctly every time.

It would be great if there were hooks, beyond simple parameter passing, that could allow me to dynamically 'reach in' to active execution context of MainSequence ideally 1x at start and end of MainSequence execution (i.e. just after context fabrication, and just before context garbage collection).

In this way, I could use API to monitor data that usually gets garbage collected before the model can 'see' it.

i.e. if I see they have a local variable in their test, Locals.Debugging_Active == true, perhaps I could catch that at the framework level, and update the report header to say 'possibly not production data!', even if developer forgot to correctly set the 'is Validation Data' flag that is formally available.

In an ideal world we would have strict process & TS style rules to enforce that all developers must set key variables as part of their executions, but also having a scrappy way to catch test-internal context issues within process model (even if this does break the paradigm of immediately garbage collecting sequence specific internal data) would be a great fall-back strategy for teams where they have 1 or 2 test experts and a much larger pool of non-expert test developers using TestStand.

View All (2)

My team uses Analyzer Rules to enforce best practices for developers across sequence files and workspaces with great results. However we would love to be able to also provide rule checking and warnings for developers on some basic *.tsd file content such as Installer Name field, and build-path & installation-path/image-path, etc... New (or rusty!) developers often miss steps in their configuration and needlessly struggle with badly behaving deployments.

As TSD files do not appear to have an API available from TestStand at this time nor conform to a json/xml syntax internally, for easy parsing via 3rd party tools, some method(s) for 'reading' file (or converting to readable syntax) may also be required in order to build rules effectively?

Background

Under the Installer Options tab, there is a button called Advanced Options.... (help linked)and then a section for TestStand Specific Settings. This section allows a user to specify where the configuration files will be located when running the TestStand runtime engine on a deployment machine. See screenshot of help discription and then of the utility below:

Help

TestStand specific settings.PNG

Screenshot of Deployment Utility Section

Deployment Utility Advanced Options.png

Recommended Change to Documentation

When looking at the help documentation, it does not detail what each of the possible destination directories are pointing to. However, if we move to the Distribution Files tab section of the help, there is a detailed list. See this example link here https://www.ni.com/docs/en-US/bundle/teststand-api-reference/page/tsref/installation-destination-options-distributed.html

I recommend making a quick link to this same page to clarify the directories that can be specified for Cfg files.

View All (3)

Hi all,

Based on a lot of experimentation, there is no way at run-time to map a logical name to a VISA descriptor in the Session Manager API.

...at least not without adding an entry to NISessionMgr.ini.

[VISA Logical Names]
LittleOldComPort = "ASRL1::INSTR"

If I don't do this I can't open an instrument session. I'd still like to use the session manager, but use an external method to map my logical names. (e.g. a database, XML, or something a little less obscure than an .ini file buried in program files)

If the Session Manager is still a supported product, is it possible to add a method to add a logical names for VISA descriptors without using the INI file?

If there's already a way to do this, please excuse my ignorance.

Thanks as always,

Mr. Jim

Hi All, My code module to be deployed uses some VI's from user.lib. When I'm trying to create the deployment, in LabVIEW options I'm excluding all files from vi.lib,user.lib and instr.lib. After creating the deployment, still my code module looks for the VI's from user.lib in SupportVIs folder which is parallel to the deployed folder. I don't know why it is still looking in SupportVIs folder instead of taking it from user.lib. Please share your thoughts about this.

Thanks in advance!

Regards,

vani

For one of our test racks we have a PXI Rack that is full of Measurement HW devices from NI. Recently tow of the cards in the rack were returned to us from the calibration house with OOT (Out of Tolerance) as found readings. This put into question the product tested and shipped in the past year. Since the test fixture is used to test 14 different assemblies, I wanted to use Teststand to generate a report that told me what hardware was being utilized during the sequence of each assembly that is tested on this fixture. It appears that unless one intentionally adds certain system configuration information into the VI that can be read in as a variable in Teststand, that this process will be very tedious in looking at each vi called out by the sequence file and looking for HW callouts. It would be great to have this capability baked into the handshaking between VI's and Teststand to allow for a simple query within TestStand. c.S.

NI TestStand Idea Exchange

Offline Results Processing Utility: Command line arguments for Improved UI Behavior

NameOf() has the option to return the entire name

automatically add TS analyzer messages to ignore list

Quick switch between the release and debug dll

TestStand - End Modal Dialog.vi should execute even if an error occurred before it runs

Feature request: statistical information when looping the step

Save in Previous Version

Spare Configuration Entry Point in Default Process Model

VISA Step Insert for TestStand

A TestStand configuration wizard

Allow ProcessModel to obtain/retain MainSequence context before & after Call MainSequence step

Add some Maths functions for array: mean, variance, standard deviation...

Ability to write Analyzer Rules around content of TestStand Deployment Files (*.tsd)

Add link in TestStand Deployment Utility Help For Clarity

[Sequence Analyzer] 'Export Items to File Dialog' Should Have Common Toolbar Commands

Save As Previous Version for Deployment Utility

Session Manager: Add VISA Logical Names at Run-Time Without INI File Entries

TestStand Deployment Utility: Support VIs issue

HW query capability in Sequence File

Add an Operator /Function to convert values(Numeric,string etc) to dotnet object and viceversa