LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open reference to LabVIEW from Application

Hi
I have a built LabVIEW application and I want to call "plugin VIs" via VI server. The plugins should run in LabVIEW development environment, not loaded into the application memory space.
I tried to open an application reference from the application to the dev environment, but this doesn't seem to work. Neither "localhost" nor "" as machine name return a reference to the dev environment. VI Server is enabled in LabVIEW.
Is there any way to control VIs from a built application?

Thanks
Daniel

0 Kudos
Message 1 of 11
(5,181 Views)
VI server functions do work in EXEs. Make sure you have different port numbers for the EXE and for LV.

___________________
Try to take over the world!
0 Kudos
Message 2 of 11
(5,150 Views)
tst, I agree VI server calls are possible within EXEs. But if I call a VI from an EXE via VI server, the VI is loaded into the application. I didn't figure out a way to run the VI in LabVIEW.
Maybe some more details to my setup:
I have an application built in LabVIEW 7.1. Users can write plugins for that application, they are called using VI server. The VIs run fine when written in LV7.1. But now one user has only LabVIEW 7.0. As these plugins are loaded into application memory space (LV runtime 7.1) the VI doesn't execute.

I have attached a small sample illustrating the problem. Start the EXE (built from "Call VI via VI Server.vi") and specify a target VI to run.
LabVIEW uses TCP port 3363 for VI server. The app uses port 3370 (see ini-File). Although I open an application reference to port 3363, the target VI is loaded into the application. When trying to run the 7.0-plugin, I get an error.

Any suggestions? Thanks
Daniel
0 Kudos
Message 3 of 11
(5,134 Views)
Are you sure you have the LV7.0 development environment running?  Try launching LV7 using the system exec call first, then see if you can access the VI server.  Also, what is the error that you're getting?  (Disclaimer:  I can't run LV on the system I'm currently reading this post from, so my apologies since my questions would be readily answered by examination of the example code)
0 Kudos
Message 4 of 11
(5,129 Views)
@Trager: Thx for reply. Actually on my system I only have LabVIEW 7.1. So what I want to achieve currently is to call a VI from a built application such that the VI runs in the LabVIEW development environment.
In my tests, the called VI always runs in the exe. The error I get when trying to call a 7.0 VI is 1126 (LabVIEW:  VI version is too early to convert to the current LabVIEW version.). This makes sense as the 7.1 runtime engine doesn't support 7.0 VIs. Only the development system does.
0 Kudos
Message 5 of 11
(5,127 Views)

I think the gist of my query still applies, though.  Do you have the development environment running?  If you use sysexec to call LabVIEW.exe and your development environment has VI server enabled, I don't see why you can't call the dev-environment VI server from your executable.  What happens when you try to open the reference to the dev app server?  Do you get an error, or is the error only upon trying to call the v7.0 VI?

0 Kudos
Message 6 of 11
(5,124 Views)
Yes, LabVIEW is running.
If I use "" as machine name in open application reference, I don't get an error but the VI runs in the application, so the application reference seems to point to the EXE (although I use port 3363 where the development environment is listening - the application is listening on port 3370).
If I use "localhost" as machine name, I get either error 62 (LabVIEW:  Serial port overrun error. --- LabVIEW:  The system caused the network connection to be aborted.) or error 66 (LabVIEW:  The network connection was closed by the peer.).
0 Kudos
Message 7 of 11
(5,124 Views)
What if you use the explicit local IP address instead of "localhost"?  Or, almost equivalently, have you tried 127.0.0.1?
Message 8 of 11
(5,120 Views)
I have just tried that myself, and ... it works! Using the "real" IP address (or machine name) works.
I'm behind a NAT, so my IP is 192.168.x.y. If I use this IP as input to open application reference, I get a reference to the LabVIEW development environment. So using the "String To IP" and "IP To String" functions to get the IP and using this as input to "Open Application Reference" will return the desired reference.
Its strange, neither "localhost" nor 127.0.0.1 work. Only the real name. The help to open app ref says:

If you want to establish communication between a VI and a stand-alone LabVIEW application on the same computer, wire localhost to this input. localhost establishes communication with the LabVIEW Run-Time Engine.

So I'm only wondering whether this is an undocumented feature or kind of incidential feature which might change in a future version. Smiley Happy
Nevertheless, this solves my problem.
Thanks Trager!

Daniel

Message Edited by dan_u on 10-16-2005 11:48 PM

Message 9 of 11
(5,124 Views)
Glad I could help.  Incidentally, reading what you just posted from the NI documentation, I think they stated exactly what's happening.  localhost and 127.0.0.1 are defined by NI to give precedence to the run-time server, not the development environment server.  It appears that they assumed that most people would want to do the reverse of what you're doing.  I wouldn't be surprised if using the explicit external address causes LabVIEW to actually use TCP/IP communication, which when it gets resolved, comes back the the computer as external communication. 
 
Either way, that's an interesting bit of LabVIEW obscurity that you've dug up 🙂
Message 10 of 11
(5,110 Views)