CJ1 CPU Real Number Calculation Accuracy.

[BITS N BYTES 66]

Using a CJ1 processor with a Structured Text Function Block to calculate the multiplication of Internal Variables of type REAL. The result is an External variable type REAL. Works like a charm BUT I get minutely varying results based upon how the internal variables are entered. For example if each variable is entered as 2.5, then 2.5 x 2.5 x 2.5 = 15.625. The resulting Hex value for this is 0000 417A. In IEEE-754 format 417A 0000 = 15.625. However if the three variables are entered as 2.5 x 25000 x 0.00025 the displayed result is still 15.625 but the resulting Hex value for this is now 0001 417A. In IEEE-754 format 417A 0001 = 15.625000953674316. Is this difference due to the IEEE-754 format or how the PLC calculates the result? The CJ PLC instruction set specifed that for Floating Point calculations "The number of effective digits for floating-point data is seven digits for decimal". So where/why is there a difference in the calculations based on the input data. If I only need an accuracy of 5 places after the decimal point how does one filter out remaining extraneous data? Confused or I am really missing something really basic??[30 years since college]. THNX

[tashinz 9]

i had recently similar issue, so i wrote to omron and got the following answer: This is not a defect, just a strange issue with use of floating points on binary machine. You need to only view the preceision you are interested in as there will always be inaccuracy at greater preceision than this. visit a link: http://www.myomron.com/index.php?action=kb&article=1126 hope this helps

[Sergei Troizky 26]

The precision of single-precision floating point format is 23 bits of mantissa, which means 7-8 decimal significant number. Being applied to your example, this means you can trust the 15.62500 part only, and should ignore the rest. Edited 1 Sep 2009 by Sergei Troizky

[banker 2]

Hi Seen the same problem with totalizers. ( Total := Total + Flow / 3600.0; ) Works great when Total is small but whem the diff. between Total and Flow / 3600 the totalizer starts loosing accuracy. Banker .

[BITS N BYTES 66]

Thank you all for quick response. As I said in my original post the CJ PLC instruction set specifed that for Floating Point calculations "The number of effective digits for floating-point data is seven digits for decimal". Does this mean that a seven digit result of 123456.7 or 1.234567 have the equivalent accuracy? If I can trust only 7 digits in my example 15.62500, then what procedure in ladder or structured text must be used to read only 7 digits of a real number and "ignore the rest"? Not quite as confused but still looking for best solution to resolve this problem.

[pfort 20]

What do you want to do with the result...display it as REAL on an HMI?...convert it to integer?...to BCD?...

[pfort 20]

Oh...and, if i were you, i would not bother with that IEEE-754 conversion...see the screenshot:

[Sergei Troizky 26]

Neither procedure. Your result is of reasonable accuracy. Just for reference, 7 significant decimal digits allow to measure: - Tens of kilometers in cantimeters (well, tens of miles in inches), or - Tonnes in gramms, or - Couple hours of time in milliseconds, or - Over 3 months of time in seconds. And remember, floating point format is not for counter (which must correctly add single units even close to limit values), but for reasonable accuracy calculations. Edited 7 Sep 2009 by Sergei Troizky