Jump to content

Implementing complex structs using clusters


Recommended Posts

Thanks to this amazing community I've almost fully wrapped a gige-cam api in labview. I was able to pass clusters as structs to function. My next question would be how to tackle more complex structs? I have the C-struct and want to model this in LV and pass it to the function. I know how to model simple structs but this one has a nested structure and makes use of a union. I tried to model it like the following but this doesn't seem to work. My program is not crashing but my .so function returns an unkown error.

 

struct.png.c306f654b351bd2dff7c282406a90df1.pnglabview_implementation.png.658820aca1d4ae732511b0f123d241f4.png

Link to comment

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct.

Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details).

Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

 

Edited by dadreamer
  • Like 1
Link to comment
On 5/3/2023 at 2:01 PM, dadreamer said:

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct.

Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details).

Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

Totally correct so far but you forgot that size_t is also depending on the bitness, not just the pointers itself. So these values also either need to be a 32-bit of 64-bit integer value.

  • Like 1
Link to comment
14 hours ago, Rolf Kalbermatter said:

but you forgot that size_t is also depending on the bitness, not just the pointers itself

For that I have left this sentence with a reference to your message and the next ones after:

On 5/3/2023 at 5:01 PM, dadreamer said:

The same applies to size_t parameters (read here for details).

But I would say that size_t type rather depends on a target bitness, than on a platform bitness. On 32-bit OS we can compile 32-bit applications and cross-compile 64-bit ones, if supported by the compiler. On 64-bit OS we can freely compile both. So sizeof(size_t) is either 4 bytes for 32-bit target or 8 bytes for 64-bit target. I've just checked that in MS Visual Studio.

  • Like 1
Link to comment

Yes it of course depends on the target you are compiling for. The actual application target, not the underlying OS. It's the same for pointers and size_t datatypes (at least in any system I know of. There is of course theoretically a chance that some very obscure compiler chooses a different type system. But for the systems that are even an option for a LabVIEW program, this is all the same).

Edited by Rolf Kalbermatter
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.