Calling a complex LabVIEW application from another non-LabVIEW application

[David_T]

I want to be able to open a VI from a C or Java 'master' application. The VI needs to be opened, continuously collect data, process it, return it to the calling application or close on demand. I do not want the VI front-panel to be visible. Is this possible by compiling my VI as a DLL and calling it? The data needed by the master application includes a large 3D array and an error cluster. I have achieved success calling a VI I had compiled as a DLL from another VI, retrieving a 3D array, but don't seem to be able to make the "slave" application stay open.

Suggestions please!

Thanks

David

[MikeS81]

Hi David,

what shall stay open? You can only read data from the dll with a new function call. Another solution would be to create a parallel running vi (this can be done with one dll call). from there you can read data with another dll call or you use maybe TCP/IP to transfer data between your processes.

Hope it helps. 

Mike

[David_T]

Thanks Mike,

that sounds exactly what I need to do. To clarify a bit, I need a front-end GUI application ("APPLICATION") which it is hoped will be non-LabVIEW and a data collection and processing app ("MODULE") which will be LabVIEW. I need to start MODULE with APPLICATION. MODULE then needs to stay running and collecting data. when desired,APPLICATION requests data from or sends data to MODULE. Eventually, APPLICATION will need to close MODULE. So, what you suggest sounds perfect. Do you have an example of how to create a parallel running VI which can be called as a dll? The other problem I had is that I have already made MODULE, which obviously has a single top-level VI. When I create the DLL from the project which the MODULE code is in, I only seem to be able to create one function call. Is there any way of allowing the VI to receive multiple different function calls or do I have to have one single, complex function call with many parameters?

Thank you once again,

David

[rolfk]

I don't have a ready example for this and there might be one or the other looming problem in here. But the basic idea would be to actually have an exported VI that can start and stop a deamon. This VI would on start request launch a dynamic VI, opening its reference and running it as top level VI. The deamon VI should not need to have its front panel open but it may be necessary for the deamon to open a reference to itself in order to make the LabVIEW runtime keep the VI alive.

In that deamon you then do the actual data acquisition and processing and post the data in some way. This could be for instance writing it in a queue that can be read by another VI function that is exported from the DLL, implementing a TCP/IP server that can serve your application the data, or just about any other interapplication communication method, including shared memory or memory mapped files.

On calling the deamon controller with the stop request it sends an event to the deamon requesting it to close down.

Rolf Kalbermatter