LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I get an unsigned char string with nulls from a dll into LabVIEW 6i?

The following ethernet packet data is contained in an unsigned char * string returned from my dll (it's formatted on printing):

Received A 230 Packet On Adapter 0x008F0070
Ethernet Dest: 01.E0.BB.00.00.15 Src: 00.E0.BB.00.DD.CC Type: 0x8868
000000: 01 E0 BB 00 00 15 00 E0 : BB 00 DD CC 88 68 48 41 .............hHA
000010: 00 E0 BB 00 DD CC 80 B3 : 00 00 FF FF 00 02 00 01 ................
000020: 01 00 F0 18 FF 7F 7F FF : FF 7F 7F FF FF 7F 7F FF ................etc., etc.

However, when I read this string into LabVIEW 6i, I only get the following:

01E0 BB

Which is the data before the first NULL or 00 information. I found a "Remove Unprintable Chars.vi" but it
just sees more data before the above string, nothing after, as seen here: 5C30 31E0 BB.

Anybody have any suggestions for how to get the rest of the string? Is there something I can do to further reformat my dll? The dll I'm using is already a wrapper around another dll so I have some flexibility, but the bottom line is, the data I want is in the format of an unsigned char *.
0 Kudos
Message 1 of 28
(3,807 Views)
Hi,
there's only two options I can think of, both requiring modifications to the DLL.
Firstly (and easiest) is to return the data in the format of an array of numbers (Unsigned 8 bit). You can then use the byte array to string.vi inside LabVIEW to convert it to your desired format. You should find that the NULLs (00) then appear correctly inside the string - to prove it just put the byte array to string.vi down and create the appropriate control and indicator. Fill in a few of the array elements with say 65, 66, 00, 67, and 68 and you should see (when run) AB CD in the string indicator - if you look at the '/' codes view it should then be AB/00CD.

The other option is to replace every NULL inside the .dll's returning data to be another character - preferea
bly one that is never used. The downside is that although the data will appear in LabVIEW complete, you'll then have to strip out the replacement character before you make use of the data.

Hope that helps

S.
// it takes almost no time to rate an answer Smiley Wink
Message 2 of 28
(3,801 Views)
Hi,

There is a third option:

Use windows lstrcpyn from kernel32.dll. This copies a pointer to mem to a
string, if configured correctlly.

This still stops when a \00 is encountered. So if it stops, add \00 to the
string, add the length of the string (incl. \00) to the pointer, and use the
new pointer to do the same. While doing this, concatinate the returned
strings.

Repeat until satisfied (enough chars have been returned, or a EOF is found.
The EOF can be anything).


Regards,

Wiebe.



"SachaE" wrote in message
news:50650000000500000037950000-1027480788000@exchange.ni.com...
> Hi,
> there's only two options I can think of, both requiring
> modifications to the DLL.
> Firstly (and easiest) is to return the data in the format of
an array
> of numbers (Unsigned 8 bit). You can then use the byte array to
> string.vi inside LabVIEW to convert it to your desired format. You
> should find that the NULLs (00) then appear correctly inside the
> string - to prove it just put the byte array to string.vi down and
> create the appropriate control and indicator. Fill in a few of the
> array elements with say 65, 66, 00, 67, and 68 and you should see
> (when run) AB CD in the string indicator - if you look at the '/'
> codes view it should then be AB/00CD.
>
> The other option is to replace every NULL inside the .dll's returning
> data to be another character - prefereably one that is never used. The
> downside is that although the data will appear in LabVIEW complete,
> you'll then have to strip out the replacement character before you
> make use of the data.
>
> Hope that helps
>
> S.
0 Kudos
Message 3 of 28
(3,801 Views)
I would do as SachaE suggests, but just read it in on the LabVIEW side as a U8 array. If this works for you, then you don't have to change your DLL at all (besides, a U8 in C is a char anyway). Then, just change the array to a character string.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask
0 Kudos
Message 4 of 28
(3,665 Views)
Excellent advice, this mostly works so I have some further questions:

I am just reading network traffic off my ethernet card right now, but here is what I get using my C program to test:

000000: 01 E0 BB 00 00 15 00 E0 : BB 00 DD CC 88 68 48 41 .............hHA
000010: 00 E0 BB 00 DD CC 80 B3 : 00 00 FF FF 00 02 00 01 ................
000020: 01 00 38 3C FF 7F 7F 7F : 7F 7F 7F FF FF 7F 7F FF ..8<............
000030: FF 7F 7F FF FF 7F 7F FF : 7F 7F 7F FF FF FF FF FE ................
000040: FE FF FF FF FF 7F 7F 7F : 7F 7E 7E 7F 7F 7E 7E FF .........~~..~~.
000050: 7F 7F 7F 7F FF 7F 7F 7F : 7F 7F 7F FF FF 7F 7E 7F ..............~.
000060: 7F 7F 7E 7F 7F 7E 7F FF : FF 7F FF FF FE FF FF FE ..~..~..........
000070: FF FF FF FF FF 7F 7F FF : FF 7F 7F FF FF FF FF FF ................
000080: FF 7F 7F FF FF 7F 7F FF : FF 7F 7F FF FF 7F 7F FF ................
000090: FF 7F 7F 7F FF 7F 7F 7F : 7F 7F 7F FF FF 7F 7F FF ................
0000A0: FF 7F 7F 7F 7F 7E 7E 7F : 7F 7F FF FF FF FF FF FF .....~~.........
0000B0: FF FF 7F FF FF 7F 7F FF : 7F 7F 7F FF FF 7E 7F FF .............~..
0000C0: FF FF 7F FF FF 7F 7F FF : 7F 7F 7F FF FF 7F 7F FF ................
0000D0: FF 7F 7F FF FF 7F 7F 7F : 7F 7F 7F FF FF FF FF FE ................
0000E0: FE FF FF FF 00 01 : ................

And here is what I get using LabVIEW to call the dll:

0015 00E0 BB00 DDCC 8868 4841 00E0 BB00 DDCC 80B3 0000 FFFF 0002 0001 0100 9600 7F7F 7F7E 7F7F 7F7F 7F7F 7F7F 7F7F 7F00 B405 4300 3300 0000 0000 0000 01E0 BB00 0015 00E0 BB00 DDCC 8868 4841 00E0 BB00 DDCC 80B3 0000 FFFF 0002 0001 0100 9600 7F7F 7F7E 7F7F 7F7F 7F7F 7F7F 7F7F 7F00 F405 1B04 0C04 0000 0000 0000 8000 0000 0000 0000 0800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

The first thing I notice is that the first 4 bytes are chopped off, and after about 50 bytes, the data is corrupted until the sequence starts to repeat, but this time it starts with the missing 4 bytes and still corrupts after about 55 bytes.

I am expecting the data in LabVIEW to look very similar to the C data because the network packets I am grabbing are pretty consistant, only a couple bytes will vary between them, not the number I am seeing in LabVIEW.

Another side effect I'm seeing is that I can only run my labVIEW code once, if I try running it again it crashes with failures such as:

memory could not be "read"

For reference, I am opening and closing the network adapter inside the read function of my dll, but the pointer seems like it should be intact...
Download All
0 Kudos
Message 5 of 28
(3,665 Views)
Cannot open vi. Am getting:

"Resource not found. An error occured loading VI 'zListAdapters.vi'. LabVIEW load error code 33: Could not load front panel data logging and retrieval information."
0 Kudos
Message 6 of 28
(3,665 Views)
I ran into the same thing when I just tried to open it. I tried reattaching it, but it still comes up with an error, whether I try opening it directly or saving first, then opening, except this time I got an objheap.cpp error. Sorry.
0 Kudos
Message 7 of 28
(3,665 Views)
objheap.cpp error indeed. Good thing I wasn't actually working on those VI's I had opened . . .

How about Winzipping it?

If that dont work, you can try (one at a time):
1) save it as a different name in a differnt directory
2) delete all front panel controls and indicators and recreate them (sometimes when .dlls barf in labview they take a few controls with them).
0 Kudos
Message 8 of 28
(3,665 Views)
Here is the vi zipped.
0 Kudos
Message 9 of 28
(3,665 Views)
Okay, so to solve one problem, I limited the amount of data going into my array using array subset and the length of my array. This stops the vi from crashing after the first execution.

However, I am still consistantly missing the first 4 bytes of data in the received packet...
0 Kudos
Message 10 of 28
(3,665 Views)