Getting VISA Read output format right (hex, ASCII, ???)

[M_Williams]

Hello, LabVIEW community. I have a VISA read/write VI which sends a data request to my equipment and reads the response. I have been successful in getting the VI to send the request and read the response. Currently I am having terrible difficulty in manipulating the read string as needed. The read string has 3 values I need to separate out and use to do the following: 1) Display an instantaneous value, 2) Chart the change in value, 3) Store to a file with a time stamp. I have been researching how LabVIEW handles the output from VISA read for over 10 hours, and have not come across a clear explanation of how I can do this. The three sub-strings have hex values which should be converted:

20 20 20 30 2e 30  to 0.0

20 20 31 2e 31 20  to 1.1

31 30 2e 32 30 20  to 10.20

The complete string read from equipment in this case is:

02 32 31 31 3d 20 20 20 30 2e 30 20 48 70 0d 32 33 31 3d 20 20 20 20 31 2e 31 20 6c 62 66 0d 32 30 39 3d 20 20 31 30 2e 32 30 20 6d 70 68 0d 17 31 34 24

Thanks!

[LV_Pro]

The string that is read back will vary depending on the device you are talking to, and its protocol. Think of the VISA as a phone, it can be used to convey any spoken language, but each of them has its own alphabet, grammar and punctuation.

So, that being said, what is the device you are trying to "decipher"?

[M_Williams]

The device is a dynamometer using RS-232 communication. From what I can understand, the device sends a series of bytes which represent an ASCII string, which gives hex values, those representing numeric values. For this particular transmission case, the format will always be 3 lines, followed by a checksum. The lines all end with 0d. The numbers I need to isolate are within those lines.

[crossrulz]

You return data is definitely in an ASCII format.  Just view your returned string in "Normal" display and it will become obvious.  You will want to use the Fract/Exp String To Number to convert to an actual number.

[M_Williams]

I understand that when the display is set to normal, the ASCII values are shown. My problem is that the ASCII values are a series of hex characters. These I think I need to convert to actual ASCII characters, and extract numerical portions.

[M_Williams]

For example: when I use the fract/exp string to number block on the first substring I get 20. That is incorrect as the 20 represents a space NOT a number.

[Minions]

M_Williams

All of the data that you have in that response is displayed in ASCII HEX.  It is fairly straight forward to decode it.  Starting with 0x02 as the START OF TEXT character.

211=   0.0 Hp
231=    1.1 lbf
...

If you split the response at each Carriage Return 0x0d, then grab the strings before and after the '=' you will have your data parsed properly for conversion to a float.

[crossrulz]

---

@M_Williams wrote:

For example: when I use the fract/exp string to number block on the first substring I get 20. That is incorrect as the 20 represents a space NOT a number.

---

I have never ran into an instrument that does that.  Please take a capture of the data coming from the instrument, set the default values (Edit->Make Current Values Default), save, and post the updated VI.  This way we can all make sure we know what we are looking at.

[Bob_Schor]

Yep, I agree with Minions.  While I was writing the little test routine below, Minions was responding and beat me to the punch ...

The reason for this strange behavior, I think, is that RS232 is designed for Ascii, i.e. text where certain bit patterns have a "meta-meaning", e.g. 0x02 is Start of Transmission, 0x77 is Delete, etc.  So to unambiguously send 8-bit text, you have to "encode it", so why not encode it as Ascii?  So the first loop decodes the Ascii string representation of the Ascii Characters into a hex array, and we then turn the hex array back into a String.

Bob Schor

[M_Williams]

Thanks for all the quick replies. Bob Schor, I have implemented your diagram and it works great. The only problem I have now is maintaining the digits after the decimal place. I'm sure I've overlooked something simple.