Convert byte to hex string

[Jo-Jo]

I am receiving a single byte using the VISA functions via RS232 from an embedded controller. Each byte is received as formatted as ASCII text, as that is how the VISA functions intepret things, but I want to view the hex values of the bytes received, so I am using the attached VIs to first cast the byte received into a U8, and then converting it back into a hex string. I feel that there is probably a way to do this in one step, but I can't figure it out. Does anyone know of a way to do this all in one go?That is convert the received byte directly into a hex string.

~Benjamin

[RavensFan]

Put an indicator on the string wire coming out of the VISA Read.  Right click and set it for Hex Display.

[IsmaNaj]

Would it be possible to cast from Bytes to HEX ? Not just for viewing purposes.. 

[RavensFan]

What exactly do you mean?

Bytes are bytes.  Hex is one way of displaying the numerical value of the bytes.

Do you want it to become a string of alphanumerical characters? For example, you get a byte that is 255, and you don't want it to be a numeric that is shown as "FF", but you want it to be a string with the characters "F" and "F"?

If so, look at the string palette >> Number to String and get Number to Hexadecimal string.

[deceased]

Something like this should do the job...

Deceased.

[IsmaNaj]

Well, I'll elaborate more on my problem.. 

Actually I'm working on a TCP IP LabVIEW server and a C++ CSocket client application. 

The LabVIEW server should send IEEE 754 64-bit floating point measures (in binary) to the client, which decodes those recieved bytes as floating point numbers. 

I'm new to both labview and Socket programming, but from what I understood, when it comes to TCP IP communications: LabVIEW only sends data in a string form.

Since sending binary arrays is not allowed, I thought transforming those 64 bit arrays into hexa strings and sending them over the TCP IP connection should do the job. What do you think? 

Thank you. 

[IsmaNaj]

Well, I'll elaborate more on my problem.. 

Actually I'm working on a TCP IP LabVIEW server and a C++ CSocket client application. 

The LabVIEW server should send IEEE 754 64-bit floating point measures (in binary) to the client, which decodes those received bytes as floating point numbers. 

I'm new to both LabView and Socket programming, but from what I understood, when it comes to TCP IP communications: LabVIEW only sends data in a string form.

Since sending binary arrays is not allowed, I thought transforming those 64 bit arrays into hexadecimal strings and sending them over the TCP IP connection should do the job. What do you think? 

Thank you. 

[RavensFan]

With that description, it sounds like you want the Typecast function.  It converts data from one datatype to another without changing the underlying bytes.  You determine what datatype you want it to become by wiring that datatype into the top.  So if you had a string and want it converted to an array of U32's, you'd wire a U32 array constant to the top.  If you have an array of U64's and want to convert it to a string, you wire a string to the top.  Actually, you don't even have to wire the string because that is the default datatype for Typecast if nothing is wired to the top.

[deceased]

You should be able to type cast the DBL to string and send it, at the end of the day the string is just 1s and 0s.. You can reconstruct it at the other end,

Deceased

[crossrulz]

---

IsmaNaj wrote:  The LabVIEW server should send IEEE 754 64-bit floating point measures (in binary) to the client, which decodes those received bytes as floating point numbers.

---

In that case, I prefer to use the Flatten To String and Unflatten From String functions to convert your data to/from the string.  I prefer these over the Type Cast since you can specify the Endianness of the data.  The Type Cast only uses Big Endian.

Also, it is a common practice to send the number of bytes in a message before the message.  So then the client reads 4 bytes to get an I32 and then uses that value to know how many more bytes need to be read.