LabVIEW
inter process communication and synchronization
Apart from turning your LabVIEW code into a shared library/DLL and calling it from your application as has been suggested already I would recommend to use TCP/IP. Active X is not simpler to handle but has as drawback that it will only work on Windows systems and over network only with some extra setup.
@max_mont wrote:
Hi all,
I 'm new in LV and I only know VB, C/C++ language.
My VB application launches some LV applications and I'd like to get the
results of tests executed by LV applications.
So I'd like to develop a communication between LV applications and VB
or C/C++ applications.
What's the best way in LV to make interprocess communication ???
My ideas are to use TCP/IP socket or windows messages.
Many thanks in advance for your help.
Using TCP/IP you have to do a little work in LabVIEW to develop a TCP/IP server but depending on your needs this can be quite simple. As long as you only need to support one single client connection at the same time a LabVIEW TCP/IP server as part of your applciation is really just an additional loop somehwere in your application listening for connection requests and handling whatever command is arriving.
Look for examples by searching for TCP/IP in Help->Find Examples. Look for Simple Data Client/Server and Multiple Connections Client/Server. These are all LabVIEW<->LabVIEW examples but if you have some experience with TCP/IP sockets in your other environment, creating a simple TCP/IP client in your external application is absolutely no problem.
Rolf Kalbermatter
@Anders68 wrote:
How much overhead are we talking about by calling a DLL?We are trying to do inter process communications from C/C++ to LabView.Is the consensus still that TCP is the best?We would like to be platform independant so Active X is ruled out?I don't know much about Active X and its benefits.
DLL calling overhead is usually quite small. For LabVIEW DLLs there is an additional possible overhead if you work with large arrays or strings, since the memory representation for those is quite different in LabVIEW than in C, and this means that if you model your DLL interface so that it can be easily called from other languages, you will use the C types for those parameters and the LabVIEW DLL Builder will create function stubs that translate between the C type and the LabVIEW typical type, which normally involves copying the entire contents into a newly allocated memory buffer. This can for large arrays amount to a significant calling overhead. For small arrays and strings this overhead is however insignificant and for skalars it is nonexistent.
As to doing inter process communication a DLL in itself can't help you anything in that. A DLL is loaded into the adress space of the process that requested it and as such two processes loading the same DLL will result in the DLL being loaded twice into independant address locations. One instance of the DLL can not see the into global variables of the other at all.
For inter process communication there are traditionally a number of technics:
1) DDE (old, legacy and slow, Windows only)
2) shared memory (only in modern systems, very fast but only on local system and OS dependant)
3) pipes (something between shared memory and files, OS dependant)
4) files (trivial, reasonably fast, OS independant)
5) network protocol (quite fast, universal and availabel in almost any environment and programming environment nowadays, OS independant for TCP/IP).
1) should not be used anymore
2) and 3) are not natively supported in LabVIEW (well 3 is under Unix)
4) and 5) are natively in LabVIEW
Rolf Kalbermatter
