Jump to content

Labview Hex Strings Adding Spaces


Recommended Posts

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?

Link to comment

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.

Link to comment

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

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

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.

Link to comment

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.

Link to comment

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:

Link to comment

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

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.