Teststand and Labview cannot load same VI while using the teststand execution only license.

[V_T_S]

My GUI is based of UserInterfaces\NI\Full-Featured\LabVIEW, in my GUI I am calling a VI named “abc.vi”. One of my teststand sequences also calls the same “abc.vi”

 

Note: Abc.vi is a regular VI 

  

If I use the teststand development license I do not see any issue of calling the same vi at two different places. The problem comes when I use the teststand execution only license.

I get the following error for abc.vi:

 

Error Message: Unable to load VI 'C:\Program Files\Tools\abc.vi'. LabVIEW already has the VI 'C:\Program Files\Tools\abc.vi' loaded and cannot load different VIs with the same name. [Error Code: -18002]

 

I can resolve the above error by using either of these method:

 

1. Make a copy of that vi xyz.vi = abc.vi, let teststand call abc.vi and labview call another copy xyz.vi

2. Create a wrapper vi (lmn.vi) which calls abc.vi, let teststand call wrapper lmn.vi and labview call abc.vi

 

Why teststand execution only license have this issue?

[Dennis_Knutson]

Except under special circumstances, LabVIEW itself cannot load VIs on the same name and from different locations. If you specify a VI of the same name and different path, LabVIEW will simply use the VI that is currently loaded. so, I'll bet you don't actually have two different VIs loaded at all. The difference with the error is probably because you are using the LabVIEW development system.

If the VIs are really the same, then you should only have a single copy in a sharted location. If they are different, they should have different names.

[V_T_S]

The only difference is in Lab View that VI is a part of project and in Test Stand, sequence is calling the same VI from same location. I am sure that Labview and Teststand do not share the memory during execution under the teststand execution only environment, but they do share the memory space if you use the development environment.

 When labview and teststand are not sharing the memory why do I see the issue in execution only environment?

[RayFarmer]

Hi,

I think the problem is that the GUI will have the path to the vi as ..\GUI.exe\abc.vi which is nolonger the same as the original location and therefore the LabVIEW RTE is going to complain that you are trying to load a previously loaded VI.

One possible solution is maybe make abc.vi re-entrant.

Regards

Ray Farmer

[Dennis_Knutson]

The LabVIEW runtime engine will probably still complain about the different paths. The GUI should be made into an exe.

[Snowman 6008]

If you follow Rays advice here is an excellent KnowledgeBase on the Differences Between Reentrant VIs (Preallocate), Reentrant VIs (Share Clones), VI Templates, and Dyn....

[V_T_S]

The abc.vi is already a re-entrant VI and the GUI is also an executable, still I have no success.

Any other suggestion is really appricated.

Thank you,

Vidula

[RayFarmer]

Hi,

I think the re-entrant suggestion on my part is a bit misleading.

The main problem is that a VI from different file locations can not exist and you need to resovle this by

a) either use the same VI from the same location

b) rename one of the VI.

Item a) you will not beable to do because one of the locations is in the EXE

so you are left with item b)

I did think that because you work with projects in LabVIEW now that having the same VI's at different locations wasn't an issue.

Maybe its still is when it comes to TestStand, because you have a LabVIEW GUI which calls via and ActiveX interface a LabVIEW VI dynamically.

Regards

Ray Farmer

[ncolson]

I had a similar issue unrelated to licenses, but it was throwing the same error and this thread is ranked high by Google so I'm putting my solution here.  This is with TestStand 2010 and Labview 2011.

My problem:

I had written a TestStand sequence (toplevel.seq) and a Labview VI (parent.vi) both of which called a sub VI (child.vi), which resided on a network drive.  The problem was that Labview was using a mapped network drive letter in the path ("X:\project\child.vi") and TestStand was using the full path with the server name ("\\server\project\child.vi").  Because toplevel.seq ALSO called parent.vi, the "X:\project\child.vi" version of child.vi was getting loaded behind the scenes by Labview, which prevented the "\\server\project\child.vi" version from loading when it was time to call child.vi directly from TestStand.

Solution:

- Open toplevel.seq in TestStand
- File->Unload All Modules

- Close Labview "Getting Started" window in background
- Refresh call to child.vi in TestStand (i.e. click red exclamation mark), it should now load
- Open parent.vi in Labview
- Right click on the call to child.vi, replace child.vi with itself

- Ignore the warning when Labview picks up the new "version" of child.vi that TestStand already loaded into memory

- Save both parent.vi and child.vi in Labview, both will show outstanding changes

The Labview path to child.vi will now agree with TestStand and the two will play nice.  There's probably a direct way to modify paths in Labview, but I was too lazy to find it.

[warren_scott]

I agree with the comments above about having the same named VI on disk and as part of the compiled .exe.  Another solution not suggested above is to edit your LV build process for the .exe to make sure you are prefixing all items built into the exe.  Then you won't have 2 vi's with the same name (one in the .exe, and one somewhere else on disk)