Setting up a LabVIEW call back from a C DLL

[clendon.gibson@canrig.com]

I have searched for an answer to this several times and have gotten nothing.

I have a large LabVIEW application that reads and writes data to various pieces of hardware. This application runs on Linux.

One of the pieces speaks in an unusual protocal. This protocal is complex enough that I don't want to have to create a LabVIEW native driver. Such a driver apparently does not exist for me to buy either. Instead I have to use a C based library from a third party. The way the library works is that when traffic comes in, it calls a callback function to handle the incomming traffic.

It would make the code a lot simpler if I could use a LabVIEW vi as the callback function. This would requrie getting a usable function pointer which I think is not possible.

So now I am wondering if a C callback function could call a LabVIEW vi if the vi were part of a shared object. So my main app calls the C protocal shared object, which calls a LabVIEW shared object. The problem here is of course that I don't know how the LabVIEW SO would talk to the main LabVIEW application.

Would it be possible to pass a queue reference to the LabVIEW SO? Since the SO and the application are running from the same Run Time Engine, would they share memory space such that a passes Queue reference would work?

Any other ideas? Thanks!

[Jarrod_S.]

There are some roundabout ways to get a function pointer to a VI on Windows using .NET delegates, but I don't know of any way on Linux.

To answer your question about SO's, this approach will likely not work. When LabVIEW code is called inside a shared library, it gets its own execution context. This means queue references and all other reference types are not available in the main execution context.

However, you could reorient this approach such that the callback dumps data into your LV Shared Object function, which stores it in some internal queue. You can then have another exported Shared Object function to read data out of this queue that the main application can continuously call.

[Jarrod_S.]

This post seems to sum up some good options for you. Most likely you will need an extra C-wrapper to provide the actual callback for your driver library. This C-wrapper can then call into LabVIEW in one of many ways to get the data across.