Need to find the memory address of a buffer or string

[nate818]

Two basic questions:

-How does LabVIEW treat the concept of a "buffer"?  Isn't it just a string wired from one block to another?
-How can I find the address of a memory location or buffer location?

I am using the Call Shared Library Node to call two functions to unwrap a custom communication protocol packet.  I will be reading packets of information from the serial port and sending them through this unwrapper to extract the data.  The first function expects as the arguments a)the address of the buffer and b)the length (in bytes) of the buffer.  I can measure the length, but am unsure of the address.  I would have just wired the string output of the serial port to the input of the unwrapper, but the unwrapper wants the address of that string/buffer.  The data type of the buffer address that the function expects is "unsigned char*" in C++ which translates to "uInt8" in LabVIEW according to http://zone.ni.com/devzone/cda/tut/p/id/3009.  The second function that is being called writes the unwrapped data to the destination buffer address that I specify as an argument. 

I located this VI that handles buffering, but am unsure how it would help me, because it doesn't deal with the address issue either (and it used arrays of doubles, not characters or strings which is what the output of the serial port will be).  http://zone.ni.com/devzone/cda/epd/p/id/2499

I use LabVIEW 6.1 on a Mac platform.  Any help would be appreciated.

Nathan

Previous related post: Call Library Function Node: Instantiate a class/handle constructors in a C++ Shared Library?

[tbd]

Hi Nathan,

      Convert the string to an array of bytes (String- Array\Path\Conversion pallet) and then specify the Call Library Function (CLF) parameter as an array of "unsiged 8-bit integer".  Notice the prototype now shows "unsigned char *" !

Drop an "Array Size" size function right-beside the CLF and wire it to the "length" input.

Cheers.

Message Edited by tbd on 01-11-2007 02:35 AM

Message Edited by tbd on 01-11-2007 02:36 AM

Message Edited by tbd on 01-11-2007 02:37 AM

[nate818]

I can't wire the "string to array of bytes" function to the uInt8 of the Call Library Node because the Call Library node is expecting a single uInt8, not a 1-D array of uInt8.  I get the source data type doesn't match sink data type error.  Even if I extracted the data in the array one byte at a time using a For loop, I would be sending the actual data into the unwrapper, not the address of the data.  Any other ideas?

Nathan

[TCPlomp]

---

@nate818 wrote:

I can't wire the "string to array of bytes" function to the uInt8 of the Call Library Node because the Call Library node is expecting a single uInt8, not a 1-D array of uInt8.  I get the source data type doesn't match sink data type error.  Even if I extracted the data in the array one byte at a time using a For loop, I would be sending the actual data into the unwrapper, not the address of the data.  Any other ideas?

Nathan

---

Nathan, you haven't followed Nate's advice:

---

and then specify the Call Library Function (CLF) parameter as an array of "unsiged 8-bit integer".

---

To pass the address you have to configure it in LV (LV will create a buffer with the data and send the pointer of the buffer into the DLL) in LV 8.2 you can select a pointer, a handle and a pointer to a handle.

Don't worry about the address LV will most likely fix this

Ton

[nate818]

Thank you.  You are right, I misread his post.  I'll test it and let you know how it works.

Nathan

[nate818]

I set up the call lib node to expect an array of uInt8 and tried all three: pointer, handle, and pointer to a handle.  Pointer is the only one that didn't cause LabVIEW to crash, but the unwrapper is still not outputing any data.  Any thoughts or suggestions?

Nathan

[tbd]

Use the POINTER Luke Nathan!

Seriously, the Pointer is the right method.

Other things to check: If the DLL wants a Zero-terminated string/buffer, you may have to add a zero-byte to the end of the input [U8] array.  Make sure Length is wired and equals the input array-length.  I'm guessing Length should be passed by Value!(?)  Also, if reading-back a string (or array) then you'll (probably) have to pass-in a string/array at least as big as the result is supposed to be (just fill it with zeros.)

And if it still doesn't work, we're still missing something simple (like an incorrect datatype or calling-convention or broken DLL? .)

... and, thank you for backing me up, TonP!  

Message Edited by tbd on 01-12-2007 12:47 AM

[rolfk]

---

@tbd wrote:

Use the POINTER Luke Nathan!

Seriously, the Pointer is the right method.

Other things to check: If the DLL wants a Zero-terminated string/buffer, you may have to add a zero-byte to the end of the input [U8] array.  Make sure Length is wired and equals the input array-length.  I'm guessing Length should be passed by Value!(?)  Also, if reading-back a string (or array) then you'll (probably) have to pass-in a string/array at least as big as the result is supposed to be (just fill it with zeros.)

And if it still doesn't work, we're still missing something simple (like an incorrect datatype or calling-convention or broken DLL? .)

... and, thank you for backing me up, TonP!  

Message Edited by tbd on 01-12-2007 12:47 AM

---

Since the DLL function also wants the buffer length I doubt that it is expecting a zero termination character. But who knows! Maybe the OP misunderstands the function documentation (has he read that at all?).

If you really need zero termination you can do that yourself or just pass the string as string and configure the Call Library Node parameter to be a String too and use the C style String pointer type there. LabVIEW will take care to append a zero byte before passing the string pointer and if you also wire the output side of that parameter copy the contents from that pointer back into a string handle up to the first zero byte. It is obvious from this that a string buffer is not the right thing to pass to a CLN in LabVIEW if that buffer can legally contain zero bytes too. 

Rolf Kalbermatter

[TCPlomp]

TBD, now I got at least your name

Ton