LabView TestStand interoperability with LabView runtime adapter

[Teuch1]

Have learnt something .. always thought that the Labview adaptor didn't use the development suite files with a TS deployment licence.. thanks... 

A couple of links from NI support that helped me when i had similar problems last year

Deploying LabVIEW Code Modules with NI TestStand

Deployed TestStand System Failing to Execute after Updating VIs on the Deployment Machine?

[Daniel-E]

Thorsten,

When you say that you check the changes into version control and then check out the changes on the other system, do you mean that you check in/out all of the LabVIEW VIs, or just a subset that you are updating?

[ThorstenBuchheim]

I check in all VIs  that are modified after a mass compile on the developer system and check out all LabView files on the target systems.

So all VIs on both system are identical.

[ThorstenBuchheim]

One more thing occurred to me when thinking about the problem:

We are currently installing the LabView Development System on our target platforms which actually is not needed.

Is it possible that TestStand takes some precedence of the LabView developer VIs instead of the ones that were exported  to the project folder when it reloads the VIs on a different system than the one where the mass compile was done originally.

This would also mean  that TestStand or LabView detects that the compilation was done on a different system and tries to reload the dependencies, then finding the developer VIs first and complaining that they are not runtime compatible.

Can somebody support  this theory or prove it wrong ?

[Teuch1]

Attached a snippet from an email a colleague received from a NI application engineer regarding a recent problem using Teststand  and the LVRTE. From the email its clear that when a VI is run from Teststand using LVRTE it does not use the correct <Userlib.> folder.

User.lib folder there is a URL in the project file that points to the <userlib> folder. When the VI is run using the LabVIEW Run-Time there is no such thing as the <userlib> folder, since this is only a part of the development system. (If an application is built from the development system necessary files from e.g. the user.lib folder will be included, but the directory will not exist within the compiled program.) This causes TestStand to identify the <userlib> folder as the TestStand user.lib and makes it look at the incorrect location. The labview user.lib directory is seen only as a normal folder if it is added as a search directory and is not identified with the <userlib> defined in the project file. If you, in teststand, go into configure>adapters and configure LabVIEW you can choose to use the LabVIEW development system, instead of the Run-Time engine, and the <userlib> will then be associated with the LabVIEW user.lib.