NI TestStand Idea Exchange

Post an idea

This method ensures that the correct test sequence and its corresponding DLL/VI/custom files are run.

This feature needs to be optional as during development phase this feature is not desired.

Configuration :

User selects the test sequence.

User (optional) selects related files like dll/vi/etc

The checksum of the package is determined and tagged with the sequence.

Execution:

User enables the checksum option.

User selects the above sequence to run.

Teststand automatically checks for the sequence checksum and also the checksum of the related files.

The sequence will run only if the checksum matches.

View All (9)

The TestStand Deployment Utility lets you select the TestStand Application Data directory as an installation directory for files. This is great because the installers know how to handle this path which differs between operations systems (such as Windows XP and Windows 7). Unfortunately, there is no similar entry for the TestStand Application Data directory in the list of default TestStand search directories. There really needs to be an equivalent TestStand Application Data directory entry there because it will need to be a search directory required by a deployment that installed files to that location.

Yes, you can add the absolute path to the Application Data directory to the TestStand search directories by hand, but the paths differ from operating system to operating system. This means that if you want to create a deployment that runs on multiple operating systems, you have to manually add search directory entries corresponding to the Application Data directory for each operating system on which you are running, even if they are not used. Then you have to include the modified TestExec.ini with your deployment. If the TestStand default search directories contained an entry corresponding to the Application Data directory and interpreted that entry according to operating system (the same as the TestStand Public Directory entry), that would be fabulous. That way, you could create a single deployment installer that worked on multiple operating systems instead of creating individual installers for different operating systems.

The reason why I am making this suggestion is that I have files in my deployment that need to be written at run-time by my sequence files but the deployment needs to run on a Windows 7 computer without administrator privileges. If you try to write files from an application running under Windows 7 without administrator privileges, you will get access denial errors unless the files are located in all but a few defined paths. The TestStand Application Data and Public directories are examples of those paths.

Also, for the sake of consistency, if the TestStand Deployment Utility allows you to install files to the Application Data directory, the TestStand search directories should also provide support for the same location since search directories determine where to load dependencies.

There are many reasons why TestStand is not my language of choice.... I will start with this one... The TestStand Version Selector needs improvements.

If the users are to base the reliability on the interface, then the TVS needs to be much more reliable. When switching from one version to another, the version selector hangs more often than being able to accompish its task. The TVS just sits there pretending to do something... well... it probably was doing something, decided it was lost and then decided to sit and watch the CPU clock cycles go by...

I usually kill the task and try again... By the 3rd attempt, it will somehow manage to switch versions. These attempts give me enough time to write this idea.. After killing the application, I always get the "Unable to determine the current TestStand version" message. This is usually a good sign as the next attempt will probably be a lucky one.

I decided to search the forum to see if others had issues with TVS, and of course, I was not alone. Se the links below:

http://forums.ni.com/t5/NI-TestStand/Operation-failed-popup-when-using-TestStand-Version-Selector/m-p/2354516/highlight/true#M40275

Josh W is not a novice at TestStand...

http://forums.ni.com/t5/NI-TestStand/Problem-launching-TestStand-2012/m-p/2401666/highlight/true#M40716

http://forums.ni.com/t5/NI-TestStand/Microsoft-Visual-C-run-time-error/m-p/860288/highlight/true#M23219

Just how long is being patient? I have waited more than an hour (during lunch) and it still does not swap versions...

I do realize that most issues are related to microsoft visual studio or visual C++, but TSV needs to tell us what is going on or why it is not able to switch version. After all, once it finally changes versions, TestStand is fine. No changes to the PC or any software installation. So the issue clearly points to TVS.

When you improve the TestStand Version Selector, can you also improve the time it takes to change versions? I realize it's too late to improve the architecture of the language where different version could co-habitate together, like LabVIEW, but at least make it a bit faster..

Now that it has selected the approrpiate version, I shall stop my rant... I mean idea and get back to work.

Hopefully all the people who share the same concern will kudo this idea..

🙂

View All (3)

Imagine the scenario where you have some custom types files and you want to validate those types are in good shape. So you want to run the TestStand "Sequence" Analyzer utlity on them.

To do this, I need to create an arbitrary analyzer project, make sure it is configured to analyze the type palettes, and then run that analyzer project.

If I were doing a 1-off sequence file, I can just open the sequence file and click the Start Analysis button (don't need to create an analyzer project if I just want to accept all the normal defaults). However, if I open the types palette I can't select the types file I am interested in and just hit the Start Analysis button (it's disabled).

I'd love to be able to have the "start Analysis" button enabled and work if I am in the types palette, and have it just analyze the types file I have selected. Or analyze StationGlobals if I am in the station globals window. Or users configuration if I am in the user manager.

I find myself creating arrays alot and I usually have the array already made in excel or note pad or another type of file in which the list might be around 20 or more entries. Now in the past I've come up with a simple way to import the arrayed data from a file, but however i don't believe everyone is doing this and generally I don't need the file in which gets imported (usually a simpler version of the master). So i suggest could we add the support to copy from excel or from notepad and paste special into an array.

Conclusion:

This idea might not be the best, fastest, or easiest way to import arrays from other programs, but the idea would be to find an easy way to import arrays.

Thanks,

I use the Stationglobals.ini to define my hardware settings on the test PC, like comport number and so on. It is running Teststand Base Deployment.

If I want to edit the settings it's only possible if I copy the stationglobals.ini to my development PC which has the full license, edits the settings, and then copies the file back to the test PC. Before I copy the file to my development PC I need to make a backup of the original file, so I don't get the settings on the development PC overwritten. Then afterwards I have to re-establish the backup.

This is a lot of copying back and forth, which is quite annoying.

Please make it possible to edit the Stationglobals.ini directly on the test PC with the Base Deployment Engine.

View All (1)

Did not know where to put this idea since NI Requirements Gateway Tool is not listed anywhere in Idea Labels.

Since IBM is phasing out Rational Requisite Pro (end of life) and replacing it with IBM Requirements Composer, NI should provide capability to interface with at least with IBM Requirements Composer and other current Requirements Management Tools that are commercially available today. NI also should provide some kind of tools that create ATML test descriptions from the Requirements Management Tools or tools like Rhapsody that can automatically generate test sequence files for TestStand.

At our facility, we have a shared Users.ini file on a network that is used by all test systems in our entire organization (somewhere between 150 and 200 systems). It contains hundreds of different users and many different user groups and its contents change frequently. I recently upgraded to a newer version of TestStand and learned that a single Users.ini cannot be used by multiple versions of TestStand; it can only be used by the version of TestStand in which it was created (or saved, when upgrading).

This is problematic because it means I have to maintain multiple Users.ini files for the different versions of TestStand in use at my facility; whenever I need to make a user change, instead of changing it in one location, I have to make the same change in multiple Users.ini files. Because there is a mixture of TestStand versions in use at my facility, it would be really nice if different versions of TestStand were able to use the same Users.ini file.

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

http://zone.ni.com/reference/en-XX/help/370052W-01/tsref/infotopics/offline_processing_utility_command_line/

Feature request 523524

View All (7)

View All (2)

The Update VI Calls tool only works on sequence files right now. I'd like it to also work on Step Types in type palettes.

Here's the situation where it would be useful for me: I'm working on a set of custom step types for a customer, which use VIs as Edit-Substeps and Post-Substeps. Some of these VIs are shared between multiple step types.

The issue that I'm having is that if a customer requests a change to one of these shared VIs (for instance, to add another input or output), then I have to go through and manually update all of the substeps in all of the referencing step types. I've already had a situation where I missed an update of an edit substep. This didn't show up in our automated testing, because it is only run at edit time, but caused an error for the customer which they didn't know how to interpret. Our testing process now has to include manual opening of every single edit substep to make sure they all still work before every release.

As part of my validation before a release to the customer, I run the Update VI Calls tool to make sure that there are no broken VIs in the sequence files I'm shipping. The Update VI calls tool already makes sure that I've updated any step modules, but it doesn't catch if I've forgotten to update a Step Type's substeps.

And yes, I know, I could write my own tool to traverse a type palette and do the updating myself, but I'd like to see this integrated into the existing tool.

View All (5)

Hello,

I had recentlty to modify the public interface of one of my custom step.

The automatic type conflict detection diden't work ! I had to modify all my sequence file manually, by only launch the "reload prototype" !

(All versions of my custom step has been upgraded in order to generate a conflict !)

So, i thaught, i could use the "sequence file converter tool" to upgrade existing sequence files ...

But no !

The sequence file converter only converts the properties which cannot be modified by the final user. (The one who write sequences)

=> The NI Answer is : All properties that could be modified on a step instance, will not be upgraded by the sequence file converter.

So, neither the default action will never be upgraded, nor all properties ....

AIEEEEEEEEEEEEEEEEE ! What can i do for my customer hundred of sequenceFiles ....

So, I had customized my custom step in order to lock all properties for the end user (Disable properties) ...

I thaught the Sequence file converter will detect that the step instances could not be modified ... and then it will do the right work !

Even with this lock, the sequence converter don't upgrade my existing sequences !

The NI answer to my problem is : You should do it right from the begining !

It is well known that the projects need didn't change during the software life cycle !!!!!!

So i decide to do my own sequence file converter for my application ... and it works fine ... but i think this need is general ... and could be integrated into TestStand.

I would like, in the sequenceFileConverter, to be abble to :

Select a path which contains recursively many sequences
Select a or multiple CustomSteps to upgrade
And launch an automatic "Force upgrade"

The tool could ask other options like ...

Keep properties or apply default
Updgrade action interface or not
keep existing parameters, and initialize default parameters with default values
Apply default parameters

I know very well that the behaviour of such a tool would need many parameters in order to handle all needs.

But, this could be done in many times ...

The first need is something like an automatic prototype reload, with existing parameters reusing, and default values for type mismatch, or new parameters.

Thanks for help.

Manu.

View All (4)

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

Adding checksum feature to the TestStand sequence

Sequence Analyzer should detect if a debug dll is used

Add basic file I/O functions to TestStand

TestStand Version Selector: active version query

TestStand Deployment Utility: Have the root directory as an Installation Destination in the Distributed Files tab

Add TestStand application data directory to default list of TestStand search directories.

Improve TestStand version selector

Easier to analyze items that are not sequence files

Copy and Paste from other programs into Arrays

Make it possible to edit Stationglobals from the Teststand Base Deployment License

teststand property search please

Provide error logging

Expand NI Requirements Gateway Tool to interface with latest Requirements Management Tools

Make Users.ini files shareable by different versions of TestStand

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

NameOf() has the option to return the entire name

Make Update VI Calls Tool Work on Type Palettes

Sequence File Validation

Option to load Type pallets from the User defined Path

Smarter Sequence file converter ...