LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

input to C++ DLL function that requires struct of *void written to by the DLL

Solved!
Go to solution

Hello!

 

I've spent the last week reading in the forums and playing around with data types but can't seem to get things right.

I want to read an image from a sensor with a function get_buffer defined in c++, the inputs and description of the function is attached.

 

To do this I have defined a Call Library Function as seen in the image:

call_library-function.png

The problem Im having is to choose the correct types for the inputs to the Call Library Function.

There might very well be more things that are wrong here but the  first and second row of the struct tImageInfos are void * hbuffer and void * pDatas which are in the header file decribed as 

 

pDatas.png

 

and I need to access the information stored in pDatas which should be a n*2024 pixel image (each pixel is 12 bit stored with LSB in 2 bytes) where n can be chosen earlier in the program, and perform some operations and plot one line of pixels. What type should I use for them?

 

get_buff_vi.png

I've attached the VI, some documentation of the api as well as the header file and some example c++ code that uses the get_buffer function in a zip.

 

Thank you very much for any help in this!

 

Hampus

 

0 Kudos
Message 1 of 6
(2,881 Views)

You cannot pass pointers to arrays inside clusters. In this case that is also not the intended usage of the function. The first two cluster elements must be pointer-sized integers - so either u32 or u64, depending on the library bitness. This is also true for all pointers and size_t arguments (CAM_HANDLE, iBufferSize, ...)

The function will fill the cluster. Then you take the pointer to the image data (pDatas) and copy it into Labview using MoveBlock (see Special Case: Dereferencing Arrays here: https://forums.ni.com/t5/Developer-Center-Resources/Dereferencing-Pointers-from-C-C-DLLs-in-LabVIEW/...).

0 Kudos
Message 2 of 6
(2,840 Views)
Solution
Accepted by topic author HampusM

There are more potential problems to this VI than just that pointer. For one there is an alignment problem in the structure since the data elements have different sizes. This means that the structure needs to be padded with filler bytes.

 

Also size_t and all the pointers/handles will be 64 bit if you ever are going to use this with a 64 bit DLL in 64 bit LabVIEW. Last but not least you are required to pass back the buffer handle to the DLL after you are done reading the buffer pointer or the system will run out of memory.

get_buffer.png

Rolf Kalbermatter
My Blog
Message 3 of 6
(2,813 Views)

Hi and thank you so much Rolf for you detailed and fast response! I can't stress enough how happy I am that you are helping me with this.

 

I did all changes you suggested:

- Alignment in the struct looks fine now with your added fillers

- You are right, I've changed all size_t and pointers to U64 (pointers set as "unsigned pointer-sized integer" at the parameter definitions) (in this and all other VIs), I run LabVIEW on 64 bit now and the DLL seems to as well

- The buffer handle was returned vie USB3_RequeueBuffer in the main vi before, I now changed it as your suggestion.

2_get_buffer.png

There still seems to be some problems though..

When i read the output data it looks like nonsense, or atleast that it does not come from the camera sensor. It doesn't show a difference whether I'm covering the camera or not. Theres a suspiciously high amount of zeros in the array. When I read the output several times in a row in a loop as seen in my main VI it gets the same data each time. I saved the measurement from some iterations in a .txt file which is attached. 

2_main_block.png2_fronpanel.png

 

It does however seem like I can communicate with the DLL otherwise, e.g. in set_image_params, I write the number of rows of pixels, and the same number is read by USB3_GetBuffer correctly. This suggests that its pDatas/output data that is still somehow configured incorrectly?

 

Thank you so much for your time,

Best regards,

Hampus

 

 

Download All
0 Kudos
Message 4 of 6
(2,781 Views)

I did take a quick look and there are folowing errors that I could find with a quick check:

 

- The MoveBlock function: The first parameter must not be  Pass: Pointer to Value but instead Pass: Value. The pointer from the structure is already the pointer and does not need to get dereferenced another time.

- Don't use the size parameter as length indication for the configuration of the second parameter for MoveBlock. The array is an array of u16 values while the size parameter is meant to be bytes. It's not causing a failure but instead will resize the array to contain 2 times as much elements as are really needed only to cut them of later in the Resize Array node.

- Why don't you wire the timeout parameter to a control on the front panel that is connected to the connector pane? The functionality is there, why not make it available to the caller of this library?

- Probably not a problem but still better to do: You should not use the iImageWidth to resize the 1D array to a 2D array but the iLinePitch MOD 2. This is the effective length of each line in bytes as most image processing libraries align lines to either a 16 bit or 32 bit memory address for more efficient CPU processing. This means that iLinePitch might not be exactly pixelSize * iImageWidth. It can mean that the image returned like that contains one or more pixels at the end of each line that are not really valid image information but it's how the data is aligned in memory.

 

Also the function as is will only work for 10, 11, and 12 bit images but not for 8 bit images.

Rolf Kalbermatter
My Blog
Message 5 of 6
(2,763 Views)

Thank you again Rolf, the double dereference of the moveblock param was indeed the culprit! Now it works!

 

Thank you also for the other comments, the camera will be used in 12 bit so that shouldn't be an issue. 

 

FYI you have helped in making possible research in migration moths' flying pattern.

 

Best regards,

Hampus

0 Kudos
Message 6 of 6
(2,746 Views)