Baffled again .....

[Colin Carpenter 10]

I'm really baffled by this one and wonder if anyone has come across anything like it. I have a Q03 UDE PLC which has happily been integrating a flow meter analogue signal to calculate the amount of litres of a fluid that has passed through the flow meter. Every second, the PLC caculates the "litres per second" from the "litres per hour" signal that is being read into an anlogue input. It then adds this value to a real number that is an ever growing accumalator. Essentially it is a slightly crude integrator that works at 1 second intervals. This has worked fine for many months, but the other day I noticed that the real number had stopped growing, so assumed that the flow meter signal must have developed a fault. I checked it and it was fine, but the accumulator just wasn't growing. It had stopped at 33,554,300 (decimal) and just wouldn't go any further. I wondered if I had exceeded the limits of a real number, but it appears from the manual that real numbers can go up to massive values ..... 10 to the 129 I believe, and there is another real number accumulator in my software that was happily still counting at 67,305,589, so I figured that it was still a valid number. I gave up trying to work out what was wrong, so using IEC, I changed the value of the real number to 0.0, and off it went, happily integrating away as before. Anyone any ideas? Thanks.

[kaare_t 155]

The values you are talking about is no problem for a REAL number. There must be somewhere in the program that the value gets "limited"... Is it possible for you to upload/post the program? And if, specify where the variable/value is located.

[Ken Roach 194]

This is actually a very common issue when using a REAL datatype as an accumulator with small increments. At some point, adding a small number to a large number does not change the value of the REAL register. It's not brand-specific; you see this in A-B and Siemens too. It's just the way floating point math works. You can read all about the IEEE 754 standard if you like. Do you have the option to use an integer accumulator ?

[Colin Carpenter 10]

Thanks Ken, that's interesting ..... do you know if there is a fix for this problem, or is it just one of those things that you have to put up with? I think it would be awkward to use an integer accumulator and still maintain the accuracy of the floating point accumulator. In this instance, the "litres per second" (the number that is being added to the accumulator each second) will range from 0 - 2 lps, so it means that if I used an integer, it would probably round to the nearest whole number (normally either 1 or 2) but the change in accuracy would be huge. In reply to Kaare, the real number is set up as D702 and D703 in global variables, and there are no other references to either of these values anywhere else. The data registers used for the real number that has happily counted to 65 million are the next two (D704 and D705).

[kaare_t 155]

When you add a value between 1 and 2 (or 0.1 for that matter) you shouldn't have the problem suggested above. That occurs (in my experience) only when adding small fractions of a number (like 0.0001)....

[sah676 0]

The problem is that with a FLOAT data type you only have 24 bits of precision. The other bits specify where the decimal point is (and + or -). Once you go above 16,777,216 (2^24) the smallest number you can add is 1. As the other guys have been saying, adding 0.1 doesn't change it because the precision bits are taken up with representing the whole part of the number. It's easy enough to work around: Once you reach 16,777,215 just tick some other register (D10 e.g.) up by 1 and start again at zero. The total number is just (16,777,215*D10)+Running total. Of course, this will still be rounded because the result is stored in a FLOAT with the same limitations. But at least adding up will continue no matter what the total is.

[Colin Carpenter 10]

That's a great first post. Thanks for that, it defines the problem beautifully ..... and the work around is nice and elegant as well.

[sah676 0]

Thanks mate! It was an interesting problem. I'd never realized FLOATs would behave like that when they got large. It's something I'll be looking out for myself.