Passing data to a dll via CallLibraryFunction Node

[MattK78]

Hello,

I am attempting to pass an array to a C dll by using the CallLibraryFunction Node.

This dll is a wrapper for another dll that is decidedly object oriented and thus incompatible with the CallLibraryFunction Node vi. The wrapper dll (source and header attached) flattens out these objects into structs and arrays.

The trouble is that I continue to get a library error, claiming invalid data format when attempting to call the ReadRegisterData Function. However I'm passing what I understand to the simplest (i.e. versatile) data form, a pointer to an array of unsigned bytes.

I've also attached the VI that I am using to call this function, written in LabVIEW 2025.

Ideally I'd contact the manufacturer for support and get clarification on the error that I'm receiving. I have attempted to do so twice now though and received no response, leading me to trial and error and consulting with the LabVIEW forums for best practices when passing array/struct data to dlls from LabVIEW.

Thank you in advance for any advice you can offer.

[Martin_Henz]

If you save the VI for an earlier version of LabVIEW (2021 or earlier), then I'll take a look on it.

I can't say much about it based on the .c and .cpp files alone. It looks a bit strange to me. I would have done it differently.

[MattK78]

Hi Martin,

Thank you very much for your interest. I have attached a version of the VI saved in LabVIEW 2021.

I agree that this is a strange way to do it but I don't have access to the source code of the base dll and so it was necessary to write this intermediate dll to bridge the gap.

[Martin_Henz]

I forgot to ask one important question: Are you using LabVIEW 64 bit or 32 bit?

[MattK78]

64 bit

[rolfk]

What's the purpose of assigning the returned object class pointer to a void pointer original_object and then typecast that to your own pseudo virtual table to call the functions?

That's asking for serious problems, since your own made up virtual table may or may not match the one the DLL itself uses. And what the DLL uses depends not only on the definition of the class in the header but any parent class that class may inherit from. And to make matters even more interesting there are differences in how and where virtual table pointers are stored depending on the compiler used to compile the code.

What you should do is to define original_object as the actual class object datatype and simply call the class methods as real C++ methods. Your  ConnectTLWrapperCpp.cpp file is fully C++ compiled and can call C++ methods properly without problems.

The fact that you define the function exports as __declspec(dllexport) will make sure they are properly exported and the fact that you wrap them in extern "C" will make sure they are not name mangled even if you compile the according cpp file with the C++ compiler. So there is no reason to try to create handcrafted virtual table structures to map them to the C++ class object. Just use that object as a real C++ class directly in your code.