NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong search directory with LV run-time engine. Correct with development system

Solved!
Go to solution

Hi all,

I am trying to run some code that is working on an older system, but I'm facing a rather strange behaviour when it comes to loading VIs.

This is standard VI, but added to a project. When I open the LV project, it shows the correct path.

 

LabVIEW development system loads VI from LabVIEW directory as referenced by the LV project fie.

Paulius_0-1585814015065.png

LabVIEW run-time engine fails to load the VI, because it searches for it in TestStand folder instead:

Paulius_1-1585814100903.png

 

What could cause this and how could I solve it? Preferably without touching code modules.

0 Kudos
Message 1 of 8
(2,882 Views)

Hi,

 

I guess the answer lies within the question itself 🙂

The difference is in the default configuration of the search directories for each environment you use.

 

For example, this is a screenshot from TestStand (Configure -> Search Directories)

image.png

 

But you can add your own, as you've already figured out,

by clicking the Add button and browsing to the desired base directory,

such as C:\Program Files (x86)\National Instruments\LabVIEW 2016\

 

Just make sure to move it up above the TestStand directories:

image.png

0 Kudos
Message 2 of 8
(2,869 Views)

Hi, thanks for your reply. The only setting I am changing is LabVIEW adapter Server fom Development system to run-time engine.

Paulius_0-1585817226359.png

I am not changing search directories. I did try to add LabVIEW path (with and without "search subdirectories" enabled) to search directories, but that does not change the observed behaviour.

0 Kudos
Message 3 of 8
(2,852 Views)

Maybe this would help (from TS help file):

LabVIEW Module Tab

image.png

0 Kudos
Message 4 of 8
(2,844 Views)

Hi, I am aware of this, but maybe I am missing a point here. I am specifying a VI in a LabVIEW project. It works with Development System and doesn't with run-time engine. Why?

0 Kudos
Message 5 of 8
(2,838 Views)
Solution
Accepted by topic author Paulius

Hi Paulius,

 

This happens because of the way TestStand and LabVIEW resolves file paths using their respective search directories.

 

When you specify a VI in TestStand, outside the context of a project, the TestStand search directories are used to resolve any relative paths.

TRJ_0-1589449890609.png

 

When you specify a VI in project context, the project path is resolved using the TestStand search directories.

TRJ_1-1589450127257.png

 

However, the path of the VI specified in the project context is resolved by LabVIEW using its search directories and information stored in the project. TestStand obtains the absolute path of the VI from LabVIEW.

TRJ_2-1589450272049.png

 

Given this, when you load a VI from vi.lib in project context, when the adapter is set to use the LabVIEW Development System, the LabVIEW Dev System resolves the VI's absolute path to <LabVIEW app directory> + <relative path to VI>.

 

However, when you load the same step with the adapter set to LabVIEW Runtime Engine, the path of the file gets resolved to <TestStand app directory> + <relative path to VI>. This happens because the LabVIEW Runtime Engine is essentially a dll that is loaded in-process by TestStand. So the current application path points to TestStand's directory rather than LabVIEW's.

 

Some possible solutions are:

  1. Create a source distribution or a Packed project library which includes all your code and its dependencies (like vi.lib VIs) and call that from TestStand. This is the recommended approach, especially when you want to use the LabVIEW Runtime Engine for execution. This would allow you to deploy your sequences and VIs to a machine with only the LabVIEW Runtime Engine and it would still be able to execute correctly.
  2. This is more of a workaround, if you don't want to change your LabVIEW source. Don't load the vi.lib VI in project context. Add a search directory in TestStand which points to the LabVIEW installation directory and specify the VI's path relative to that.

 

Hope this helps. 

 

Regards,

Tinu

 

 

 

 

 

 

Message 6 of 8
(2,686 Views)

Hi TRJ,

thank you for explaining what is going on. It makes more sense now. I will see how I can fix my system when I will get to it. Marking your post as the answer for now.

Btw, is this documented somewhere in the official documentation? Is this TestStand or LabVIEW version-specific behavior?

0 Kudos
Message 7 of 8
(2,633 Views)

Hey Paulius,

 

Glad that helped.

 

The general conventions on how files are resolved in both TestStand and LabVIEW is there in official documentation. I am not sure if this particular case of calling a vi.lib VI in project context in the LabVIEW RTE from TestStand is documented, it is a sort of special case.

 

This behavior is not version-specific and you should see the same behavior across TestStand and LabVIEW versions.

 

Regards,

Tinu

0 Kudos
Message 8 of 8
(2,626 Views)