NI TestStand Idea Exchange

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

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?

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.

 

Adding the same option as installer advanced options to lock the Labview Packaged Library Version to the Deployment file Version

 

hugo_fr_0-1647943596741.png

 

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

 

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.

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

All the major IDEs I use (LabVIEW, LabWindows/CVI, Visual Studio, etc.) support specifying post build actions as a part of the deployment.

 

TestStand does not.

 

Since the TestStand Deployment Utility (at least as of TestStand 2019) does not implement any kind of signing implementation, I'm resorting to manually signing my installers with my official signing certificate after the fact.

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?

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.

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.

Hi,

 

Several years that I'm facing this issue : I'd love to be able to rename a file when building my TestStand project image.

It would be particularly nice to ease the installation of a Type Palette thanks to this feature (taken from TS help):

 

TestStand also searches the TypePalettes directory for type palette files with the Install_ prefix. When TestStand finds a type palette file to install with a base filename that is not the same as any existing type palette file, TestStand removes the Install_prefix and adds the type palette to the type palette list. When TestStand finds a type palette file to install with a base filename that matches an existing type palette, TestStand merges the types from the install file into the existing type palette file and deletes the install file. This method is better than modifying the existing type palette file because this method is more modular and flexible for deployment and updates.

 

So, in my project I made a type palette file xxx.ini. When deploying this file, I'd love to rename it Install_xxx.ini so TS can install/merge it on the destination computer !

This is just an example of the use case, it could be applied to any file within my deployement image.

I am a AE here in the UK. Just had a customer with TestStand.

 

He was given a project to do in TestStand that was estimated 5 days to develop, but his managers told him to add another 5 days on just for deployment of the system, mainly because they have issues deploying the system.

 

The problem was including a DLL in the Workspace. Of course this is very easy to do, but they were expecting that it would automatically add the DLL to the workspace when in the sequence they were calling it, given how powerful TestStand is. 

 

Would it be wise to add this small feature into TestStand to smoothen out the process of deployment for newer customers?

 

It looks like it's a widerspread issue due to the fact that the manager would recommend 5 days for deployment due to experiences with previous projects. I understand to those who have used TestStand before may think it is not much to just add the DLL into the workspace, however adding an auto include feature would be nice and could even save newer engineers time.

 

In addition, he suggested including .NET and C++ installers because most of the Engineers he knows use these instead of LabVIEW.

 

Let me know what you think of this Idea.

 

Daniel

 

 

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

There is a major flaw with packed project libraries in LabVIEW.  That is that they pull the dependencies in to the same folder as the PPL.  For example if you use advanced math functions then lvanlys.dll will be put in the directory.  The problem is that LabVIEW doesn't like it when you try to load multiple files with the same name.  So if I have a test system with multiple ppls that use the same dependencies I could potentially run into collisions.  There is a document here that discusses a solution for this:

https://forums.ni.com/t5/LabVIEW-Development-Best/Packed-Project-Library-Pitfalls/ta-p/3523762

 

I would like to see the option to prefix my dependencies for PPLs.  This could easily be added to the Packed Project Library Options dialog. 

It would be great to have an option in the TestStand Deployment Utility to clear the ReloadLastWorkspaceAtStartup flag in the TestExec.ini file when making a deployment.  

 

I usually keep the flag set to save a step when developing code, but when I'm getting to the stage where I need to deploy to continue development and testing, not having this cleared results in an error that pops up on every first launch after installation.  

When running teststand deployment licence there is no Teststand GUI available to set or configure Results Processing.

I think it should be easy to export the active configuration to file. And then have a property loader type step to load the settings back into the sequence at runtime on the deployed machine. Note in my case I want to run different sequences with different reporting requirements on the same deployment PC.


I have found https://decibel.ni.com/content/docs/DOC-32076
and after more stuffing around than was justified I have got it working with TestStand 2014.

 

Export.png

 

 

Also it should be much easier to specify a relative UDL file. 

UDL.png

 

 

I resolved this by adding an expression after ReadEx that was:

Parameters.ModelPlugin.PluginSpecific.Options.ConnectionString="\"FILE NAME="+Left(RunState.SequenceFile.Path, Find(RunState.SequenceFile.Path, "\\", 0, True, True)) +"\\60467Database.udl\""

 

This means I can select an absolute path to the UDL file in the development directory on my laptop and then use a relative to sequence path in the deployment. 

 

I feel there should be an more obvious way or am I missing something?

The TestStand Deployment Utility lets you select the following locations for the installation destinations of individual files:

 

File Installation Destination.png

 

However, you can select the following for the default installation base directory:

 

Default Installation Base Directory.png

 

It would be really nice if both lists of available installation locations were the same, both in terms of locations and naming conventions.  The most glaring omission in the file installation destination list is the Windows Volume location.

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.