VI not found in instr.lib when using Project path

[Oli_Wachno]

Can you please specify which TestStand and LabVIEW versions you are using? 

[OnlyOne]

NI Labview 2019 SP1 f5
NI Teststand 2019 f4

[FloresFe]

Hi @OnlyOne and @Oli_Wachno,

The root cause of the issue lies in the fact that the LabVIEW Run-Time Engine cannot resolve symbolic paths such as <vi.lib> and <instr.lib>. These paths are special types utilized by the LabVIEW Development Environment to simplify the process of resolving dependencies.

Symbolic Paths - NI

Every time we develop code modules that have dependencies in instr.lib or vi.lib, we must make sure we include them in the deployment either by creating a source distribution or a PPL including your test code and the dependencies.

In the LabVIEW Project, code is referenced using Symbolic Paths. While these paths may not be visible from the LabVIEW Project Window itself, if you open the .lvproj file, you will find VI URLs beginning with "/<instrlib>" or "/<vilib>".

For instance, in the project above (Agilent 34401, which comes with LabVIEW), if you change:

<Item Name="Agilent 34401 Read Single Measurement.vi" Type="VI" URL="/&lt;instrlib&gt;/Agilent 34401/Examples/Agilent 34401 Read Single Measurement.vi"/>

to:

<Item Name="Agilent 34401 Read Single Measurement.vi" Type="VI" URL="../Examples/Agilent 34401 Read Single Measurement.vi"/>

You will notice that the code module can be located by TestStand using the LabVIEW Runtime adapter since it can resolve relative paths. However, this is not the recommended approach, as these dependencies have a specific purpose for containing these special paths. They ensure that LabVIEW Development can resolve the paths regardless of where your projects are stored or where LabVIEW is installed on a given system, or when logged in as a specific user.

The recommendation here is to keep using LabVIEW development for your code modules and make sure you pack them up when deploying your system. Another option would be to convert the driver into a PPL, including all the dependencies, and use it with the Run-Time engine.

The recommended approach is to continue using LabVIEW development for your code modules and ensure that you package them when deploying your system. Alternatively, you can convert the driver into a Packed Project Library (PPL), which includes all the dependencies, and use it with the Run-Time engine. 

@OnlyOne, is there a specific reason for using the Run-Time Engine in the adapter instead of LabVIEW Development?

Hope this helps! 😃👍

[OnlyOne]

Thanks for finding the root problem.

The reason that the sequence has to execute in Runtime is that this is a production-tester with no need of an expensive devopment-licence.

How can i convert the driver into a Packed Project Library (PPL)?