NI TestStand Idea Exchange

The Sequence File Documentation Tool allows you to create documentation in the file formats HTML and text.

It would be nice if it could also create XML based documentation similar to report generation. Selecting a style sheet will ensure that the XML file is presented in a certain way using a browser.

Norbert

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use. 

This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments 

It would be great to have the ability to create an independent TestStand configuration that is valid in a workspace context. That would allow project specific search directories, StationGlobals an several other configuration items you normally don't want to share across projects on the same test station.

Almost all of our analog measurements are specified in %: example

a Power Supply DMM measurement limit is 24.00Vdc +/- 5%

We typically have 100+ measurements like this in a project

Why not include it in the default step types as an optional selection?

I sure would use it, so would my team.

I agree that it should not alter existing programs using the default step, but I believe that this feature should have been in Teststand when it was first released.

I have run across this in both analog measurements, and the results from an ADC

Think a limit of 0x234 +3%, -7%

How cool would it be to sequence any LabVIEW VI in TestStand? I realize one could make a wrapper around any VI, but that adds not only a layer of complexity, but customization. I am a staunch follower of the KISS philosophy, and custom wrappers are not so simple; well, at least not as simple as no wrapper at all ; )

Under Station Options, Preferences, add selector for error logging to:

None

Client SequenceFile Directory

Specific directory

check box for: one file for each error

check boxes for parameters to log:

error time

error code

error message

sequence file

sequence

step

step action

MySocketIndex

Often customers unknowingly use debug DLL and this results in reduction of the test time.

Sequence analyzer tool should give a warning if it detects that the dll used is not a released one.

I know that I can write my own sequence analyzer tasks, but I think this one should be default out-of-the-box from NI:

Add a sequence analyzer warning task that checks for usage of obsolete methods / properties / events.  This way we can use sequence analyzer to help find them and make our code easier to upgrade with future versions of TS

Otherwise, trying to find all the obsolete "stuff" is REALLY REALLY annoying -- a lot of searching

It would be nice when entering in the Find: control to beable to pop open the Variable dialog (as in the expression editor) to select variable names. It could be linked to the Limit Search to: control. Like wise on the Replace control when that window appears. 

I know you have that drop down facility on this control but that only remembers what you have previously entered.

It would be nice to be able to create a new sequence from highlighting steps in a sequence and performing a right mouse click, "Create New Sequence...", this would be a kin to Create SubVI in LabVIEW.

This action could display a dialog to give possible options such as, to copy the Setup and/or Cleanup group, Create in a New SequenceFile or in Current SequenceFile, the option to Move or Copy highlighted Steps. It could also include creating any locals and /or  FileGlobals (if creating in a new SequenceFile) used by those highlight steps.

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.

Currently, the Installation Destionation options are as follows: 

There is no way to install files to the root directory, or its subdirectories, with the exception of those already present in the Installation Destination. For instance, make it possible to install a file to the following directory: C:\ProgramData\IVI Foundation\IVI

When you are running an execution and you want to check if a step will execute or not depending on the precondition you have to go to the step, browse to the precondition, copy it and paste it in the Watch View...

Wouldn't it be great if you could add your step precondition the the watch view with a single click (like VS "Add Watch")... ideally I'd have another entry in the menu below called "Debug" ot "Watch View" with submenu-items: "Add Precondition to Watch View", "Add Pre-expression to Watch View", "Add Pre-expression to Watch View"

Vote for me!!!

<<- N --.>

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.

The output messages are a good way of sending status messages from the test solution to the end user.  However the control is not available as one of the controls that can be added to user interfaces.

Can this control be made available to be quickly added to a UI and linked to the execution view manager.

Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms.  If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5).  If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.

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 :

1. Select a path which contains recursively many sequences
2. Select a or multiple CustomSteps to upgrade
3. 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.

NI has gone through a lot work to get the IVI Components integrated within TestStand as step types. I was wondering why NI has not incorporated the NI-DAQmx technology into TestStand as step types. I realize most TestStand developers would just create TestStand Adapters in the sequence step written in CVI or LV to interface to NI-DAQmx functions. Even the more advanced TestStand Developers would create their own custom step types to interface to NIDAQmx. I have just done that to where I have created a framework of custom DAQmx step types that I use as a small subset from all the NIDAQmx functions used from the NI-DAQmx library. 

Why restrict to load the type pallets always from <user or NI>…Components\TypePalettes folder?

It will be very helpful I can configure my path to the load my custom type pallets, this will resolve the issue handling different type Palettes for different customers / projects / sequences.

Or even better, if given the option to associate the type pallet to sequence files / sequence model. Just like Edit -> Sequence File Properties -> Model Option -> Require specific model.