LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PICAM SDK, Call Library Function, crashes LV

Solved!
Go to solution

Alright! I guess, since there is no Boolean type that I can specify for the dll-node in LabVIEW, your recommendation would mean that I should choose 'Adapt to type' option and then explicitly connect Boolean indicator. I tried that and it also works! It seems to be the cleanest way of doing this.

0 Kudos
Message 51 of 89
(1,905 Views)

Absolutely not! A LabVIEW boolean is an 8-bit value and then you will get the same problem as when you had the parameter set to be an int8!

Set it explicitely to 32-bit integer passed as pointer to value! Then use an Not-Equal to 0 node in LabVIEW and output a boolean to the caller. To be super safe also wire an explicit 0 integer constant to the left side of that parameter to make sure all bits are cleared so even if the DLL function might decide to only write a single byte into the address, the returned value is still correct. You may think this is paranoid programming, but it is just safe programming to avoid problems with called code that might not adhere to their self declared specification of the API interface.

 

My comment was about if you want to provide an explicit boolean accessor in LabVIEW then make it use a boolean towards the caller. You can't change the interface to the DLL itself at will. But you can make the wrapper VI that provides functionality to users better correspond to what LabVIEW users would expect rather than saddling them with C programming details that he/she shouldn't have to care about. Why should you create a Boolean accessor when you then go and return an integer and have to specify to the user: If this value is 0 the boolean attribute is FALSE, otherwise it is TRUE (and yes the numeric value could be something else than 1 so never ever compare explicitly to that value!).

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 52 of 89
(1,901 Views)

Thanks Rolf for the guidance, I really appreciate it! I actually started thinking that why the camera manufacturers could not create a LabView SDK in addition to just providing dll-libraries and h-files 🙂

0 Kudos
Message 53 of 89
(1,895 Views)

OK, the last parameter I would like to implement the GET-method for is 

PicamParameter_Rois

Now I am trying to get the values after they have been set.

 

Blokk has implemented type defs (ctl) for Rois so I just used them. They seem to be correct in terms of the order of elements inside clusters and data types (all integer 32 bit). To initialize the type for the output, I wire the corresponding cluster as an input to the Rois-terminal while wiring Rois ctl as an indicator to the output of the dll-library node (please, see screenshot below). The proper values seem to be retrieved but after one second or so LabView crashes due to a Memory problem.

Could you please advise where the issue could be? I tried the first three Data Formats in the corresponding drop-down menu but the effect is the same. I have a feeling that the issue is rooted in the Pointer to the Pointer to the Value, but I am not sure how this could be told to LabView.

 

snippet1.png

 

This is the error message that I get:

 

snippet2.png 

 

P.S. Below is the screenshot of Set- and Get-clusters right before LabView crashes. Set-method was implemented by Blokk and works fine. The values seem to be messed up. I am trying to get the values after they have been set.

 

Snipped3.png

 

0 Kudos
Message 54 of 89
(1,886 Views)

Well, now you work with pointers and memory allocated by the DLL function itself. That is not something that you can do with LabVIEW diagram controls. Basically the only way to deal with this is by configuring this parameter as pointer sized integer passed as pointer to value.

 

Then you need to copy the data out of this pointer. And this starts to get nasty. Basically you need to deal with calling MoveBlock() from LabVIEW to first copy the first 4 bytes into an int32, lets call it count. Then you need to copy 4 more bytes (for 32-bit LabVIEW) and 8 more bytes (for 64-bit LabVIEW) out of this pointer. This second parameter is a pointer from which you need to copy count * 24 bytes into a LabVIEW array of PicamRoi Clusters which you have preallcoated (Initialize Array) to count elements. After that you need to call Picam_DestroyRois() on the pointer you received from the Picam_GetParameterRoisValues().

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 55 of 89
(1,874 Views)

Thank you Rolf, I will try to digest everything you have written to the maximum extent and implement the logic.

0 Kudos
Message 56 of 89
(1,872 Views)

This is how that VI should look like:

Picam_GetRoi.png

 

I added both the Picam:GetRoi.vi and Picam:SetRoi.vi in the ZIP archive since the Get had an error too.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 57 of 89
(1,864 Views)

Thanks a lot Rolf for the subVIs, it would definitely take me a while to realize them. I think I will meditate on them a bit to understand exactly how it works in LabVIEW. Anyways, up to now the GET-methods for all PIXIS-relevant parameters have been implemented, so I will move on to implementing SET- and other methods that are not in the library yet. Most likely, I will be back soon! 🙂

0 Kudos
Message 58 of 89
(1,823 Views)

OK, few more functions left to implement before I can share the extended SDK 🙂

Now I am stuck at the GET and SET functions for the buffer memory allocation. Here is the snippet from the picam_advanced.h:

 

 

 

/* Camera Acquisition Setup - Buffer -----------------------------------------*/
/*----------------------------------------------------------------------------*/
typedef struct PicamAcquisitionBuffer
{
    void* memory;
    pi64s memory_size;
} PicamAcquisitionBuffer;
/*----------------------------------------------------------------------------*/
PICAM_API PicamAdvanced_GetAcquisitionBuffer(
    PicamHandle             device,
    PicamAcquisitionBuffer* buffer );
/*----------------------------------------------------------------------------*/
PICAM_API PicamAdvanced_SetAcquisitionBuffer(
    PicamHandle                   device,
    const PicamAcquisitionBuffer* buffer );

 

 

 

 

And here is my trial which gives a Handle-error.

 

Snipped1.png

 

I checked by probing that the handle is correct. I am also not sure how I should handle *void. Both GET and SET methods produce similar error. Could you please help me to spot the problematic place?

0 Kudos
Message 59 of 89
(1,788 Views)

OK, few more functions left to implement before I can share the extended SDK 🙂

Now I am stuck at the GET and SET functions for the buffer memory allocation. Here is the snippet from the picam_advanced.h:

 

 

/* Camera Acquisition Setup - Buffer -----------------------------------------*/
/*----------------------------------------------------------------------------*/
typedef struct PicamAcquisitionBuffer
{
    void* memory;
    pi64s memory_size;
} PicamAcquisitionBuffer;
/*----------------------------------------------------------------------------*/
PICAM_API PicamAdvanced_GetAcquisitionBuffer(
    PicamHandle             device,
    PicamAcquisitionBuffer* buffer );
/*----------------------------------------------------------------------------*/
PICAM_API PicamAdvanced_SetAcquisitionBuffer(
    PicamHandle                   device,
    const PicamAcquisitionBuffer* buffer );

 

 

And here is my trial which gives a Handle-error.

 

Snipped1.png

 

I checked by probing that the handle is correct. I am also not sure how I should handle *void. Both GET and SET methods produce similar error. Could you please help me to spot the problematic place?

0 Kudos
Message 60 of 89
(1,784 Views)