AWC application engineers had some totals on a recent application drifting away, which reflects an issue with precision when summing large volume floating-point numbers.
The format of a 32-bit (single precision) floating-point number in a PLC (data type Real) includes a mantissa of 23 bits, which provides a level of precision of 6 digits. Any more digits will lead to a loss in precision; in practice, this means that 99,999 + 0.01 is not going to equal 99,999.01. This behavior can cause massive problems for functions such as totalizers, which many applications use. As a general rule:
- Floating-point values have 6 digits of precision in the PLC (P).
- Data has S significant digits.
- 10^(P–S) values can be safely summed without losing precision.
- For a PLC application in which 4 significant digits are required, 10^(6-4) = 100 values that can be summed without losing precision.
How can this issue be resolved? A quick alternative is to use double-precision float, which is data type LReal in the PLC, during totalizer calculations. This may present some space and speed concerns, and changing the data type also introduces changes to the interface on the HMI, SCADA, and IoT systems as well. That said, this is still usually the easiest way to correct the issue.
Another alternative is to implement a summation programming block based on the Kahan Compensated Summation algorithm, developed by AWC engineering manager Matt Paulissen. This algorithm keeps track of that accumulated error which is then added back into the sum, therefore avoiding a loss of precision.
As evidenced in the above screenshot, the usual summation style lacks accuracy and can only get worse if the number of digits increased above what the mantissa could manage. If the application requires data types to be kept as 32-bit floats for whatever reason, implementing the Kahan block will prevent any totals from drifting away. Please fill out the below form if you are interested in using the Kahan block for your own application.
- Julyann Tu – AWC, Inc.