Use of Call Function Node vi, with char type pointer

[safe]

I want to be able to use a certain function from C++ DLL, and I followed the TOOLS>>IMPORT>>SHARED LIBRARY(.dll) wizard.  Where I located my header file and the dll file.

However i am getting an error (1097).  This is the function with the paramaters:

void Function_Name(unsigned char *L, unsigned char *H, unsigned in Len, unsigned char Adr);

I don't think, that I configured my Call Function Node, correctly.  How should i set the paramaters settings of the first 2?  I have tried Numeric, unsigned (and signed) Int (32, 16), pass pointer value.  to accomodate the first two varaibles. 

Please someone help, what should I do to accomodate the unsigned char pointers, so that I can used the function in labVIEW?

[intvsteve]

Hi,

Are your unsigned char * variables arrays of bytes, or strings? You may need to just configure the node to use an array by pointer setting, with a data type of unsigned byte.

[tbob]

Unsigned char* in C is usually used for strings.  Problem is that C uses the NULL character (0x00) as a end of string signal.  Labview doesn't view strings this way.  If you know what your maximum length string would be, in Labview you could create an array of U8 (same as unsigned char in C) with that number of elements in the array, and initialize all elements to NULL (numeric 0).  Pass the array to the DLL as a pointer to array.  When passing a string to the DLL, your numeric array would have to contain the ASCII equivalent of the characters, with NULL at the end.  When receiving the array back from the DLL, you would have to convert all numerics into characters up until the NULL character.  I am not sure this will work, but its worth a try.

[intvsteve]

Typically in C, strings are plain old char *. IIRC, back long ago on the Mac, they were unsigned char *.

Regardless, you can also choose to pass a C-style string to a DLL if you choose the 'string' type. LV will handle the conversion for you, adding the NULL terminator, etc.

FWIW, before the Call Library Node had that feature, I did what tbob mentions. LV has 'string to byte array' and 'byte array to string' functions. You could append a '0' byte to the end and pass by array data pointer, and that's the equivalent of an unsigned char * that contains a string.

[tbob]

I didn't know about the C-style string choice.  I haven't used Call Library in a while.  This forum is so full of good information. 

[safe]

Hi intvsteve,

My whole purpose is to prove I can do the same thing and better with LabVIEW than VEE.  However I am really trying to get this dll working.  Sorry about the real quick message full of errors posted earlier.  I am trying to get started with LabVIEW quickly and have people here start with LabVIEW instead of Agilent VEE.  Honeslty for sure this works with VEE 7.5.

Yes it is a unsigned byte, but a pointer so it points to the address of the unsigned byte.  I tried what you have asked in the configuerations, but still was not lucky to get the ball rolling.  I still get error 1097. 

I selected Array, Array Data Pointer, and one of both (4 byte  or unsigned 32 bit).  It still did not work.  Can you tell me exaclty how I should configure my paramater to be able to use the function in my DLL.

Here is the function again:

void Function_Name(unsigned char *L, unsigned char *H, unsigned in Len, unsigned char Adr);

Thanx,

Safe

[tbob]

Sometimes errors are caused by selecting the wrong Calling Convention.  The two choices are C and WINAPI.  Try both.

[intvsteve]

Hi Safe,

The error you're encountering has the following description (I'm sure you've already looked this up-posting here for clarity for other readers):

LabVIEW:  An exception occurred within the external code called by a Call Library Function Node. This might have corrupted LabVIEW's memory. Save any work to a new location and restart LabVIEW.

Typically, this happens for one of just a few reasons:

1. Memory was overwritten (e.g. you passed a buffer of N bytes, but N+X bytes were modified, and an exception was thrown.
2. A bad pointer was passed. (This is probably not the case.)
3. Arguments were not passed to the function properly. (Calling conventions)
4. Function wasn't called from the proper thread.
5. Some other reason (only can be determined by inspecting in a debugger).

I've attached some pictures of how I'd configure the dialog, but there are two critical things you have to know: calling conventions and thread safety. Those are things defined by the DLL. In Windows, C vs. 'Standard' (a.k.a. Pascal) calling conventions MUST be correct, as they affect how arguments are passed on the stack. If this is wrong, then, for example, where arg1 is expected to be an unsigned char *, you may actually only pass an unsigned char. Dereferencing that number as a pointer will at best crash, at worst appear to be a valid address and silently corrupt memory.

I suggest double-checking the calling conventions. 'stdcall' is still quite common, but not the default setting in the Call Library Function dialog.

Best regards,

intvstefve

[safe]

Hi Invsteve,

Thanks, and yes I have read the code, but you gave me a good detailed information about the error.  I know it has some thing to do with calling conventions.  So I did exaclty as you did and i have the attachments to show it.  Can but the function in the bottom is still not char pointer. 

maybe you see something that I don't, thanks for your help...I know soon we will find the problem.

Thanx,

Safe

[intvsteve]

Whether it's 'unsigned uint8_t *' or 'unsigned char *' or  int8_t*' shouldn't cause an exception -- they are all pointers to blocks of data containing 1-byte sized elements.

I am curious how you're sizing the array you send in. Do you have an array on the diagram you've initially sized, then pass the 'array size' value as the third argument? And, I presume that both 'H' and 'L' are the same size (Len)?.

Also, in your first post, you indicated a function prototype of:

void Function_Name(unsigned char *L, unsigned char *H, unsigned in Len, unsigned char Adr);

I'm assuming that 'Len' is an unsigned int, which you've properly set to a uInt32... is the fourth argument a char or a 32-bit integer? Again, passing the wrong argument by value (a uInt32 vs. a uInt8) will mess up the stack, and cause trouble.

Best regards,