NI TestStand Idea Exchange

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

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. 

 

* Why not include Configuration files, such as TestExec.ini by default in Deployment Utility?

 

* Also using default settings, nothing appears in the Start Menu/All Programs menu on the target machine. Why not have the main sequence file to be installed so that it appears in the Start Menu/All Programs menu on the target machine?

 

 

Eugene

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.

Recently I have been involved in 2 Projects which deployed the test solution to PCs with disconnected deploy licenses

On both projects it was very labour intensive, there were some strange failures that were seen , related to the different licences and which were only highlighted when running with LVRTE and Teststand base deployment license. On each occasion it felt that even though the development machine had proven the solution it still required significant effort to prove and integrate the deployment image 

 

My suggestion is to allow the developer to configure their development PC NI licence manager to replicate the PC that will run the deployment.

The Development machine would obviously need to have the development suite licences, all child licences related to the development licence would be available in the NI Licence manager . The developer would then have the option, to configure the licence manager to use the desired licenses. Ie TestStand Base deployment & switch executive deployment.

 

With a TestStand solution on a development machine the deployed image could then be tested before its deployed to its destination PC

ie.

1.The adaptor settings can be changed for the code modules to Run Time

2.The TestStand Search directories can be configured to use the deployment target image

3.And the licencing could be changed to replicate the deployment PC 

 

Realise that points 1 & 2 above should iron out most of the issues with the deployment licence and its mainly on new deploys that the integration is painful, but having the option to select the licence to test on the development PC will help a lot to speed up the integration.

 

 

      

See Also

Simulated Devices in LabVIEW projects

Project and Workspace Context in MAX

 

Link to those ideas in next post

 

We can already create tasks, channels and scales in a LabVIEW project but, We cannot then use MAX to run those Tasks and we must use MAX to create a simulated device on a development machine.  After a few projects the Max configuration becomes cluttered.  Deployment and importing of the hardware configuration can get problematic to say the least! 

 

On the other hand- if the Hardware, Data neighborhood and IVI session set-ups could be added to the workspace, deployment would be a snap! just import the *.nce from the workspace without having to create one from MAX and exclude items not concerned for the deployment.

 

For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by deployment in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.

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.

Often, multiple sequence files are deployed on the same test computer.  A convenient way of differentiating between them is by changing their icons.  Although this can be accomplished through custom commands invoking VBScript, it would be nice if the TestStand Deployment Utility provided native support for customizing the icon of a deployed sequence file.

We work with Teststand and Visual Studio 2012.

We would like to have an option to switch between the use of the debug dll or the release dll.

Now we have to change this step by step and that's a lot of work.

When deploying from a workspace file, TestStand analyses the VIs it has to include in the deployment package. However, when working with plug-in classes, TestStand will add the parent of a plug-in class, but not its children. Possibly because these are not directly used (they are included at runtime), and thus not recognised during analysis.

 

I would like to see that TestStand recognises a parent class it includes in the deployment, and then:

  • includes all its child classes that are in the same project file;
  • asks to include possible child classes that are not in the project file.

Even though we already have an About box for TestStand, it would also be nice to have one for the active TestSequence file as well. The Help menu would have a new item called "About MySequenceFile ...".

 

MySequenceFile About box splash screen:

19679i37712516107E8A41

 

The information in this screen should be loaded directly from a single FileGlobal string whenever a sequence file is made active. This can probably be done already by those that know how, but it should be already part of TestStand by default.

 

 

Eugene

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?

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

 

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.

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.

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

 

 

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.

 

It would be a big convenience if, when you are configuring a TestStand Deployment, the Workspace automatically populated with the current workspace that was open when you try to deploy.  While not a major inconvenience, it is somewhat of a hassle to go and select the same file every time, especially if you are making small changes to test a system.

 

image.png

There is often problems with cross-linking the wrong LabVIEW VI code modules. Why not automatically import VIs into TestStand from LabVIEW projects using the name of the LV project as a name extension for each VI in TestStand?

 

For example, if the name of the LV project is "Project 1.lvproj" and contains VIs named A.vi and B.VI, then these could easily be loaded into testStand as "A-Project 1.vi" and "B-Project 1.vi"?

 

 

Eugene