Best way of totalizing flow?

[OkiePC]

Tom, I agree with all of your points, but my reason to prefer to let the totalizer totalize and let the PLC talk to it as needed, is that some of the PLCs that would talk to these meters get powered down for maintenance while the total water usage in bypass needs to be counted...with the flowmeters sitting up high in the pipes with a comm. cable and UPS power, there is no loss, no concern for analog accuracy (we have a relic or two doing that...the antithesis to this thread: WoRST way to totalize: summing analog flow rates sent from the meter and sampled by a PLC analog card.)

By setting up communication, you can monitor much more than a flow pulse to roll your own total from, plus you can get matching data which the boss will approve of. (Whether it's more accurate or precise is irrelevant; if they match, he trusts it...)

 

[Tom Jenkins]

All valid points, Okie. And I agree that if the meter has a totalizer built in you may as well use it. I just felt compelled to point out that there isn't any magic in a totalizer - it is just electronics and programming too. And I also think that too many programmers get hung up on unrealistic data considerations and forget the physical constraints of the system may overwhelm the more esoteric programming details.

It's always nice to be agreed with!

 

[Bit_Bucket_07]

Tom,

The truth is that there are many different applications requiring totalization and some demand far more precision and/or accuracy than do others. That said, if you are attempting to do long term totalization that requires adding a small Floating Point value to an accumulator register that will reach a high value, then the data loss from rounding off will eventually become far more significant than could be considered either trivial or esoteric.

This error can be particularly difficult to diagnose if one is unaware of the issue of machine epsilon, because the totalization will appear to be functioning perfectly for some time after the program has been initially written and commissioned and in some cases the errors may not begin to present themselves for some years after a lifetime totalizer has been put into service. Suddenly, a program that has long been functioning without a glitch and that hasn't been modified in any way becomes absolutely dysfunctional.

 

[JERA]

A PLC can lose input signals from flow meters if the pulses are too short or less than scan time.

I have experienced this on a project where the pulses were shorter than the PLC scan time so we lost the measurement. The solution was to mount Weidmuller MCZ timers on 150ms on signals.
Weidmuller MCZ timers available in both 50 and 150 ms version.

 

[Tom Jenkins]

Tom,

The truth is that there are many different applications requiring totalization and some demand far more precision and/or accuracy than do others. That said, if you are attempting to do long term totalization that requires adding a small Floating Point value to an accumulator register that will reach a high value, then the data loss from rounding off will eventually become far more significant than could be considered either trivial or esoteric....

....Suddenly, a program that has long been functioning without a glitch and that hasn't been modified in any way becomes absolutely dysfunctional.

1) Well, I'm not a mathematician, but Simpson's Rule has been working well for quite a while. That is essentially what we are talking about with totalizing from an analog signal - integrating vs. time. http://en.wikipedia.org/wiki/Simpson's_rule Now, there are all kinds of caveats and so on, and on a purely theoretical basis you may be right. However, it seems to me that on an analog signal the errors going up are offset by the errors going down. If one is concerned about custody transfer then Okie has the right idea - use the method that causes the fewest arguments.

2) It also strikes me as just a bit silly to worry about errors of one part in 100 million if the primary meter is - at the very best - only accurate to one part in 10 thousand. Back in the day we had a concept called "number of significant digits". That concept may have gone out with the slide rule, though. I suppose that if a computer can calculate to 15 decimal places they must all be important!

3) As far as the pusle counting, it will be every bit as accurate as any other device provided, as I stated, that the input has the frequency response required. That's just good design practice, though. And, of course, you can always have a loose wire. I guess that the internal workings of the flow meter never fail?

4) You may be right about a program suddenly becoming disfunctional all on its own. I've never seen that, but I've only been doing this for thirty years or so.

 

[jamesau]

BB7 makes a valid and pertinent point. See
http://en.wikipedia.org/wiki/Machine_epsilon.

Basically, those performing totalization on an analog signal using floating point math with (Total = Total + increment) will eventually see their totalizers stop totalizing regardless of which integration rule is chosen. Straightforward totalizing as above may be fine for batching but will be problematic when used for representing long-term usages, for example.

 

[Bit_Bucket_07]

1)4) You may be right about a program suddenly becoming disfunctional all on its own. I've never seen that, but I've only been doing this for thirty years or so.

Don't feel bad, Tom. I had been doing PLC programming for 30 years before I first ran into this problem.

I am attaching a screen-shot of a runtime accumulator rung that I had used in a SLC500 program. If you are capable of replicating this rung in a SLC500 and running it, you will see for yourself that it is quite capable of logging and displaying runtime hours in decimal format. That is, until the accumulator register reaches a value of 8192. After that point, the value of the accumulator register will never change due to rounding errors in the floating point math function. If the number in the accumulator register becomes large enough, than a similar ADD function will begin to round off additions that have a value greater than 1.

Ignore this issue at your own peril.

 

[Tom Jenkins]

Don't feel bad, Tom. I had been doing PLC programming for 30 years before I first ran into this problem.

Excellent comeback.

This appears to me to be a defficiency in the RSLogix 500 and not an indictment of the fundamental methodology. Have you hit tech support with this? What was their response?

 

[Bit_Bucket_07]

Excellent comeback.

This appears to me to be a defficiency in the RSLogix 500 and not an indictment of the fundamental methodology. Have you hit tech support with this? What was their response?

Machine epsilon is different for different processors, but it exists in every processor. It is merely a question of how far your math function can operate before it hits a wall.

 

[zova]

By the way, it is interesting to compare ε of various PLCs. As I said before ε of Siemens S7 PLC is 5.960464e-8. Could somebody share here results of PLCs which is working with?

 

[Ray S]

Hi,
I am Working on a similar application using pulsed and analog output flowmeters and then totalizing the flowrates. We found it is easier and relaible to use an external totalizer installed at each flowmeter location with a 4-20ma output that tracks the total flow,then scale the 4-20 for 0-999999 in the PLC. When the totlaizer reads full scale it will reset to zero.Laurel Electronics has a totlaizer that will output an analog signal to track either flowrate or total flow.

 

[Bit_Bucket_07]

Hi,
I am Working on a similar application using pulsed and analog output flowmeters and then totalizing the flowrates. We found it is easier and relaible to use an external totalizer installed at each flowmeter location with a 4-20ma output that tracks the total flow,then scale the 4-20 for 0-999999 in the PLC. When the totlaizer reads full scale it will reset to zero.Laurel Electronics has a totlaizer that will output an analog signal to track either flowrate or total flow.

I can't imagine this method providing more accurate results than simply integrating the flow rate analog input in your PLC logic. After all, you're still relying upon an analog input for totalization, plus you're having to account for the reset to zero in your accumulation logic. All that I see in this setup is two additional 4-20 mA devices (totalizer output and 2nd PLC analog input) for which calibration drift could become an issue. This strikes me as a very expensive patch for a non-existent problem. That said, it is probably a less expensive solution than using a high speed counter module for each flowmeter.

 

[danw]

an external totalizer installed at each flowmeter location with a 4-20ma output that tracks the total flow,then scale the 4-20 for 0-999999 in the PLC. When the totlaizer reads full scale it will reset to zero.

That technique of totaling to some maximum value and then resetting the totalizer was used in analog strip chart recording for decades, where one first channel graphed the rate signal and a second 'integrator' channel graphed along the edge of the chart showing a series of sawtooth waves, each sawtooth representing a total to the max, and then a reset back to zero. The tech would have to count the number of sawteeth to get a grand total. It's so old (disappeared with microprocessors in the mid-late 1970's) that I can't find an image on the web . . .

But, I think you're kidding yourself as to the ability of a pair of commercial/industrial analog signals to provide a resolution of one in a million.

To do so with analog 4-20mA would require resolution of 0.000016mA or 0.016uA and assuming the electronic circuit could hold a baseline offset of 4.00000000 mA (or its equivalent voltage) stable enough to not unduly influence the uncertainty of the measurement, it would take a 20 bit A/D, which resolves one part in 1,048,576.

Who does 20 bit A/D's in the PLC world?

You might designate the span as "one million", but there have to be lots of lower significant digits that are disappearing in non-resolution.

Isn't the 4-20mA really one part in 10,000, appearing as 9,999 with an assumed multiplier of 10^2?

 

[danw]

This epsilon effect for floating point calculations is new to me.

Check me out here. If I read this epsilon effect correctly, for the SLC example, the counter failed to increment once it hit 8,192 hours, correct?

The reason is that one second, represented as a floating point value for purposes of being added to the 8192 hours value, is smaller than the minimum value that will not disappear when the sum is rounded off. The rounding action makes small values less than the epsilon value disappear when added to large values because of 'rounding'.

8192 hours = 29,491,200 seconds
1 second with respect to the total of 29,491,200 seconds is
1/29,491,200 = 3.3008420138e-8

If 3.3008420138e-8 is less than the epsilon value for the calculator, then the sum when rounded off does not increase, but remains the same.

Did I get it?

Dan

 

[zova]

No. Algorithm of calculation of machine epsilon is very simple. You have to declare three variables - accumulator, increment and epsilon itself.

increment = 1
while accumulator <> accumulator + increment / 2
increment = increment / 2
wend
epsilon = increment