VI's in TestStand User Interface memory - Conflict with Code modules

[lordsathish]

Hi Ppl,

We have created an application using the TestStand full Featured user interface. The application is pretty large, having quite a few utilities other than the full featured user interface. I have created few LabVIEW modules reusing the same code that was used to create the application. I noticed that when I'm using the LabVIEW runtime engine adapter, these LabVIEW modules are not getting loaded when I try to specify module and returns error -18002. I found that this was because both the module and the application were using VI's with same name. When I renamed the LabVIEW modules and relinked them I was able to load the code module.

Please suggest me some good way to deploy these code modules. I tried using source distribution, in which I had to source distribute, then rename a large number of VI's, relink them and then deploy them. Since I had included vi.lib and instr.lib there were aroung thousand VI's in one code module. I feel this approach is pretty tedious.

Thanks,

Sathish

[lfelias]

Hi!! I found this KB that might help you!!

http://digital.ni.com/public.nsf/allkb/D82FEAF0B4BA293A862575710053E252

Regards,

[RayFarmer]

Hi,

The trouble is you cant have the same VI loaded from two different locations. In your UI the location is going to be in the exe whereas your code module is coming from some disk loaction. Therefore you have try make the VI come form the same location or rename the VI for one of the calls. You could trying calling your VI dynamically from within you UI.

[J.C._Andersen]

Hi.

I know this is an old post, but I have the same problem, but the context is a bit different.

I have a sequence file which contains a call to am instrument driver VI called "Initialize.vi". This VI is a member of a lvlib, and thus it its fully qualified name is "<lvlib name>:Initialize.vi".

The TestStand Full Featured OI also includes a vi named "Initialize.vi". This VI is a member of "TS Full LabVIEW UI Dependencies.lvlib" which again resides inside "TestExec.llb" (I guess the TestStand team was not told that no one has been using llb's for the past decade or more).

In my book the two VI's both named "Initialize.vi " are name spaced apart and you should be able load in the same LabVIEW instance no matter if it is the runtime engine or the development environment. But it turns out that I run in to trouble anyway.

The scenario is as follows:

• I open the sequence editor and make sure that the LabVIEW adapter is set to use the runtime engine.
• I insert the VI from the instrument driver in the sequence with an absolute path, save the sequence file and close the editor.
• Then I open the Full Featured OI and open the sequence file.
• I press "Run MainSequence" and then I get the following error:
  Unable to load VI 'C:\TestStand\Test Sequences\My Name Space Test\My Support VIs\Initialize.vi'. LabVIEW already has the VI 'C:\Users\Public\Documents\National Instruments\TestStand 2019 (32-bit)\UserInterfaces\Full-Featured\LabVIEW\Source Code\TestExec.exe\Initialize.vi' loaded and cannot load different VIs with the same name. You can resolve this issue by either by renaming the VI or adding the VI to a LabVIEW Project Libary.
• I close the OI and open the sequence editor.
• Now I make the path to the instrument driver VI relative to the sequence file name.
• I close the editor and reopen the OI.
• I press "Run MainSequence" and the result is the same as with an absolute path.
• I close the OI and open the sequence editor.
• Now I add the instrument driver directory to the TestStand search path.
• I close the editor and reopen the OI.
• I press "Run MainSequence" and now everything loads correctly and the sequence can execute.

To me this sound like TestStand is not handling LabVIEW name spacing correctly. Especially when I use an absolute path, there should be no problem what so ever.

I am using LabVIEW 2019 SP1 and TestStans 2019 f1.

I have attached a simple example that illustrates the problem.

Can anyone from NI please explain what is going on with this, thanks.

[Anand_Jain]

J C Andersen, 

Update: I have reproduced the problem in house and at this time it looks a LV bug. I am working with the LV R&D to resolve this issue. The only workaround I know of at this time is to rename the VI in the User Interface. 

I will post an update once I have more information. 

Regards, 

Anand Jain

National Instruments