Issues regarding floating-point precision
Thread Content
The exponent of a 32-bit floating-point number ranges from -128 to 127, while the mantissa consists of one integer digit plus 6 decimal digits, for a total of seven significant digits. In my workshop, the Zhejiang University Zhongkong DCS systems all use version 300, with tag numbers being half-precision floating-point values ranging from 0 to 1. When calculating the cumulative flow rate, I found that Zhejiang University’s built-in function for accumulating flow rates was too complicated – two separate function blocks were needed for accumulation and resetting. So I wrote my own function block. My approach was as follows: I converted the value to a floating-point number and then accumulated it in an intermediate variable. The typical cycle time in Zhejiang University’s system is 0.5 seconds; thus, 7200 accumulations occur in one hour. By multiplying this figure by the range of the flow meter and then dividing by 7200, the cumulative flow rate can be determined. To reset the cumulative flow, it’s sufficient to set this intermediate variable to zero. Today I realized the issue with floating-point precision; problems arise when intermediate variables are very large. With 7 significant digits in the mantissa, the value represented by the lowest digit after the decimal point becomes quite large, and adding a value between 0 and 1 results in imprecision. For example, 3.111111*10^6 plus 0.5 is still 3.111111*10^6; there is no change. In this way, when the value is high, even if there is traffic, the cumulative traffic will not increase.
Note: Traffic accumulation calculation already includes low-level signal rejection. The measurement error of ordinary process measuring instruments is 0.5 per thousand. In the example, a value of 0–1 (0.5) is added after the first 7 digits; this 0.5 is likely to be smaller than the instrument’s measurement error of 0.5 per thousand.
You haven’t been in contact with Zhejiang University’s JS-300 system; the value 0.5 represents 50% of the range. For example, in the case of a mass flow meter with a capacity of 3000 kilograms per hour, 0.5 corresponds to 1500 kilograms per hour. And 0.5 per thousand is the value 0.0005.
This post was last edited by jlshnlhj on 2024-11-22 at 12:01. I haven’t used 300; I have used 100. Well, here 0.5 is a half-precision floating-point number; so what is 0.5 multiplied by 7200? Can it exceed 1.111111*10^6? Reaching a 7-digit integer? If a half-precision floating-point value is converted directly to a full-precision floating-point value, with a full scale of 1.0 corresponding to 7200, then adding 0.5 wouldn’t that be incorrect? Have you converted it to engineering units? Shouldn’t that 0.5 also be converted into engineering units?
Assuming the flow rate is at half scale, that is 0.5, then the total for one hour is 3600; for 10,000 hours, it is 3.6*10^7. What I’m doing here is not adding up the engineering quantities, but rather summing values between 0 and 1. To calculate the cumulative flow, multiply this accumulated value by the range and then divide by 7200
This post was last edited by jlshnlhj on 2024-11-22 at 16:09. This floating-point variable should just be an intermediate conversion variable. It is recommended to divide by (3600*t, where t=1 or 2) after 1 hour (3600 seconds), and then store the resulting value in the subsequent cumulative data variable. After completion, the intermediate transition variable is reset to zero. 10,000 hours – that’s over a year already; this isn’t an intermediate variable, but rather a cumulative variable that is related to time.
There’s no need to go to such trouble; using 4-20mA signals for accumulation will never yield accurate results. Check whether the loading system uses pulse signals, or use direct communication to read the flow meter’s accumulated value.