Analog Output

Let's say your flow meter's output is scaled in liters per minute. Capture its value once per second. Divide that by 60 (there are 60 seconds in one minute). Each time you capture a value, add it to a running total. The running total will be liters.
When using this method for large flows over a long period of time be aware of the limitations of your PLC's floating point arithmetic. A 32-bit floating point number gives you seven significant digits. If you try to accumulate over too long a period you could run into a situation where the one-second sample value is too small relative to the cumulative total.
Consider doing your arithmetic using 32-bit integers instead.
 
very inaccurately.


For each scan:

  1. record the time of the CURRENT scan when the [total] will be updated
  2. calculate the difference in time since the PREVIOUS scan when the [total] was updated
  3. convert the difference in time to [difference in seconds]
  4. convert the 4-20mA analog input signal (for example, 0:16383 or -32768:32767) to [flowrate] (lb/sec, kg/s, m**3/s, etc.)
  5. multiply the [difference in seconds] by the [flowrate]
  6. add the product from the previous step to the [total]
  7. that [total] is an approximation of the [totalized flow rate] from the time of first scan.
Many steps have been left out here:

  • what level of accuracy is required? *
  • we do not know the process
  • we do not know the brand of PLC
  • we do not know the style of programming (LD vs. ST vs. FBD etc.)
  • how do you want to initialize the [total] when the PLC is powered on, and there is no PREVIOUS scan?
  • how do you want to handle times when the PLC is powered off but the process is running with a non-zero flowrate?
  • what clocks (or timers) are available to record the time of each scan, and how does that affect the accuracy? If the scan time between updates of [total] will be very short (milliseconds), having a clock that counts in steps very much smaller than a millisecond is probably necessary.
* All computer programs model some portion of the physical world; the only real choice to make is the required level of fidelity of that model; everything else flows from that choice.
 
suborbital, thanks for your input, I just started Simulating PLC programmes beginning of the year .Its a general preamble, I will buy mini Siemens or Allan Bradley PLC in course of the year.
I am an African, PLC is new here
 
Let's say your flow meter's output is scaled in liters per minute. Capture its value once per second. "


Steve Bailey, if the flow meter output is scaled liters per minute, the valued should be captured once per second or minutes ?
 
Last edited:
The value captured once per second and divided by 60 before adding to the running total.
If, instead, you decide to sample every five seconds, divide the sample by 12 before adding to the running total.


drbitboy's comment, "very inaccurately" was appropriate. Using a PLC to integrate an analog flow signal is not the best way to totalize. Better to let your flow instrument totalize if it has that capability. Or configure your flow instrument to output a pulse at some increment of volume and let the PLC count those pulses.
 
Let's say your flow meter's output is scaled in liters per minute. Capture its value once per second. Divide that by 60 (there are 60 seconds in one minute). Each time you capture a value, add it to a running total. The running total will be liters.
When using this method for large flows over a long period of time be aware of the limitations of your PLC's floating point arithmetic. A 32-bit floating point number gives you seven significant digits. If you try to accumulate over too long a period you could run into a situation where the one-second sample value is too small relative to the cumulative total.
Consider doing your arithmetic using 32-bit integers instead.

i
Steve Bailey, if the flow meter out is scaled in liters per minute - capture its value per second or per minute?
 
The value captured once per second and divided by 60 before adding to the running total.
If, instead, you decide to sample every five seconds, divide the sample by 12 before adding to the running total.


drbitboy's comment, "very inaccurately" was appropriate. Using a PLC to integrate an analog flow signal is not the best way to totalize. Better to let your flow instrument totalize if it has that capability. Or configure your flow instrument to output a pulse at some increment of volume and let the PLC count those pulses.

Thanks Steve, It is well noted
 
The value captured once per second and divided by 60 before adding to the running total.
If, instead, you decide to sample every five seconds, divide the sample by 12 before adding to the running total.


drbitboy's comment, "very inaccurately" was appropriate. Using a PLC to integrate an analog flow signal is not the best way to totalize. Better to let your flow instrument totalize if it has that capability. Or configure your flow instrument to output a pulse at some increment of volume and let the PLC count those pulses.
I recently did two totalizer comparisons. One with E+H magtube and ladder math in Rockwell logix continuous task. The other compared a Foxboro magtube against logix totalizer fb. In both cases, I would characterize the results as accurate, 1% difference.
 
I recently did two totalizer comparisons. One with E+H magtube and ladder math in Rockwell logix continuous task. The other compared a Foxboro magtube against logix totalizer fb. In both cases, I would characterize the results as accurate, 1% difference.

I concur. 1% is reasonable. 1% of 500gpm is reasonable. 1% of a 5,000,000 total "looks" very inaccurate, but it is still 1%. The size of the error is less of a problem than the fact that it is cumulative with a totalizer. Then there's the "man with two watches" problem. If there is a totalizer on the meter, and you are totalizing from sampling analog signals from that same meter, the totals will never exactly match. The end user will "never know for sure what time it is" and begin to distrust the system.
 
'possibly' cumulative. It could be straight offset related to low flow cutoffs etc and how signalscould be processed different internally vs externally to the analog input. Had I done a longer trial, the error may have gone down. Or up.
 
I recently did two totalizer comparisons. One with E+H magtube and ladder math in Rockwell logix continuous task. The other compared a Foxboro magtube against logix totalizer fb. In both cases, I would characterize the results as accurate, 1% difference.


Magtube is a technology that touts a 0.5% (or better) accuracy, and these totalizer apps achieved 1% accuracy between two meters of the same type.


When adding hundreds or thousands of numbers together one time, and then a second time, the expectation is much better than a 1% agreement. So while 1% is a very acceptable accuracy in an engineering or accounting (e.g. custody transfer) sense, it is at the outside edge of accurate compared to the capability of the meters.


But to be fair, neither is it very inaccurate.



"Very inaccurately" referred as much to the inherent challenge of flow measurement in an assumed operational and industrial setting, as well as to the effect of noise vs. sampling period in a totalizer application where flowrate is variable (if it's not variable, then a totalizer is not required).


Magtubes lessen the problem, they don't eliminate it.
 
Nothing eliminates everything. I would value a high quality scale vs flow meter, but then you have to deal with scale error etc. Some people would tell you that if you are using an analog input vs tcp/ip, you have no business talking accuracy...it goes on and on. Check against the best standard you can, and accept the results or make changes that matter.
 
I always convert the signal to engineering units first, and if the measurement has a lot of bounce in it I use digital filtering to increase stability.

Then I use the trapezoidal rule ( https://www.intmath.com/integration/5-trapezoidal-rule.php) to totalize.

volume = Δt x 1/2 (q1 + q2)

If your flowrate is well behaved and your time increment is reasonable the accuracy is good. Note that sometimes the actual flow curve will be above the top of the trapezoid and sometimes below it, which tends to even out the error.
 

Similar Topics

Hello! Hope you are great. I need to make a change in a PLC with ladder logic. I will mount a analog valve and I need to control it in ramp up...
Replies
7
Views
292
I have a 170AAO92100 card that I am interested in using as a 10 volt output. Is there setup that I have to do in order to change output or simply...
Replies
0
Views
82
Hi We're having issues with an FX1N-1DA-BD Analog output module. We're using an metallic contamination sensor MCS 1000 to detect particles. This...
Replies
1
Views
105
I am having trouble with getting no control of my analog output signal. I am using the SCL function block to control my analog output. The logic...
Replies
11
Views
232
I have a program that I am gradually piecing together (my first program). There are 4 cascading timers that turn Y001 and Y001 + Y002 on and off...
Replies
8
Views
534
Back
Top Bottom