LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting a server error when launching VI's dynamically from a llb

I have made a simple VI launcher which opens a reference to a VI and opens the Front Panel through a property node and run the VI by using a invoke node in order to be able to distribute the launcher without having any sub VI's included. When running the Launcher as a VI calling a subVI in a LLB file there are no problems. But when compiling the launcher to an executable file and then call the same VI in the LLB I get an error 1003 "error at invoke node in VI" The VI is not executable. The VI is missing a lot of standard sub VI's which is located under the \Vi.lib\Utility\.
However I can save the LLB with options and include the missing VI's and make it executable but the LLB becomes huge. Somehow the reference to the standard library is missing when using the executable launcher. I have also tried to set windows path to the standard library but without success.
Is there any workaround for this problem?

Thanks in advance
Regards
Peter
0 Kudos
Message 1 of 4
(2,949 Views)
Is this happening on the PC where you have LV installed or just on other PCs?
When you build an application it includes all the necessary VIs. If you don't build an application, you will have to transfer all the VIs yourself to the target computer. You can try installing the RTE, but that doesn't include the VI.lib directory.
In the end, there is no getting around it - you must have the VIs on the computer for the code to run. A loader VI is good for a case where you want to replace VIs without constantly replacing the EXE.

___________________
Try to take over the world!
Message 2 of 4
(2,938 Views)
Hi tst

This error happens on the PC where the LV is installed.
If I look at the standard Paths from a VI and from the executable there is a difference. The VI, launched from LV is able to use the LV standard paths and find the \Vi.lib\Utility\ folder where all the VI’s used are located. The path from the executable is only looking at it self and below from there, regardless of the Windows global path.
I manage by include the \utility\ folder to the root of the executable so it becomes a common folder for all the dynamic VI's the launcher is calling and then it is working.
Another work around could be compiling all the Sub VI’s to DLL’s or executables and change the launcher to run a DLL or a stand alone executable file instead and only have the RTE installed. But here, the intention by launching VI’s is that it is easy for me and others to make changes to the VI or even for others to write new VI’s which could be added to the launcher, and not by converting the VI to a DLL or executable each time a small change is made.

Thanks for your reply

Message Edited by Sandman on 06-06-2005 03:36 AM

0 Kudos
Message 3 of 4
(2,928 Views)
A VI maintains a list of the subVIs it uses in relation to where it's located. If it doesn't find a VI where it's supposed to be, it starts looking elsewhere. This can be set in the EXE's INI file. Find the appropiate line in the LabVIEW.INI file (should be something like "viSearchPath=":\*;:\;:\*;:\*;:\*;") and copy it into the EXE's INI. If you don't have it, add another path in the options menu and it should appear.

I still don't understand something - if A VI was compiled, it remembers its subVIs locations - if you don't move it, it should work fine. Are you including the dynamically called VI in the build? If you are, it will be moved into the EXE (which is built like an LLB) and if it's calling additional VIs dynamically, will lose their place. If you're using it on the same computer, you can avoid including it, but to get its relative path correctly, you will have to do an additional strip path if you are using the calling VIs path as the source. You can do this by placing a property node and selecting the Application>>Kind property, which will tell if you're in the development system or the RTE.

If this didn't help, can you post a small example of this?

___________________
Try to take over the world!
0 Kudos
Message 4 of 4
(2,916 Views)