02-01-2006 02:39 PM
02-02-2006 04:40 AM
02-02-2006 07:34 AM
When you use the project manager in LabView 8.0, you set the server setting in the porject. But I try with the older methode and it's doesn't work.
Did you try the code?
Benoit
02-02-2006 03:12 PM
Another thing you might try besides the VI server settings is that you have the fully-qualified VI name in the string control on the client. In this case it looks like it would be:
Get Set.lvlib:Get Set.vi
You can get this pretty easily by just dragging the VI from the project window into the string control on the client VI.
Hope this helps!
02-03-2006 07:52 AM
02-03-2006 08:16 AM - edited 02-03-2006 08:16 AM
I no longer have your VIs in front of me, but the idea is this:
In LabVIEW 7.1 and earlier, VI Libraries (LVLIB) did not exist. A large part of the reason for creating VI Libraries was to address namespacing issues, so you could actually have two VIs with the same name in memory at the same time, provided they are in different libraries.
Similarly, to address a VI by name in 7.1 and earlier, you only needed the name of the VI. In this case, that would be "Get Set.vi". Since it is in a library in 8.0 called "Get Set.lvlib", the fully-qualified name is "library name:VI name" -- "Get Set.lvlib:Get Set.vi".
So make sure your client VI has that string (just drag the Get Set.vi from the project window into the string control) and is set to use the string and not the path, and hopefully that will solve the problem.
Message Edited by Jeff B on 02-03-2006 08:16 AM
02-03-2006 08:42 AM
First of all, I've managed to successfully call a VI dynamically that is
being called as a subVI in a built application from another built
application using LabVIEW 8, which I believe is what you want to
accomplish. So this is possible. The path reference has not changed from
LabVIEW 7.1 to 8. You still reference the subVI as
C:\...\Application.exe\subVI.vi.
I then tried taking sequential steps to find out what in the process is
breaking this communication. I started by embedding the subVI to be called
dynamically into a Project Library and rebuilding all the executables. The
result still worked. After that I tried embedding the Server VI that
contains the subVI into a separate Project Library. After rebuilding the
exact same application, but with the new library structure, the VI Server
communication failed. I believe, therefore, that we are getting some
conflicting information when we start including these VIs into Project
Libraries. I also noticed with your application that at times the
Client.exe application still seemed to be referencing the unbuilt version
of Get Set.vi at its original location, even though the path was clearly
set absolutely to be Server.exe\Get Set.vi. I'm not sure if this is because
of the Project Library format as well.
I will escalate this issue to find out exactly what is going on. In the
meantime, you can achieve this functionality for now by not embedding the
Server VI in a Project Library. If you rebuild the application without
Project Libraries, the VI Server communication succeeds.
Benoit
02-07-2006 08:25 AM
This worked great for me. Really the part that took some digging is step 2. The other part that I was previously trying to explain was just making sure you included the library name in the name of the VI in step 4.
08-22-2006 07:04 PM