2d array allocated and returned from dll

[lrbenson]

I am using labviews "call library function node" to control an Active Silicon frame grabber (Phoenix). The function used to acquire an image allocates memory on the frame grabber and returns a pointer to this memory. Any idea how I can use this pointer to an image in my vi ?

I have tried using the initailize array function, passing it into the "call library function node" but get no info, it stays at the initialized value. The function call is:
void PHX_Acquire(unsigned long *hCamera, unsigned long eAcq, unsigned long *pvVar);

I have also tried passing it a single unsigned 32 value but can't figure out what to do with the value returned other than passing it to another "call library function node". I was hoping to bring the image into my vi space for analysis.

Any ideas?

[Ankita]

Hi,

Please take a look at the shipping example Call DLL.VI. You can search for this example by going to Help>>Find Examples in LabVIEW. In this example you should look for two datatypes: 2D Array and 2D array handle. This would give you an idea of how you can get an image array back from your dll.

Hope this helps.

Ankita

[Steven_H.]

The key to this question is: who is allocating the memory for the image?

According to the post, the DLL is doing so. If that's true, it's going to be tough to access that memory on the LabVIEW diagram, because LabVIEW can't (on the diagram) dereference a pointer to memory it didn't allocate.

You could build a wrapper DLL that can copy the data into an intermediate buffer, which LabVIEW allocates and passes to that wrapper.

It's easier if the DLL expects the caller to allocate the memory. In that case you'd be able to pass a constant array of U32s (of sufficient size) from the LabVIEW diagram into the Call Library Function and get the data out.

Steven H.

[okidoki]

Hi !,

I'm trying to find the quickest way to pass a buffer
from LabView to a DLL and from a DLL to LabView.

Is it possible to have a memory region shared between
LabView in user space and a DLL in kernel space ?

The idea is to not have any intermediate buffer between
the DLL and LabView but rather have the DLL driver and LabView
reading and writing on single copy shared by both.

Intermediate buffer requires to perform a copy to update the LabView internal buffer.
This copy could be expensive in processing time if the buffer is very large.

I know that several LabView users are using an 1394 Camera within their application.
How do they transfer a large image from their DLL driver in kernel space into LabView in user space ?

Their must be some timing issues at doing that !?
Do they perform a copy or access the image buffer into the kernel space ?

Thanks in advance!
Mario

[Philip_Courtois]

Hi Mario,

As Steven wrote, you will have to create a wrapper-DLL in the case that the driver-DLL has already allocated the buffer for the picture. It's the wrapper-DLL's job to access the buffer from the driver-DLL and pass it into the buffer allocated by LabVIEW. Of course, the most efficient would be to pass the image directly from the driver-DLL to LabVIEW, but your driver-DLL would have to be prepared for this by accepting to pass the image into the buffer allocated by LabVIEW.

I guess the real question is; do you really need to pass the image data from the drive-DLL to the block diagram of LabVIEW? If you take our IMAQ (IMage AcQuisition) VIs as an example, you will notice that they keep the actual image data away from the block diagram layer, and instead handle the images by referencing them through the IMAQ and Vision DLL using the IMAQImage reference. Acquisition, analysis, presentation and storing is all handled by the DLLs so no data intensive passing of the image data to the block diagram is necessary. Only in case you want the actual 2D pixel array instead of the IMAQImage reference, a value passing to the block diagram is necessary.

I hope this clarifies your question.

[DVTAdtran]

Irbenson

I am also looking into creating a driver for Phoenix 66M version frame grabber. Where you successful or are you still working on it? I was also wondering were you got the definitions for all the dll functions.

Thanks for the help in advance.