NI TestStand Idea Exchange

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

I think it can a be a really good idea to review and give feedback on all Idea exchange.

 

You ask us to give feedback but you don't finish the loop.

 

Some idea are mark as new for many years now...

It would be nice to have an Auto-populating folder option for TestStand projects much the same way that LabVIEW project do.  

 

Folders added to TestStand projects are snapshots of the folder's contents when added.  Any files added to the folder on disk afterwards are not marked for inclusion with the deployment at analysis time.  This behavior is fine as a default.

 

However, there are times when you do want to automatically include all files in a folder.  Having an auto-populating folder option would mark the folder and all its contents for inclusion automatically with the deployment at analysis time.  After analysis is over the user could still choose to uncheck any files they wish before selecting the build button.

 

From version to version, it's only natural that developers will be adding new files to established folders.  Since the TestStand project doesn't aid in development activities, it's easy for folks to forget to add files while they're developing.  We often have a faulty build or two with each release because necessary files aren't making it into the build.  We ultimately have to delete the folders in the project and re-add them, then go through the hassle of fixing the paths and included files. An auto-populating folder option that integrates with the build utility would save us time and headaches.

 

It isn't uncommon to deploy customized TestStand options, such as search directories, on a deployment computer.  It would be much easier to do this if the search directories in TestStand were stored in their own .ini file rather than in TestExec.ini.  You can obviously set the search directories in TestExec.ini quickly using the built-in search directories GUI, but when distributing the TestExec.ini file to the deployment computer, you have to be careful that none of the other options contained in the file don't inadvertently cause problems when executing TestStand deployments.  A separate .ini file for search directories would clearly remedy this situation.

The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.

 

On many an occasion I've wanted to wrap the following basic functionality:

  • Run a specific sequence file (with or without a [typically custom] process model)
  • Wait for it to complete.
  • Retrieve the result.

It's something I've needed to do in all of the following situations:

  • Integrating into a customer's existing framework
  • Integrating into my own automated test framework
  • Providing a simple API to a customer
  • Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls

The solution I've ended up defaulting to in the past has been some variation on:

  • Start with the full-featured C# UI.
  • Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
  • Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
  • Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.

The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.

Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.

For example:

TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.

With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".

Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.

Thanks!

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 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.

Type Files have a feature to combine files from an install: files prefixed with 'Install_' get merged file existing file (explained here).

 

I am building a ModelPlugin, and I would like it to be enabled and configured in the Result Processing after install (users should intentionally opt out of using the installed plugin instead of opt-in). The settings are saved in ResultProcessing.cfg, and there is no merge feature available. Placing my own ResultProcessing.cfg will remove any previous settings the user had configured (or other plugins). I would like to be able to place a 'Install_ResultProcessing.cfg' that gets merged upon TestStand launch similar to type files.

It is common to want to place a shortcut to a TestStand User Interface or even a TestStand sequence file on the Windows Desktop for each user of a computer.  This is done by placing a shortcut in the Windows All Users Desktop directory.  Currently, the TestStand Deployment Utility only allows you to create a shortcut on the current user's Desktop.  It would be really nice if the TestStand Deployment Utility allowed you to also create shortcuts on the Windows All Users Desktop so that everyone using the computer could see this shortcut on his or her Desktop.

TestStand should use Workspace and Projects properly when determining the folders and files used for deployment.  It should not default to reproducing the on disk source structure for your deployment.

 

  1. I develop in a folder called: C:\Development\ProjectFolder\. 
  2. I create a workspace, a project, and add the ProjectFolder to the project.
  3. I load the workspace into the Deployment Utility.
  4. In the Installer Options tab I set my Default Installation Base Directory to "Windows Volume (C:)"
  5. In the Installer Options tab I set my Default Installation Subdirectory to "ProductionSW"

 

I would expect the Project Folder and its contents to be the ROOT of my deployment placed in the C:\ProductionSW\ folder.  My resulting installer should create C:\ProductionSW\ProjectFolder\

 

However the Distributed File Tree Views show:

View Workspace

  • Workspace.tsw
    • Project.tpj
      • ProjectFolder
        • source Files and Folders

View Source

  • C:
    • Development
      • ProjectFolder
        • source Files and Folders

View Build Preview

  • Installation Directory
    • Development
      • ProjectFolder
        • source Files and Folders

By default when I build the deployment it installs my software at C:\ProductionSW\Development\ProjectFolder\

 

The Development folder is not in the workspace or project.  It is not referenced in any of the source files (as all paths are relative).  I understand why it's in the View Source as that's where it resides on disk.  However, the workspace/project should be used as the basis for the deployment not where things are on disk. 

 

The source starts at ProjectFolder and that is what I expect to be deployed to my Default Installation Base Directory\Default Installation Subdirectory folder.

 

If the workspace and project aren't used to define your project code then what good are they in the Deployment Utility?

Hello,

 

For the moment Localization files are to be placed in TestStand public or TestStand user paths. Smiley Sad

 

It should be interesting to move them in a custom directory, which could be configured in the stations options.

(Or defined somewhere in a TestStand project) Smiley Happy

 

Doing so, would simplify the deployment processus ... and Localization files would not be treated as global files, but project files.

=> When you have to handle with many TestStand project, you could have a directory for each project ... with multiple localizations files different by project !

 

I think the mechanism of file managment of TestStand should be modified, in order ...

 

  • To suppress the global files
  • To manage such a kind of project ... (A workspace) ... containing all the file he need !

Doind so, would simplify the deployment process ... to a simple directory copy ! Smiley Very Happy

 

Thanks.

 

Manu.net

It would be nice to have an auto-incrementation option checkbox (like LabVIEW executable version).

 

And addindg the build index would be even better ...

 

hugo_fr_0-1647942208236.png

 

I know that I can deploy station globals by adding the ini file to my workspace but when deploying them I want the Station Globals to be merged with the existing station globals on the deployed machine.  Please add this as a feature to the deploy utility.

 

The separate compiled code flag is great when using VIs and source code control.

 

However TestStand (2016 SP1) deployment utility builder does not warn if the separate complied code flag is set - This means the VI will not run with the TestStand Deployment Licence without a LabVIEW development system installed. 

 

I do think the the Deployment utility should have a checkbox to force include the compiled code in all VIs and Controls so it can be run easily with the TestStand Deployment licence and LabVIEW runtime engine. 

 

Suggested because I have pulling my hair out wondering why a VI on a deployment machine won't run. 

Turns out a type def control had separate compile code flag set!  I even wrote code to clear this flag on VIs and all subVIs - it never occurred to me to check controls!

 

Also please update the error message in TestStand:

----------------------------------------
Details:

Parameter 'UUTServiceType': -This was a bit of a clue... but the TestStand type matched when I recreated it.
Unable to load VI 'Dialog - Prompt to connect UUT.vi' with the LabVIEW Run-Time Engine version 17.0.
The version of a subVI might not match the version of the run-time engine and the Version Independent Runtime feature is disabled or a VI dependency might be missing.
Try the following steps to troubleshoot the issue:

1. Open the VI in the LabVIEW development system. If the VI is broken, fix any errors in the VI.
2. Force compile the VI by clicking the run arrow while holding the 'Ctrl' key.
3. In LabVIEW, select File >> Save All to ensure that all subVIs are saved in the same LabVIEW version.

4. Check that the separate compiled code flag is not set on the VI or its dependent subVIs and controls (typedefs) when using the LabVIEW Runtime engine. 
----------------------------------------
Error Code:

-17600; Failed to load a required step's associated module.
----------------------------------------
Location:

Step 'Prompt User to Connect UUT' of sequence 'MainSequence' in 'My testsystem.seq'
----------------------------------------

 

{edit1} I also have just realised that running the code with the LabVIEW runtime in adaptor settings worked fine on my development PC as the control's code was in my local object cache. So I was also wondering why it worked fine on my development machine and not on the deployment machine when using the LabVIEW runtime.

Therefore the Runtime adapter should have a setting  to either Disable the Runtime using the local object cache

or an option ot clear the local object cache before running the sequence. This means this issue would have been reproducable on my development machine with the LabVIEW runtime adapter. 

 

I feel this idea is almost is close to being a bug.... 

 

 

 

Download All

Although BuildTSD allows for builds from the command line, they are still not automatable because someone must be logged in for the run to work. All of our other build tools (Visual Studio, Eclipse, MPLAB, Quartus, NIOS, Matlab, etc.) allow for headless, remote, automated builds which support our move toward continuous integration, continuous deployment, and agile development.

There is rudimentary Command Line Interface (CLI) integration in the TestStand Deployment utility.  Its undocumented, and is one flag.  "build".  Which is useful, but the fact that my only option to determine if the build succeeded is manually parse the build output log is cumbersome and error prone.

 

In a world where continuous automation and build automation are becoming daily buzzwords, additions to the CLI are sorely missing.

 

I don't necessarily need to be able to do much from the CLI, but having control and the ability to read back status on a build would be tremendous.

 

https://forums.ni.com/t5/NI-TestStand/Running-the-deployment-utility-from-the-command-line/td-p/1624948

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

 

I have seen multiple customers who have encounter the following error:

 

 

Error: The following VIs or Project Libraries have duplicate names
You must change the names or add them to project libraries:

 

The issue sources from installing a TS deployment onto your development machine. It is not recommended.  And though the deployment will be able to execute, it can also cause undesired linking errors, as shown in these cases. As a result, some of the VIs called are looking to SupportVIs (even in your development sequence), and other VIs called are looking for the same named VI in vi.lib. There can't be two different VIs with the same name, unless they are in two different libraries.

 

I suggest that we implement a warning when such an installation is started or even an error which prohibits installation fo the deployment.

It would be nice to be able to create installers from existing images that were created previously using the TestStand Deployment Utility.  It would also be nice to be able to pause the TestStand Deployment Utility between the image creation and the installer creation.