Flow Totalizers

Hi guys! How do you program flow totalizers? I know it could be as simple as adding up the numbers, but we have a problem when the totalizer value gets larger and larger. The error also becomes larger! We had simulated the program for several times and it works just fine but in the actual process, the error seems to be unavoidable. We have to resort to resetting the totalizers every week and sometimes daily. By the way, we use Siemens S7 300 PLCs. Hope someone out there could help... Thanks... Godbless..

Just as you said. On the raising edge of the pulse from the flow meter add appropriate quantity to the totalizer counter. If you now exact enough quantity for a single pulse there is no reason to have to big error. And the relative error has to be about the same, regardless of the total amount. It seems that there is some problem with your actual measuring { flow / flow meter / wiring / hardware / software / ... }.

Could it be that your pulses are coming in too quickly to be processed accurately by the counting logic?

Hi!

check plc scan time and flow meter's pulse width.
I once have similar problem, my logic scan time was something between 50-60ms and flow meter pulse width was 50ms, so my plc didn't register all pulses from flow meter...

Lare

I'll second CowDung's suggestion, what is the minimum "on time" of the pulse coming from the flowmeter? What is the maximum scan rate of the PLC program? Perhaps there is a condition in the PLC program that only comes true once in a while that causes the scan time to be significantly longer and pulses to be lost?

mafe said:

Hi guys! How do you program flow totalizers? I know it could be as simple as adding up the numbers, but we have a problem when the totalizer value gets larger and larger. The error also becomes larger! We had simulated the program for several times and it works just fine but in the actual process, the error seems to be unavoidable. We have to resort to resetting the totalizers every week and sometimes daily. By the way, we use Siemens S7 300 PLCs. Hope someone out there could help... Thanks... Godbless..

Click to expand...

Sounds like you are using a floating point register for the totalizer accumulator. Avoid that. If you are counting pulses, stick with an integer register (no floating point round off).

If you are integrating an analog signal and your increment is already a floating point number, there is a way to deal with it. Use two registers. Add your increment to the first register and when it passes a certain value, add a fixed amount to the second register and subtract the same amount from the first register. This keeps the first register value low enough to avoid round off. The second register can be an integer. You get real total by adding them together, this can be floating point.

The basic problem is that when you add a very small floating point number to a very large floating point number, at some point the small number has no effect on the result. Long before that happens you will have significant totalizer error.

First of all we need to know if you are counting pulses from the flowmeter or are you totalizing from an analog input?
How do you know there is an error, are you comparing the total in PLC to a local total in the flow meter?
Roy

Very nicely explained Mellis....
I've seen the problem with floating point numbers many times. An IEEE floating point number is 32 bits:
1 bit is the sign
7 bits for exponent
23 bits for the mantissa
2^23 is 8388608, so the resolution is 1 in 8388608
The solution as posted by Mellis (using two registers) is exactly the same way I've addressed this problem in the past.

In IEEE 754 the 23 bit mantissa is expanded with an implied 1, so the resolution is actually 1 in 2^24-1 (16777215), but the principle is the same. You cannot increase an IEEE 32 bit float beyond 16777215 by adding 1 to it. And if you are adding numbers smaller than 1 then that limit decreases dramatically.

To add to the float woes, there are many numbers which cannot be represented exactly in a float, for example, a fraction Y/10*n where Y and N are integers and Y/10^n<>1/2^N ie, .1, .01, .001, .2, .02, .002, etc, cannot be represnted precisely. A very close approximation can be had and the error will be essentially negligible for a single calculation, but when you do the calculation over and over the error can begin to become significant. Best to use integers and stack them until you have enough bits. You can find sundry methods for doing 32 bit and 64 bit computations using 16 bit processors on the internet. However unless I'm mistaken the S7 300 is a 32 bit machine, and if four billion is a large enough number then using integers for totalizng becomes trivial - doing a single floating point operation to scale the final result.

Finally, the answer to Roy's question is very important, because if you are totalizing from an analog flow meter then we need to change the direction of this thread.

Very interesting discussion on potential cumulative error from IEEE floating point. I had seen the inability to exactly represent some values, but had never considered the effect of cumulative error over time when totalizing.

Anyone aware of a white paper on this topic?

Dan

For the sake of completeness, I'm going to expand on my previous post an offer an alternative solution.

Pulse Signal
If you are totalizing pulses, the solution is simple. So simple that people overlook the obvious. Count the pulses in an integer, do not scale the pulses to engineering units and count in a floating point. Scale the total to engineering units. This completely avoids floating point math until the final step and will have no problem with accumulating error.

With 32bit integers, this should be trivial. A totalizer with 9 usuable digits covers most real applications. If you need more range a simple overflow into a second 32bit integer will handle it. If I had to do this, I would program it to overflow at 1,000,000,000 just to make reading the total count easier.

This is the same as what Alaric suggested.

Analog Signal
The method described in my previous post works well, but I think I like this alternative even better. Arrange it so the incremental amount is an integer with an implied demical point and add that to a 32bit integer. For example, if you are measuring 60 lpm and sampling once per second, you will be adding 1.0 liter each second to the total. If 0.001 liter resolution is acceptable, multiply the increment by 1000 and add that to a 32bit integer.

From here on, it works the same as the method described above for pulse signals. The main difference is that you are much more likely to need to roll over into a second 32bit integer because you are adding larger increments. You can convert the totals back to a floating point if you like.

The key point here is accumlation with an integer works well. Accumulation with a floating point does not.

mellis said:

Use two registers. Add your increment to the first register and when it passes a certain value, add a fixed amount to the second register and subtract the same amount from the first register. This keeps the first register value low enough to avoid round off. The second register can be an integer. You get real total by adding them together, this can be floating point.

Click to expand...

I'm going to modify this statement. The second register MUST be an integer or you are going to run into the same problem again eventually.

Thanks guys for all the replies, i do appreciate it very much.
Yeah, Mellis is right, we are using the analog signal and not the pulse signal from the flowmeter. I will recheck our program and try your suggestions. Thanks again...

Hello, regarding with the totalizer. Can we use the 4-20mA as a signal only and use the pulse output for the totalizer??

What do you do with the totals, if it's just display i.e. logging manually or auto you could use a range of registers of units, tens, hundreds, thousands etc. i.e. when units reg hits 10 inc tens reg and reset units etc. this means you could have a big number & if required on a particular day & time store the numbers & reset the counts, this gives you history etc. Used this once in an old plc that was limited in those days.