Labview Hex Strings Adding Spaces

[harokey]

Hello, I'm trying to use labview to communicate with at TCP server.

The problem I'm experiencing is that the TCP server will return a string of hex numbers for example:

0123456789ABCDEF\r\n

This returns from TCP Read (CRLF Mode), and then I strip the trailing \r\n characters using the String subset function.

The problem is somewhere along the way, the data becomes represented with spaces, so the string contains:

0123 4567 89AB CDEF

Which is unexpected to me. Why does Labview add spaces to my string, and how do I make it stop?

[LAVA 1.0 Content]

QUOTE (harokey @ Jul 23 2008, 11:27 AM)

Which is unexpected to me. Why does Labview add spaces to my string, and how do I make it stop?

Please post the relevant section of your code so that we can see what you are doing. LV only does what you tell it to do.

[crelf]

QUOTE (harokey @ Jul 23 2008, 12:27 PM)

The problem is somewhere along the way, the data becomes represented with spaces...

Are you sure the string has spaces in it, or is that because you're using HEX display mode on a front panel indicator? That mode does break HEX groups up for display purposes only, but does not alter the data.

[harokey]

QUOTE (LV_FPGA_SE @ Jul 23 2008, 09:58 AM)

Please post the relevant section of your code so that we can see what you are doing. LV only does what you tell it to do.

Attached are pictures of sample code that shows the issue.

When I run the command through telnet, it goes as follows, note that there are no spaces:

QUOTE

hostname

616E31323235612D3831373032313800

The string display is on "Normal" mode, not hex.

Don't worry about the Send TCP Command SubVI, or that stuff, the relevent part is the last TCP write.

QUOTE (crelf @ Jul 23 2008, 10:29 AM)

Are you sure the string has spaces in it, or is that because you're using HEX display mode on a front panel indicator? That mode does break HEX groups up for display purposes only, but does not alter the data.

It does have spaces, and the display mode is the "normal" display mode. The Data is an ASCII String, that is representing characters.

I have a subVI that will take this returned string (without spaces) and translate it. However, it doesn't work correctly with the spaces that are getting added in. I could fix it by accounting for the spaces, but I'd rather make labview stop putting spaces where they don't belong.

Edit: Upon Further Inspection, it looks like they are null characters, not spaces Which means that this is an issue with my TCP server and not with lab view, and it just had not shown up with my testing using c and python.

[crelf]

QUOTE (harokey @ Jul 23 2008, 01:40 PM)

Attached are pictures of sample code that shows the issue.

I know that this is going to sound stupid, but can you please upload your code?

[jpdrolet]

Are you sure that they are spaces and not some special/control character (like TAB) that isn't displayed in the telnet application? What do you see with /codes display?

[harokey]

QUOTE (jpdrolet @ Jul 23 2008, 11:26 AM)

Are you sure that they are spaces and not some special/control character (like TAB) that isn't displayed in the telnet application? What do you see with /codes display?

It turns out the "spaces" are null characters, the problem has to do with labview's strings not being null terminated like C strings, and therefor this problem was not picked up with the testing scripts I had been using. Thanks for everyone's help, but it wasn't exactly labview's problem.

[crelf]

QUOTE (harokey @ Jul 23 2008, 04:17 PM)

It turns out the "spaces" are null characters, the problem has to do with labview's strings not being null terminated like C strings, and therefor this problem was not picked up with the testing scripts I had been using.

Ahhhh - so there was something there that hyperterminal was ingnoring Yeah - the TCP read will give you everything back - using the "/codes" view is a great way to see everything as jpdrolet suggested. Glad to hear you got it working in the end :thumbup:

[jpdrolet]

QUOTE (harokey @ Jul 23 2008, 04:17 PM)

It turns out the "spaces" are null characters, the problem has to do with labview's strings not being null terminated like C strings, and therefor this problem was not picked up with the testing scripts I had been using. Thanks for everyone's help, but it wasn't exactly labview's problem.

LabVIEW displays non-displayable characters as spaces in string controls but should this rule apply to the null character? After all, doesn't the http://en.wikipedia.org/wiki/Null_character' rel='nofollow' target="_blank">null character mean "stay at same position" when printed?

[crelf]

QUOTE (jpdrolet @ Jul 24 2008, 10:58 AM)

LabVIEW displays non-displayable characters as spaces in string controls but should this rule apply to the null character? After all, doesn't the http://en.wikipedia.org/wiki/Null_character' rel='nofollow' target="_blank">null character mean "stay at same position" when printed?

Perhaps, but displaying the data is not printing. The "stay at the same position" is an interpretation that the printer/driver makes fromm the NULL, whereas in LabVIEW, it's a string and it should display everything, irrespective of how more specialised applications might interpret.