LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

hex string value to floating point

Solved!
Go to solution

Hi, Could someone help me 

 

I am reading value's from a heating boiler and i am stuk in som hex value's

 

For example i get hex values

boiler water temperature: 44.40

i can read in dispaly of my boiler it is 44.40 degrees Celsius 

i get hex value 2C66 

some more values 

2FB3 hex i know it has to be 47.40

13F0 = 19.94

0700 = 7.00

6400 = 100.00

i get the value before the dot but how get the value after the dot?

 

how can i converd the hex value in labview to floating point values.

some one a idea.

 

thanks

 

rob 

0 Kudos
Message 1 of 13
(2,921 Views)

Hi rob,

 

with all the values you gave us I implemented this:

There seems to be a simple linear equation to convert from those hex values to your temperature data!

(Reading the manual will probably tell you the same…)

 

Edit:

The slope value of 0.0039… looks very familiar to me: it's (about) the reciprocal of 256! The intercept is nearly zero, so when getting rid of rounding errors the scaling factor simply is 1/256…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 13
(2,907 Views)

@rdeb wrote:

Hi, Could someone help me 

 

I am reading value's from a heating boiler and i am stuk in som hex value's

 

For example i get hex values

boiler water temperature: 44.40

i can read in dispaly of my boiler it is 44.40 degrees Celsius 

i get hex value 2C66 

some more values 

2FB3 hex i know it has to be 47.40

13F0 = 19.94

0700 = 7.00

6400 = 100.00

i get the value before the dot but how get the value after the dot?

 

how can i converd the hex value in labview to floating point values.

some one a idea.

 

thanks

 

rob 


2FB3 hex = 12211 decimal

 

So this is NOT a simple conversion issue.

 

Your temperature controller must also have a scaling factor that you need to use to convert the hex Integers to Floating-point. 

 

Also pretty much every temperature controller I have used uses Modbus protocol. To get high accuracy Modbus often stores values in two (16 or 32 bit) registers that you must merge, convert the merged value to Single Precision, and then multiply by the scaling factor. 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 13
(2,904 Views)
Solution
Accepted by topic author rdeb

ConvertHexTemp.png

Message 4 of 13
(2,880 Views)

Here's what I would probably do:

 

altenbach_0-1625083273024.png

 

(or go DBL, depending on where the data goes later.... Same result)

 

 

Message 5 of 13
(2,857 Views)

Even works directly with arrays and returns the correct result for all your example inputs.

 

altenbach_0-1625083685331.png

 

Note that you can also cast the U16 to FXP. same result, but a bit more dangerous and unsuitable for you math (e.g. linear fitting will coerce it back to DBL at the input)

 

altenbach_2-1625084075972.png

 

 

0 Kudos
Message 6 of 13
(2,848 Views)

Thanks this is the solution. works verry well. 

 

ConvertHexTemp.png

0 Kudos
Message 7 of 13
(2,798 Views)

Thanks this works also fine. but for mee more difficult to understand what is happing 

altenbach_0-1625083273024.png

0 Kudos
Message 8 of 13
(2,798 Views)

Thanks for all te reply's 

 

it was my first question on this forum.

 

it's great that there are people who want tho help with questions that you can't solve yourself.

 

thanks 

0 Kudos
Message 9 of 13
(2,788 Views)

@rdeb wrote:

Thanks this works also fine. but for mee more difficult to understand what is happing 

altenbach_0-1625083273024.png


OK, you want even simpler? Here is even simpler!!! (same result!)

 

altenbach_0-1625148139647.png

 

Explanation: A right shift by 8 bits (i.e. a left shift by -8 bits or a scale by 2^-8) is the same as a division by 256, which the second code does explicitly. (Assuming unsigned numbers. Scale by power of two actually does an arithmetic shift and retains the sign correctly for signed inputs. A right shift directly on the integer will shift the lower 8 bits into non-existence, that's why we convert to floating point first.) The first code does the same division after first converting to floating point, but can be done more efficiently by the CPU. Divisions and multiplications by integer powers of two reduce to a few bit manipulations, while a general division involves more effort. Still, on modern CPUs, a division is highly efficient and you probably won't see a difference. 50 years ago, things would have been different. 😉

A seasoned programmer used to think in binary will gets stronger clues from my first code, i.e. understand more easily what it actually does under the hood. That's the only reason I preferred it. Feel free to use the second version above.

Message 10 of 13
(2,755 Views)