12-15-2024 08:07 AM - edited 12-15-2024 08:12 AM
Adapt to Type has a very specific meaning:
LabVIEW internally uses its own specific memory layout for all its datatypes. For most like numeric scalars, it is in fact more or less exactly equivalent to what the C compiler uses. For arrays, and strings LabVIEW has its own specific way of handling them in the form of handles. A handle is simply a double pointer to a memory location that first contains an int32 for every dimension (a LabVIEW string is in that context also simply a 1 dimensional array of bytes). Directly thereafter comes the actual array data.
When you configure a Call Library Node parameter as Adapt to Type, LabVIEW simply passes its own native data directly to the shared library function without any translation. And your C code better is prepared to deal with that data EXACTLY as LabVIEW requires it. If you configure the parameter instead explicitly as string or array of something, you only can connect that specific type to it and you get additional options to configure that LabVIEW should only pass the pointer to the actual data instead of its entire native structure. And if passed as such you have more restrictions what you can do with that pointer in the C code.
How do I know what data type I should use in my C code if I configured a parameter as Adapt to Type?
Quite simple actually: Configure your Call Library Node as desired, connect all the parameters configured as Adapt to Type to a native LabVIEW control or constant, then right click on the Call Library Node and select "Create .c File...". In the file dialog select what file you want to write to and then look at that file in your favorite text editor. You see exactly the type declarations and the function declarations that match the current Call Library Node and can copy paste them into your C project.
But watch out. If you make changes to the LabVIEW control that is wired to an Adapt To Type parameter, this changes the type that is passed to the shared library and if you don't change your C code accordingly, you just created a crash generator.
Basically the LabVIEW array handles is similar in their functionality to a Matlab mxArray, but of course not the same. Your C code needs to properly translate between the two, and that needs to happen in a way that honors both management contracts for the LabVIEW handle and the Matlab mxArray exactly. It can result in more or less involved code needed when interfacing two different managed environments with each other like in this case.
12-16-2024 01:54 PM
Dear, Rolf,
I'll try to study your suggestions and make some tests (not so easy for a non-specialist like me...)
Thank you!
Fabio