LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIIEW discards null character and subsequent bytes received from DLL

I am using LabVIEW 7.1 with a Sealevel 5101 Synchronous Serial card to communicate to my device in High-Level Data Link Control (HDLC) protocol. The vendor Sealevel has provided a DLL, which is used in conjunction with the Call Library Function Node to talk to the card. Right now I have a loopback plug installed on the card and I am trying to read the data back that I just sent out.
 
The data transferred to and from the DLL by using a string with the data in Hex Display format. The data transfers fine unless a \00 (null character) is involved. The null character and any hex bytes after null character are discarded. I requested support from NI since Monday but they did not come up with anything to resolve this problem!
 
We wrote a program in VB and read the data without a problem including the null character.
 
 
0 Kudos
Message 1 of 7
(3,811 Views)
Can you provide me the Service Request number that you were given when you contacted support?

I suspect the problem is that you have set up your call library function node to return a C string.  C strings are terminated by a null character, so any data after a null character would be discarded by LabVIEW (or any C string reading application).
Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 2 of 7
(3,799 Views)
I tried both NI support's suggestions:

1. Converting the the sting using String To Byte Array function which had the same results as before
 
2. Changing the string to an Array of Unsigned 8-bit Integers which caused an empty array to be received from the DLL
 
My support # is 7174271
0 Kudos
Message 3 of 7
(3,787 Views)


@Nick111 wrote:

2. Changing the string to an Array of Unsigned 8-bit Integers which caused an empty array to be received from the DLL


When you are providing a U8 Array as the input to a DLL call which is supposed to return a string, you need to preallocate memory for the array.  For example, if you know your string will be no longer than 256 bytes, you need an array with 256 elements in it passed into the DLL call.
0 Kudos
Message 4 of 7
(3,781 Views)
Preallocating memory for the array did the trick.
 
Thanks Matthew!
0 Kudos
Message 5 of 7
(3,769 Views)
Glad you got it up and running.  It looks like the AE you were working with has been in contact with you also so I won't need to follow up with that.

If your DLL is going to be modifying any arrays/strings data, it is always a great idea to preallocate memory (in fact, in many cases it is a requirement if you don't want to crash).  However, some programmers don't want to have such a rigid requirement of knowing how large of an array to allocate before calling your external code.  For more advanced applications you can call into LabVIEW's memory manager (from your DLL) to have LabVIEW allocate data for you and return it to your application.  This is one of the more advanced topics in LabVIEW, but if you are interested be sure to check out the LabVIEW fundamentals help on calling external code.  Specifically, the Memory Manager topic is useful, and this (little out of date but) great example.
Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 6 of 7
(3,742 Views)

Travis

Both the Memory Manager help topic and the 'Passing a Variety of Data Types from DLL to LabVIEW' example were excellent!

Thanks

Nick

 

0 Kudos
Message 7 of 7
(3,730 Views)