NI TestStand Idea Exchange

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

Hi,

 

I'd like to propose that the FileDiff.exe in the merge mode shall have the possibility of changing the file name labels.

 

Right now FileDiff.exe tool in merge mode has four fixed file name labels:

 

1. Base

2. File 1

3. File 2

4. Merged

 

The names of the labels 1. & 4. are allright. But for someone who uses version controll tool names 2. and 3. could be confusing. I'm not quite sure about the is there one template of  the order in these three-way-diff tools but as I use SVN I'd like to have:

 

1. Base

2. Mine

3. Theirs

4. Merged

 

Having this I'd have the same nomenclature which I have in SVN/TortoiseSVN, and it would't create a confusion.

 

merge proposal.png

 

 

To restore a Teststand perspective to its original layout.

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

Hi!

 

I was working on a project which required LabVIEW 2011 and TestStand 2010. The software had lots of LV modules already created. I reused some of them. However, I needed to trim whitespaces in TestStand which were coming from the string outputs of these LV modules. Nevertheless, I was surprised to discover that there is no TRIM string function in TestStand at all. I had to create a simple VI which just trimmed the whitespaces. I couldn't modify the previously created modules because they were used elsewhere and could affect the outcome of the other test systems. Why does TestStand lack this simple functionality?

 

Regards,

 

L_A_B

 

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

 

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 ; )

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.

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.

 

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.

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.

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

 

obsoleteAnalysis.png

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.

I haven't been able to figure out how to use the cmd prompt to query which TS version is active. Is this possible? if not, it would be nice to have.

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 ! Smiley Frustrated What can i do for my customer hundred of sequenceFiles .... Smiley Sad

 

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. 

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.

Currently, the Installation Destination 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

 

Create option to print selected components (Script, variables, Step Settings etc) this would be useful on several levels, it would make tracing thru long scripts easier, would provide a quick means of providing feedback on errors and other situations which lend themselves to having more than a single screen of information available concurrently.

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. 

 

exports2.JPG

 

exports1.JPG

 

 

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 nice to add these features to the XML Packaging Utility:

1. Allow the changing of the stylesheet.  Currently the utility packs the XML with the specified stylsheet within the XML;  in some cases I'd like to define a different stylesheet for distributions.  This would also allow distributing reports if the specified stylesheet within the XML is not found.

2. Allow an option to have the "packed" files maintain the "Date modified" file properties.  I quite often use Windows to sort a folder of reports on the date modified attribute.  After packing, that info is lost.

3. Incorporate a zip file as an output