LabView user-event from external dll source

Question

Hi!
I'm dealing with the following issue:
I use a CAN sniffer device, wich sends data over USB to a PC. The main goal is to create a vi that can process the incoming data. I already have a vi wich works with polling mechanism. It calls external DLL functions with the "Call library function node". The main problem is the polling mechanism.
I would like to recreate this vi so that it would work event-driven. I have an other application, written in C++, that does the same thing, and it gets interrupts from a DLL, when a new data is available in the input buffer.
The callback mechanism is implemented in the DLL.
In LabView I would like to do tha same thing. There is the "event case structure", but there is no option for defining such user-events, that i would prefer.
I have found a similar topic, there the solution is "occurrences". The occurrence is called from a DLL, too. But this solution uses the "waiting for occurrence to set", that is an endless-loop-like thing.
The other thing I've found is the ActiveX and .NET events. I don't know, probably that is the solution.
Anyway: is there a possibility to create such events, that can be generated from a simple external DLL and can be handled by "event case structure"? How should I do this?
Or how NI does this? I mean that NIs DAQ cards must use some similar methods for data processing. Is there some tutorial or support about it?
Thank you for your answer!

Answer 1

2716jag wrote:
Hi Wiebe,         From your answer i have a doubt that What it exactly means "If the dll is used from within LabVIEW". Also i want to know Is there any way to access the functuions defined in the .SYS file in Labview Environment. Regards,Jagan Can you be a litte more specific with your first sentence. I have no good idea what you mean. A .sys driver is usually a kernel device driver. This driver has to be started and run in the kernel subsystem which LabVIEW can not access directly. Such a driver is initialized using the CreateFile() Windows API. The returned handle is then used with other API functions such as ReadFile(), WriteWile(), DeviceIoControl(), and finally CloseHandle().Theoretically you could call all this APIs directly from within LabVIEW using the Call Library Node. In practice you do not want to do this even for fairly simple kernel drivers since the parameters for those APIs do get fairly complex in most cases, and you usually do also want to have some sort of asynchronous operation using events or such to make the driver access user friendly. All these things are most easily handled in a user space DLL written in C that exports a more LabVIEW friendly API that you can then import into LabVIEW using the Call Library Node. Usually most kernel device drivers do come with a accompagning user space DLL already, as this is the only sensible way of accessing such a driver. So you can usually look for the documentation of that user space DLL API and go from there trying to import that into LabVIEW using the Call Library Node. Even then it may not be easy at all if that API uses complicated function parameters and even completely impossible if it uses callbacks or such, requiring you to write a so called wrapper DLL that translates between the native API and a more LabVIEW friendly API.  You don't have to believe me but I can guarantee you that if writing such a user space DLL or wrapper DLL is beyond your capabilities, trying to go directly about accessing the Windows APIs in LabVIEW to access a kernel device driver is going to make you squirm in real pain. And those knowing how to write such a DLL would never even consider spending the time to try to access a kernel device driver directly from LabVIEW. Rolf Kalbermatter