Passing an Interrupt from a DLL to LabVIEW

[Phillip Brooks]

I have a DLL that monitors hardware. When an defined interrupt occurs, the DLL calls an interrupt handler by way of a pointer to the handler. I need to handle this from LabVIEW. Below is the API documentation for the function.

The vmeConnectLM() hooks an interrupt handler when a location monitor is signaled (interrupt occurred).

ULONG vmeConnectLM(

BYTE LMNumber, // LM number 0-3.

ULONG PtrToHandler. // Handler address for the LM INT.

);

Parameters

LMNumber - The LM number range of 0-3.

PtrToHandler - Pointer to a handler to be called when the INT occurs.

Return Values

Zero, if successful; otherwise an Error Code.

Remarks

A vmeAcquireInt() API call must be performed before any interrupt can be enabled or disabled. The handler suppose is to be declared as typedef void (*FUNC)(ULONG). If this command is successful, the Location Monitor interrupt specified by LMNumber will automatically be enabled. The parameter passed into the handler will be the LMNumber.

How/what can I associate to this DLL function?

[m3nth]

Wow. That sounds complicated.

Rolf! Where's Rolf!? He might know.

So you want to use LabVIEW code as an interrupt handler and then pass along a pointer to that LabVIEW code so it will be executed on an interrupt??

I have limited knowledge in this arena but I'm wondering if you can't implement your own interrupt handler in C using your own custom DLL or code interface node. That would let you come up with a block of code to execute as the handler that you could get a pointer to and pass along to your DLL. Then you could use that block of code in conjunction with some easier mechanism (Queue, Notifier, Occurence etc) to communicate back to LabVIEW that it needs to do something. That way you wouldn't have to directly have a pointer to a chunk of LabVIEW code, but it would still do nearly the same thing. You would also have the option of performing a poll then in LabVIEW which might even be easier than an interrupt driven chunk of code (but that might not be exactly what you need).

Can you expand on how fast you need this to execute? Do you think a dedicated parallel loop in LabVIEW that was polling at a certain rate would be adequate? That sounds a lot lot easier than getting an interrupt handler to directly run LabVIEW code.

[Phillip Brooks]

Wow.  That sounds complicated.

Rolf!  Where's Rolf!?  He might know.

So you want to use LabVIEW code as an interrupt handler and then pass along a pointer to that LabVIEW code so it will be executed on an interrupt??

I have limited knowledge in this arena but I'm wondering if you can't implement your own interrupt handler in C using your own custom DLL or code interface node.  That would let you come up with a block of code to execute as the handler that you could get a pointer to and pass along to your DLL.  Then you could use that block of code in conjunction with some easier mechanism (Queue, Notifier, Occurence etc) to communicate back to LabVIEW that it needs to do something.  That way you wouldn't have to directly have a pointer to a chunk of LabVIEW code, but it would still do nearly the same thing.  You would also have the option of performing a poll then in LabVIEW which might even be easier than an interrupt driven chunk of code (but that might not be exactly what you need).

Can you expand on how fast you need this to execute?  Do you think a dedicated parallel loop in LabVIEW that was polling at a certain rate would be adequate?  That sounds a lot lot easier than getting an interrupt handler to directly run LabVIEW code.

5780[/snapback]

I will have three A/D channels generating single WORD data running at 1200 Hz each. These will not be synchronized. The channels are enabled and disabled manually, this is a monitoring function I may need to switch hardware and DLL at some pint (this is a VME Single Board Computer), but the alternate DLL offers the same functionality (pointer to a ISH routine). I really don't want to write a wrapper DLL.

I might be able to poll using timed loops, I'm evaluating this now...

[Phillip Brooks]

:thumbdown: Well, timed loops are limited to 1 msec resolution when running under windows. You can select 1 MHz clock only with RT; this won't work because I need the DLL. Still thinking....

[m3nth]

So you need the data to be acquired at 1200Hz with no buffering available?

Perhaps if you did write a wrapper DLL it could just be a buffer that you could poll at a slower speed than the speed of your acquisition (like most normal DAQ routines).