NI TestStand Idea Exchange

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

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

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.

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.

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.

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

 

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