NI-CAN Import LabView DLL into C# (Labview special types, Path, Eror)

[osanhuez]

Hi guys.

I'm currently using the NI-CAN hardware for LIN comunication with some devices. As a requirement I have to use C# under .net to implement everything. It has not been a problem to import the nican.dll into the .net enviroment as there is full documentation already for C. My problem is now when I'm trying to use the LDFRead.dll from the LDF Starter Kit 1.0. As the documentation in the Kit is only develop for LabView and not to C and there is not Header neither Lib file the importing to c# enviroment is getting really paintfull.

Basically, my problem is that i don't know how to translate the types used in the Labview to C# types. functions are really simple, for example LDFOpen, which use as input a PATH (location of the LDF file), in error and out error. So starting for this I start to get problems. Seems that path is an special labview Type and i don't know how to translate it, also this error in out must be some kind of structure because it has a bool, int and string inside. Again not idea which size of string for example, should I create my one structure to pass and get that info?

Any help with the subject will be really greatfull.

BR.

Oscar Sanhueza

[rolfk]

I guess you mean Path and not PATH as datatype? Anyways you are in a bit of a problem here. These datatypes are very special datatypes and use LabVIEW handles. If you would know that the DLL is only going to peak at these datatypes but never modify them in anyway you could simulate those datatypes but the mentioning of error in and error out does suggest that the DLL does actually use LabVIEW error clusters and one element in there is a LabVIEW string handle and since it is also output it is likely that the function can and will modify that handle at some point when an error occures. However in order to do so it will try to link dynamically to the LabVIEW Memory Manager functions that the calling process is supposed to provide.

Since your calling program is not a LabVIEW moduleyou do not have those Memory Manager functions exported and you will receive a dialog box that this DLL has not been called by a LabVIEW program or LabVIEW runtime application and needs to be shutdown. There is really not much you can do, but to investigate for a different API that does the same functionality but does not use LabVIEW datatypes in its interface.

[osanhuez]

Rolf

Thanks for your fast answer, i got clear that the dll was develop entirely for LabView development. I was thinking in any case, would be possible to develop a second dll in LabView usgin this dll and that the complex datatypes where simplified, for example replace the Path for and string and just use string.topath() labview fuction, also just separate the erro cluster in 3 different variables and pass poniters to them so i can access them in case there is an error?

I really have been looking for another solution for this problem but still not found anything that could solve this LDF reading problem in a fast way. I know that implement it would take long, but I'm in the need to implement so many other things that it would be great to just forget it.

[rolfk]

Well you could create a LabVIEW DLL wrapper that consists bascially of VIs that simply export the DLL API but then with C compatible parameters. It would be quite an ineffcient solution but probably the quickest if you can't find the C compatible API of your DLL.