Efficient way to Pass and Receive Pointers with C/C++ DLLs from LabVIEW

[nathand · Accepted solution]

---

@soljiang wrote:

numeric, unsigned pinter-sized integer was exactly what I set the paramater to be.  

---

Then why did you write "then for SetParameter, I set arg1 to be Adapt to Type,  NOT constant, Handles by value." Again, you shoudn't be using Adapt to Type for the QCam_Handle parameter.

Can you upload your code, showing the actual configuration? Also, why are you trying to build a DLL in LabVIEW that wraps another DLL?

[soljiang]

Oh my goodness.  I misunderstood when you said parameter.  Now I can use the handle!!!  Thank you so much!!!

[soljiang]

Rolf helped a lot too.  I tried to mark both posts as solution but seems I cannot.  NI should add that as an option.  I can only give kudos now.  😛  Thank you both!

[rolfk]

---

@soljiang wrote:

numeric, unsigned pinter-sized integer was exactly what I set the paramater to be.  

---

You claimed differently just in your previous message!

---

In labview library call, I configured LoadDriverAndOpenCamera() return value to be numeric, unsigned pinter-sized integer.

then for SetParameter, I set arg1 to be Adapt to Type,  NOT constant, Handles by value.   But functions in SetParameter() can't use handle that's passed on by LoadDriverAndOpenCamera().

---

At least in C, the nomenclature is very normal:

parameters is whatever is inside the brackets, return value is what the function returns.

[soljiang]

Thank you so much Rolf! I made a mistake when I try to follow your instructions.  Thanks!

[embedded1988]

Hallo,

I am calling functions from a DLL using Call Library Node funtion, passing pointer to a struct (in C++) using cluster in LabVIEW, the function runs properly but the problem is here, when function returns 1 its ok and then VI is stopped, and if i run again the VI funtion returns 0(error according to header file), i have to close to the VI and the start again it works perfect.

Does anybody have an idea how can i overcome the problem of closing the VI and then re-starting it?

rolfk and nathand are welcome!

Regards,

azy

[nathand]

Does the DLL contain some function you're supposed to call to clean up when you're done with it, that you aren't calling? Does the documentation provide any more information as to what the error return value means? It would help if you provide the header file, the documentation for the DLL, and your VI.

[embedded1988]

Hello nathand,

There are 2 functions namely stop and close closely related to each other , tried both with changing positions also but no improvement. returns as told earlier that return 0 means error and return 1 means function's working properly. For security reasons i can't provide the header file and related things but i can make a dummy header same as original as follows:

typedef enum{a,b=2}R;
typedef enum{c,d}D;
typedef enum{e,f,g,h,i,j}RG;

typedef struct {
unsigned short x1;
unsigned short x2;
unsigned int x3;
unsigned int x4;
unsigned int x5;
R r1,r2;
D d1;
RG rg1;
char x6;
unsigned int x7;
bool x8;
} abcd;

Function prototype for start fn is :

int __stdcall Start(abcd* xyz);  //Return 0 is error

In the Call library fn node i am passing a cluster to this start fn and the parameter is set to Adapt to type --->Handles by value.

Regards,

azy

[nathand]

If you are getting correct data on the first call, then you have most likely configured the Call Library Function Node correctly, and the problem is somewhere in the DLL itself. Without documentation and without knowing what other functions are available in the DLL, there's no way to help.

I can suggest some further tests, but I'm not sure what the results will indicate. Can you call the function more than once in a single run of the VI without getting an error? Have you tried the same thing from some other programming language? I would still guess there's some initialization or cleanup function that you need to call, and I can't guess which of Stop, Close, or something else that would be without any documentation or explanation.

If the DLL is written in-house, I highly recommend putting a debugger on it and stepping through with the developer.

[rolfk]

---

@embedded1988 wrote:

typedef enum{a,b=2}R;
typedef enum{c,d}D;
typedef enum{e,f,g,h,i,j}RG;

typedef struct {
unsigned short x1;
unsigned short x2;
unsigned int x3;
unsigned int x4;
unsigned int x5;
R r1,r2;
D d1;
RG rg1;
char x6;
unsigned int x7;
bool x8;
} abcd;

---

You have a lot of compiler specific things going on here. First for enum types the compiler is free to choose whatever it likes between the minimum required size to represent the necessary enum values and whatever it considers the prefered unit of enum.

All your enums can easily be represented by a single byte, but as said, depending on the used compiler it could just as well be an int or in fact even something else. That's not a problem if you use the same C compiler to write the library and the calling applciation but can already cause troubles when you use different compilers.  Generally speaking most 32 bit compilers nowadays will likely use an int for all enums except when they contain enum values > 2^32 but there is no guarantee or requirement in the C++ standard for a compiler to do so.

In the case of LabVIEW as caller,  you are the compiler , and have to tell LabVIEW what these values are, which as pointed out are not exactly specified and have to be found out by trial and error and could easily change if the actual DLL is recompiled by a different compiler.

Then bool, clearly shows that it is C++ but again, the standard does not mandate any specific size other than that it needs to be able to store the 2 states. The only thing that can surely be said is that it is at least one byte since this is the minimum addressable memory location but again, a byte doesn't strictly speaking to be 8 bits. There exist hardware architectures that have different minimum addressable quantities.

C(++) is a very low level programming language that gives compiler builders almost every freedom to adapt it to whatever is best suited for the hardware architecture. That is not a big problem as long as you use the same compiler for the callee code and the caller code, but can produce quite unexpected results if you mix and match compilers in the case of dynamic shared libraries.

So you need to find out what C compiler was used for creating the shared library and what specific values it used. In addition aligning can also pose a problem in some cases although in this specific example it is not a problem but in your real situation it might.