Packed BCD to decimal in Crimson 3.1?

Hello,

I am stumped on how to tackle this issue.

I am working on an Energy project on a solar / wind farm and I am trying to read in some data from a couple of smart meters. I have attached the data breakdown. They are using this archaic data type I haven't encountered before.

My thought was to read each byte as binary individually and then reassemble as a decimal, but I don't see how to create a single byte tag they are all word, long or real type.

Even still I cannot read raw binary from the register, it is always in decimal format.

Is there something simple I'm missing?

I think you can use the Manipulation setting of "BCD to binary" to handle this. You'll probably have to do this for two tags set up as Long integers (32 bits each) and then do some math to combine them, or leave them as separate tags, since combining them into a 32 bit float would cost some precision.

Using the built-in BCD unpacking functions in Crimson would probably be the best method as Paul mentioned. But you could also do it the hard way with some code.

Determine the value of each digit by ANDing the corresponding register with a mask to clear all other bits, then shift right by the necessary number of places. (For sake of example, assuming the data is mapped to tags named with address numbers from your screenshot.)

Then it's just a matter of adjusting the digits by the proper factor of 10 to determine the final value.

Crimson works in signed 32-bit integers which can only hold a value of +/-2,147,483,648. With 16 digits, the transmitted value could potentially exceed that so you'd either have to drop the extra digits or work out some 64-bit math.

Thanks for the replies!

I created (4) tags and read the modbus addresses individually, with BCD to Binary as noted above.

So my total expression I used is:

S_Total := addr2852 + addr2851*10000 + addr2850*100000000;

Click to expand...

I did lose some precision by punting addr2853 but it does increment pretty quick on the solar side since it was sunny today.

What would the interpretation look like as 64 bit in Crimson? There doesn't appear to be any easy tool for much on this job. I get spoiled with all of the functions for data conversions in all of the usual PLC packages I usually use!

Do you need to perform any math on the resulting integer? If not, I would keep it as two 32 bit words, set the LSW format with leading zeros, and place them side by side on your displays.


If you need to use the 64 bit integer in any expressions or math, then you might want to do some trials with the 64-bit floating point functions built into Crimson 3.1. I have no 1st hand experience with those, but the Crimson help file has a decent explanation.

OkiePC said:

Do you need to perform any math on the resulting integer? If not, I would keep it as two 32 bit words, set the LSW format with leading zeros, and place them side by side on your displays.


If you need to use the 64 bit integer in any expressions or math, then you might want to do some trials with the 64-bit floating point functions built into Crimson 3.1. I have no 1st hand experience with those, but the Crimson help file has a decent explanation.

Click to expand...

Unfortunately I have to do some math, I calculate monthly output from these numbers

In that case, I would recommend putting some of the value after the decimal point and try your luck with 32 bit floats. If the precision is not good enough, dig into the reference manual on the 64 bit floating point functions. It probably will not be too much extra work to get it to do what you need.

OkiePC said:

In that case, I would recommend putting some of the value after the decimal point and try your luck with 32 bit floats. If the precision is not good enough, dig into the reference manual on the 64 bit floating point functions. It probably will not be too much extra work to get it to do what you need.

Click to expand...

Assuming IEEE-754, 64-bit floats (double precision) have enough mantissa bits (53 = 64 - 1(sign) -11(exponent) + 1(hidden)) to represent numbers with up to 16 decimal digits (53 x .3 ~ 16).