Best way of totalizing flow?

[zova]

sorry

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

 

[rootboy]

If at all possible, just use a meter that puts out one pulse for every 10m3. Or if you want better resolution, get one that does one pulse per 1m3.

That's how water and gas meters do it. This way you let the meter do the "totalizing" before it sends out a pulse. In other words, it stays as an analog signal/value in the meter until it reaches a one pulse unit. It then sends out a pulse and you wait until the next 10m3 goes by before getting the next pulse.

Just remember, anytime that you try to stuff an infinitly variable analog value into a pre-defined digital one you are going to have a tight fit...

What are you metering?

 

[DwSoFt]

we have our meters at 0.1m3/pulse and a few even at 0.01m3/pulse. and some that are HART back instead of pulse signal. i prefer the meter doing the totalizing than doing it in the plc. bc as already mentioned, the analog signal wont be exact enough sometimes to accurately totalize. i mean if you are in a pinch, or dont have the evertra wires then go for it, but if you do have the wires, and the flow meter does it, then why not. it gives a good accurate totalized number. to prove the point you could do both and then compare results.

 

[danw]

For the example of the SLC counter counting seconds and converting to hours, the effect was the up count ceased at 8000 odd hours.

If the arithmetic had not been floating point, but just plain old incrementing a 32 bit register, would not a seconds counter have gone the full 4 billion odd (4,294,967,296) counts equivalent to 132 years?

Or is the conversion to hours or days or years the problem, where using floating point for the conversion is subject to the machine epsilon?

Dan

 

[jamesau]

Dan,

Integer arithmetic is exact in the sense that there is no rounding/truncation error. Floating point arithmetic experiences greater rounding/truncation error as the two operands increasingly differ in magnitude.

So, it can be a good idea to totalize to a small limit (say hour, or gallon, or whatever) and count up that small increment in an integer (using integer data types and operations).

The following link touches on the mechanics of floating point arithmetic and why it behaves as it does.
http://www.cs.uaf.edu/~cs301/notes/Chapter6/node3.html

 

[mellis]

Three possible methods...

Count pulses from meter in PLC.

Integrate analog signal from meter in PLC.

Communicate serially to totalizer in meter from PLC.

All of them work. All of them have advantages and disadvantages.

Count pulses works great if you want a total, not so great if you want flowrate. All arguments about missing counts, wiring noise are missing the point. Do it right it works, do it wrong and it doesn't. Just because you have seen it done wrong doesn't mean you should never use it.

Integrate analog signal. This one has limitations. The first one is, the accuracy of the analog signal itself. The second is the basic assumption that the flow is constant between samples. For example, this method always indicates low when the flow is ramping up, and indicates high when it is ramping down. There are techniques to eliminate the round off error you get with large floating point + small floating point. That's not a big deal if you do it right.

Serial communication to the flowmeter's internal totalizer. More difficult to implement, but easily the best all around. You have the full accuracy of the meter. No added error in signal conversion. You get to take advantage of features in the meter that would be difficult to implement in the PLC. Empty meter detection for one. In the case of mass flowmeters, the volumetric flow is based on the density at the time of sample, very difficult to do in the PLC. And it's the only way the local display and the PLC will ever match.

Any one of them may be the "appropriate choice" for an application. It depends on the requirements and the budget.

 

[Bit_Bucket_07]

Three possible methods...

Count pulses from meter in PLC.

Integrate analog signal from meter in PLC.

Communicate serially to totalizer in meter from PLC.

All of them work. All of them have advantages and disadvantages.

Count pulses works great if you want a total, not so great if you want flowrate. All arguments about missing counts, wiring noise are missing the point. Do it right it works, do it wrong and it doesn't. Just because you have seen it done wrong doesn't mean you should never use it.

Integrate analog signal. This one has limitations. The first one is, the accuracy of the analog signal itself. The second is the basic assumption that the flow is constant between samples. For example, this method always indicates low when the flow is ramping up, and indicates high when it is ramping down. There are techniques to eliminate the round off error you get with large floating point + small floating point. That's not a big deal if you do it right.

Serial communication to the flowmeter's internal totalizer. More difficult to implement, but easily the best all around. You have the full accuracy of the meter. No added error in signal conversion. You get to take advantage of features in the meter that would be difficult to implement in the PLC. Empty meter detection for one. In the case of mass flowmeters, the volumetric flow is based on the density at the time of sample, very difficult to do in the PLC. And it's the only way the local display and the PLC will ever match.

Any one of them may be the "appropriate choice" for an application. It depends on the requirements and the budget.

Precisely. It depends upon the requirements and the budget. Some applications in which you choose to read pulses will require a high speed counter module. That is an expensive proposition, as is serial communication to the meter. I disagree with your assertion that serial communication is the only means by which the PLC totalizer value will match the instrument display. I recently (several months ago) implemented a natural gas flow totalization application with high speed counters and my values always match those of the flow meters. I have often done conveyor belt scale totalization via integration of the analog input signal with no noticeable discrepancy between the PLC totalizer and the belt scale integrator totalization.

 

[DwSoFt]

not just serial communication, but direct communication in general, such as HART over the current signal wires, rs232/485, FIELDBUS, etc

 

[zova]

not just serial communication, but direct communication in general, such as HART over the current signal wires, rs232/485, FIELDBUS, etc

Do you really think programmes for flowmeters writes Great God when he comes from the sky?

 

[Bit_Bucket_07]

Do you really think programmes for flowmeters writes Great God when he comes from the sky?

Heh!

I've always understood that the software contained in microprocessor based instruments was written by mere mortals.

 

[DwSoFt]

we use HART protocol for totals on our main injection skids. and then at each individual well pad, they are pulses into the plc. many of the newer jobs i have been on they are using HART instead of pulses.

 

[danw]

Yeah, I know this thread is 8 months old, but I gotta comment.

A pulse from HART? Really?

I would assume that if HART is used that the HART value being used is the actual total that is calculated by the flow meter, the one least subject to error of any of the techniques.

Most HART enabled flow meters have an internal totalizer, the exception being differential pressure transmitters, which typically do not totalize, even though they're typically HART devices.

HART is not easy to implement; although it's more common in the DCS world, only a few high end PLCs offer HART AI cards. HART break-out boxes are of little value because an analog representation of a totalizer value is severely restricted by the limited dynamic range of an analog signal. Given the 'complexity' of handling HART, the people who do it typically do it to get the exact total value directly from the flow meter.

I suppose that a volumetric/mass pulse output could be available via HART, but why do that when the totalizer value is available?

 

[DwSoFt]

Yeah, I know this thread is 8 months old, but I gotta comment.

A pulse from HART? Really?

I Think you misread what I posted...

For clarification: We use the meter total over Hart like u said, not pulses over hart, on our main skids. well sites are still using pulses as PLC/RTU do not have hart compatible cards installed/available.

 

[NoName]

Hello all.
I've got a question regarding flow totalization.
My task is to output a signal when flow reaches 1m3.
The probe that monitors flow can measure flow at max 1450m3/h.

So this is what I have done:
I set up my analog input to give me the value at m3/s. (CF/s)

I then in a 1 sec interval add(CF/s) 10 times and then divide the value by 10 so that I get an approximate value of flow in this 1s time frame. I get the value (CF/s_ACT). I add (CF/s_ACT) to (CF).
When (CF) is greter or equal than 1.0 I output the signal for 100ms and also subtract (CF) by 1 to get the overflow value (OFL). I add the (OFL) value back to the (CF/s_ACT) variable.
This routine then cycles….

Is this the right way to solve this task, or have I missed something or gone completly in the wrong direction?

Thanks for your input in advanced.
Cheers
Al

 

[rootboy]

Is this the right way to solve this task, or have I missed something or gone completly in the wrong direction?

Thanks for your input in advanced.
Cheers
Al

If you can set your meter up to output a pulse rather than rate then you won't have a rounding issue. Use the rate of change that the pulses are coming in at to derive flowrate.

Reading the instantaneous analog value will create errors.