Trying to convert ASCII-Character "â" to its corresponding ASCII-Value with "String To Byte Array" (LabView 5.0)

[Mika]

The result is 226 and that is wrong. In fact it is 131. Is there a bug in this function or did I make a mistake ?

[asimpleman]

Check out this link. http://www.jimprice.com/jim-asc.htm#extended
About halfway down the page you will find 2 different ascii sets.
Apparently IBM created the first extended ascii set, but Windows changed it.
226 is correct in Windows version.

"Mika" wrote in message
news:506500000008000000DF610000-1031838699000@exchange.ni.com...
Trying to convert ASCII-Character "â" to its corresponding ASCII-Value
with "String To Byte Array" (LabView 5.0)

The result is 226 and that is wrong. In fact it is 131. Is there a bug
in this function or did I make a mistake ?

[Mika]

Thanks, now I know the problem. But I have to read ASCII-Characters from my equipment that are organized in the IBM way. So how can I get the right value on my Windows based system ? I have no idea ...

[aderogba]

I don't think there is a bug with this function. Extended ascii characters are represented by two bytes and they resides in the upper byte (upper 128). String To Byte Array only returns the lower 128.

[aderogba]

My earlier response is with respect to keyboard scan codes. I tried the "â" character conversion on LabVIEW 6i, I got the same response. Also 131 doesn't produce "â", but 226 does.

[Mika]

Sorry, that doesn't help me very much ... I think, the problem I have is not clear enough.

My equipment, that sends ASCII-Characters according to the IBM-Standard, wants me to interpret them in LabView which uses the Windows-ASCII-Set. So after the conversion with "String To Byte Array" the value of the sent character "â" is 226. Now the problem: I have to get 131 as value, according to IBM. And I think that's not the only problem, every other character with a higher value than 128 will be translated in a wrong way, too.

All I need is a function that converts my ASCII-Characters sent by my equipment according to the IBM-ASCII-Table and NOT to the Windows-ASCII-Table. If you look it up in IBM-Tables: "â" is 1000 (lower byte) 0011 (upper byte) and
that is (2^0 + 2^1 + 2^7) = 131 and NOT 226. So my functions output must be 131 with an "â"-input.
By the way, 226 is 11100010 and that is "Ô" (IBM-Table).

[aderogba]

I can't seem to be able to figure out the simplest way to solve this. The closest I encounter was using mapping i.e mapping one character set to the other.

[asimpleman]

You could create a lookup table with all the ibm codes in column 1 and the
corresponding windows codes in column 2. Search column 1 for the given
value and then index out the value from column 2.

"Mika" wrote in message
news:506500000005000000B4AB0000-1031838699000@exchange.ni.com...
Sorry, that doesn't help me very much ... I think, the problem I have
is not clear enough.

My equipment, that sends ASCII-Characters according to the
IBM-Standard, wants me to interpret them in LabView which uses the
Windows-ASCII-Set. So after the conversion with "String To Byte Array"
the value of the sent character "â" is 226. Now the problem: I have to
get 131 as value, according to IBM. And I think that's not the only
problem, every o
ther character with a higher value than 128 will be
translated in a wrong way, too.

All I need is a function that converts my ASCII-Characters sent by my
equipment according to the IBM-ASCII-Table and NOT to the
Windows-ASCII-Table. If you look it up in IBM-Tables: "â" is 1000
(lower byte) 0011 (upper byte) and that is (2^0 + 2^1 + 2^7) = 131 and
NOT 226. So my functions output must be 131 with an "â"-input.
By the way, 226 is 11100010 and that is "Ô" (IBM-Table).

[Mika]

Thanks everybody, especially Adam. I tried the lookup table in a similar way and that works perfectly.