LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to effectively change streaming hexadecimal bytes to decimal numbers?

Solved!
Go to solution

Tech Support,

 

There is an instrument plugged into a serial port on my computer that is streaming 25 bytes of hexadecimal data every second.  After changing the display mode to 'Hex Display' I can now see the hex bytes instead of munge.  I am using the 'Hexadecimal String to Number' vi with marginal success.  By that, I mean that (1) I cannot convert the entire hex string at all, and (2) when using 'String Subset' to parse out individual hex bytes I am periodically able to convert a hex byte into an integer.  I have tried the type-cast suggestion indicated in a previous posting on this subject with no change in performance, although I do not entirely understand how that solution works (how to properly define the type?).  Do I require a buffer to continuously convert streaming hex data?

 

I would send my vi, but it's fairly simple.  25 bytes of hex data in every second (1 second buffer), Index of 0, default U32, sent to an Indicator.  At this juncture, all I want to do is see my data.  I am using LabView 8.5.1.  Please indicate if I should supply more information.  Thanks.

 

~Going Bananas

 

 

0 Kudos
Message 1 of 10
(4,232 Views)
You should post your HEX data, the data you see after conversion and the data you expect. A VI with an example (without the serial part since it sounds like a LabVIEW problem) would be helpful for all of us to help you faster.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 2 of 10
(4,227 Views)
Solution
Accepted by topic author CodeMunkee

CodeMunkee wrote:

After changing the display mode to 'Hex Display' I can now see the hex bytes instead of munge.  I am using the 'Hexadecimal String to Number' vi with marginal success.  By that, I mean that (1) I cannot convert the entire hex string at all, and (2) when using 'String Subset' to parse out individual hex bytes I am periodically able to convert a hex byte into an integer.  I have tried the type-cast suggestion indicated in a previous posting on this subject with no change in performance, although I do not entirely understand how that solution works (how to properly define the type?).  Do I require a buffer to continuously convert streaming hex data?

 

I would send my vi, but it's fairly simple.  25 bytes of hex data in every second (1 second buffer), Index of 0, default U32, sent to an Indicator.  At this juncture, all I want to do is see my data.  I am using LabView 8.5.1.  Please indicate if I should supply more information.  Thanks.


If your data looks correct when you set the string to hex display, the "hexadecimal string to number" is NOT the correct tool (it assimes hexadecimal formatted strings containing the ASCII characters 0...F exclusively). You have a binary string so typecast is the correct tool. If you want the first 4 bytes as U32, you simply create a diagram constant of representation U32 (value is irrelevant) and wire it to the type input of typecast. The output will be a single U32 numeric wire containing the desired output.

 

What is in the rest of the string? It cannot be all U32 unless there is some termination character. Do you want to see any of the remaining data? In this case you need to tell us the structure.

 

Please create an indicator for your raw string, run the VI so it contains data, then convert the indicator to a diagram constant (right-click terminal...change to constant: this way we see what you actually have). Now save the VI and attach it here. Tell us what value you expect. (Things could be slightly more complicated if you have little endian byte order).

 

I an not sure what you mean by "continuously streaming" data. How much history do you want to keep? Do you want to stream to disk? If you just want to see the recent history data, hook it up to a chart with a desired history lenght.

Message 3 of 10
(4,220 Views)

Yes, type-cast did the trick.  I simply funneled the binary string into "Type Cast" formatted for U32 and then "Number to Fractional String" and I had my data in decimal numbers I could read.

 

To your other questions, yes it's all U32, yes there is a termination character, and yes I use all my data.  By "streaming continuously" I mean that my instrument never turns off, is constantly connected, and sends 25 bytes of data to my computer once every second.  I want to keep all the data it streams from now until eternity (or until they stop paying me to collect data!) so yes, I will soon need to stream to a file.  I additionally plan to implement your suggestion of the charts as a visual aid.

 

Thank you for your elegant solution, I am sure I'll be back on this channel in the not-too-distant future!

 

~Bananas for Everyone!
0 Kudos
Message 4 of 10
(4,180 Views)
Most of microcontrollers and OSs uses little endian byte order. LabVIEW uses big endian byte order because it was firstly made for MAC OS, which uses big endian. Type Cast will use big endian, so you have mostly to change byte order to little endian. Better is to take Unflatten from String VI, where you can select the right byte order for you.
0 Kudos
Message 5 of 10
(4,174 Views)

If the result is currently correct, byte order is not an issue.

 

Since U32 is an integer, I don't quite understand why you are formatting as a fractional string. You'll never have decimals.

 

Just use a numeric indicator on the blue wire and you don't even need to format anything. You can read it right there. 😉

0 Kudos
Message 6 of 10
(4,168 Views)
Probably he has a U8 Array and want to format e.g. 4 bytes of this array to one U32 number. Here is the byte order very significant. He can't connect an array to one integer indicator.
0 Kudos
Message 7 of 10
(4,155 Views)

Eugen Graf wrote:
Probably he has a U8 Array and want to format e.g. 4 bytes of this array to one U32 number. Here is the byte order very significant. He can't connect an array to one integer indicator.

 

There is no "probably". We know what he has (a 25 byte string!) and we know what he wants (an array of U32!). Most likely it is 6xU32 numbers and a termination character, or checksum, for example.

 

So far we looked at the first number and he was able to see the correct decimal number. Thus byte order is most likely correct. If the byte order were wrong, the result would  be noticeably different and unexpected. 😮 Of course if we would typecast to an array of U32, we need an array indicator. That seems obvious. 😉

 

If it later turns out that the string is actually little endian, we can always revisit the topic. I already said in my first reply the following: QUOTE: "Things could be slightly more complicated if you have little endian byte order". In order to be sure, we need a raw string and the expected result, as I already requested.

 

Byte order is not difficult, you are guaranteed to get it right on the first or second try. 😄

Message 8 of 10
(4,149 Views)

Ok, there is no problem from my side. I want only to say that type cast is almost the same as unflatten from string. Only if you want to unflatten data in little endian byte order (what is the most case of use), than you have to select unflatten from string vi with little endian byte order option instead of type cast vi.

 

Eugen

0 Kudos
Message 9 of 10
(4,145 Views)

Just to clarify, I oversimplified what I did in my previous post.  After I used "Type Cast" I did in fact have an integer that I sent through a mathematical function (which gave me a decimal) before sending to "Number to Fractional String".

 

You gentlemen are very thorough -- I tinkered with the little/big endian stuff but it turned out it wasn't necessary.  I am grateful to know that LabView has a vi to handle this little endian business in an elegant fashion. Thanks for the tip.

0 Kudos
Message 10 of 10
(4,117 Views)