hex string value to floating point

[rdeb]

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 

[GerdW]

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…

[RTSLVU]

---

@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. 

[Darin.K · Accepted solution]

 

[altenbach]

Here's what I would probably do:

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

[altenbach]

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

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)

[rdeb]

Thanks this is the solution. works verry well. 

[rdeb]

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

[rdeb]

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 

[altenbach]

---

@rdeb wrote:

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

---

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

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.