Loadlibrary failed, with the FunctionName having UserDefined DataStructures

[Rajeswari]

Hello , i have a COM Dll Which is having different functions. When I loaded the dll using Call Library function node, it is successful. But while selecting my Exposed function which is having UserDefined DataStructures it is giving Labview Run time error. But it is allowing other functions that do have the primitive data types. Can you please tell me how to overcome my problem? Here I am attaching my Com Dll please check it. There are 3 functions which use UDT's ie. IIinitializeCanCardDriver, ICAN_Write and ICAN_Read functions. Please let me correct if I am wrong path.

And can you let me know what are the other problems that may cause due to UDT's access from Labview.

[Rolf Kalbermatter]

QUOTE (Rajeswari @ Nov 30 2008, 06:31 AM)

Hello , i have a COM Dll Which is having different functions. When I loaded the dll using Call Library function node, it is successful. But while selecting my Exposed function which is having UserDefined DataStructures it is giving Labview Run time error. But it is allowing other functions that do have the primitive data types. Can you please tell me how to overcome my problem? Here I am attaching my Com Dll please check it. There are 3 functions which use UDT's ie. IIinitializeCanCardDriver, ICAN_Write and ICAN_Read functions. Please let me correct if I am wrong path.

And can you let me know what are the other problems that may cause due to UDT's access from Labview.

First a DLL alone does not help much really! It seems to be a combined COM/standard DLL, meaning it exports both a COM/ActiveX interface and a standard C function interface. It even seems to contain the selfregistration for the ActiveX interface so that you can register the DLL using regsvr32 "<path to your DLL". It might possibly even include the necessary typelib, that allows you after registration of the DLL to use that ActiveX interface from LabVIEW using LabVIEW's ActiveX interface.

The C interface however, that you are trying to access through Call Library Node does usually not have any information about the actual interface. It just exports the function name and leaves the rest up to the caller. You can use the External Library import wizard in LabVIEW 8.2 and higher if you have the header file for the DLL and in 8.5 this wizard is even able to import more complex function prototypes but all automatic translation has to end somewhere and the import wizard usually chokes on very involved function parameters. This means not necessarily that the function can't be imported in LabVIEW using the Call Library Node, but it usually means that it can't be done without some complicated vodoo techniques that are out of question for anyone without very good C understanding. And someone knowing C good enough to be able to apply those voddo tricks will almost always chose to write an intermediate DLL that translates between the complicated C function parameters and somewhat more LabVIEW friendly parameters.

So a DLL alone is of absolutely no help without the according header file if you want to import the standard C functions from a DLL using Call Library Node. And often the header alone is not enough either since the C syntax is ambigious enough that the meaning of some parameters can be only determined by studying C example code or reading a thorough documentation about the function (with the latest being seldom available).

My advice if you are not a seasoned C programmer: register the ActiveX interface of the DLL and try to use that instead, using the ActiveX interface in LabVIEW.

Rolf Kalbermatter