NI TestStand Idea Exchange

Post an idea

Professional Development package should include source code control (SCC) and Requirements Gateway right out of the box.

I know that bundled SCC was a problem in the past that NI wants to avoid, but I feel that a "Professional" development system isn't very professional without it and Requirements Gateway. However, It is very difficult and painful for me to get separate funds approved for important items that really needs to be already there right out of the box.

I already use free SVN, but TestStand does not recognize it, so it is not "integrated".

Eugene

View All (4)

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)

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.

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)

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://zone.ni.com/reference/en-XX/help/370052AA-01/tsref/infotopics/deploymentutility_distfilestab_instdestopt/

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.

The TestStand search directories dialog appears to add and remove items by adding or removing entries to and from the TestExec.ini file directly. This poses a problem because it isn't using the TestStand API to manipulate search directories. This results in a difference in behavior between the API and the dialog. In the case of the dialog, you can add search directory entries that don't exist (invalid paths) but with the API, you can't do so. It would be really nice if either:

1. The search directory dialog used the TestStand API for adding and removing entries (so that there isn't a discrepancy in behavior)

2. The TestStand API allowed addition of non-existent (invalid) search directory paths

It is convenient for me to have search directory entries that are invalid so that my deployments will run on either Windows 7 or Windows XP rather than having to create a separate deployment for each operating system. You can obviously do that through the TestStand search directories dialog. However, that is not possible if you attempt to do it programmatically through the TestStand API.

In addition to using the search directories dialog, I also have a utility that can be used to programmatically modify the search directory entries. Because the TestStand API throws errors if you try to add a search directory entry that is an invalid path, the utility often ends up modifying more than the user-requested changes (by being forced to remove invalid paths that were configured previously through the search directories dialog).

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Professional Development package should include source code control (SCC) and Requirements Gateway

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

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

TestStand Deployment Utility: Clear ReloadLastWorkspaceAtStartup option

File installation destinations should be the same as the default installation base directories in the TestStand Deployment Utility

TestStand search directories dialog should use TestStand API when adding/removing items rather than adding/removing entries to/from TestExec.ini file