Re: [foxboro] 12 hour ave

Brian,
    If the samples do not have to much deviation (and if it is the case you
can support a little error), you can use the following calc. I tryed it and
seems to work.
    Ave[t] = ( Ave[t-1] - ( Ave[t-1] / N ) ) + Sample[t] / N

Where
    Ave[t] is the average at this scan
    Ave[t-1] is the average in the previous scan
    Sample[t] is the new value to add to average
    N is the number of samples in the average.

The upper limit to N is 43200 (12 hours at 1 sample per sec.)

The calc steps are:
PERIOD= 1 sec.
RI01 = Sample
RI02 = Connected to RO01 (RO01 = Ave[t] / RI02 = Ave[t-1])
RI03 = Connected to RO02 (RI03 = N)

The HSCO of RO02 must be 43200

CST
IN RI02
IN RI02
IN RI03
DIV
SUB
IN RI01
IN RI03
DIV
ADD
OUT RO01
CST
IN RI03
IN 1
ADD
OUT RO02

I hope it will work.

Regards

Jorge Monsalvo
IVControl S.R.L.























----- Original Message -----
From: "Brian Long" <blong@xxxxxxx>
To: <foxboro@xxxxxxxxxxxxx>
Sent: Thursday, February 26, 2004 2:15 AM
Subject: Re: [foxboro] 12 hour ave


>
> I was hoping there was an easy way.  I think Foxboro needs a new block.
> Thanks for all the help.
>
> Brian
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
> [mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Jim Mowrey
> Sent: Wednesday, February 25, 2004 8:58 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] 12 hour ave
>
>
> So far, all the solutions I've read use a tremendous amount of memory
and/or
> blocks in order to store 12hours x 3600 sec/hr values and update them.
>
> How about this?  (Just off the top of my head, so may need work.)  If you
> loosen the accuracy somewhat, create 13 ACCUM blocks, each tied to the
> measurement AIN.  Create a few CALCA blocks using the time of day command
to
> monitor the current time.  (Or a IND block, if you prefer).  The
non-current
> ACCUM blocks HOLD bits would be set by the CALCA blocks based on time of
> day.  So, only one ACCUM block would be actively accumulating.  You'd know
> how long it had been running based on the time command in the CALCA
blocks.
>
>
> Say that ACCUM block 10 of 1 to 13 was currently not in HOLD, and it was
20
> minutes after the hour.  Add the OUT's from ACCUM block 1-10, 12 and 13
and
> (3600-1200)/3600 * ACCUM block 11's OUT value.  This gives you a fairly
> accurate sum of the accumulated value for the last 12 hours.  The only
> inaccuracy is in the estimation that the first hour's accumulation was at
a
> steady rate for the fraction of an hour that you use in the sum.  In this
> case, we've added 2/3 of the accumulated value in block 11 and all of the
> other blocks including block 10.  Note block 10 has been running for only
20
> minutes or 1/3 hour, or 1200 seconds.
>
> Now, divide the sum by 3600*12 to give the "average" rate over the last 12
> hours; this is done in the CALCA blocks as well.  At the hour, place ACCUM
> block 10 in HOLD, freezing its value, and clear the value stored in ACCUM
> block 11, and remove it from HOLD.  Now, block 11 is the only accumulating
> (not in HOLD) ACCUM block, and a fraction of block 12 is added in
depending
> on how many seconds it is past the hour.
>
> A back of the envelope calculation shows this should be accurate to +/- 4%
> assuming that at 30 minutes past the hour 12 hours ago the measurement
went
> from zero to its current value.  And, it only uses 13 ACCUM blocks and 2
or
> so CALCA blocks, for about 19 block equivalents.
>
> Jim Mowrey
> Maxis Automation
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
> Behalf Of Brian Long
> Sent: Wednesday, February 25, 2004 6:54 PM
> To: Foxboro
> Subject: [foxboro] 12 hour ave
>
> I need to take an analog input running at 1 sec and average it over 12
> hours.  I need to display the value so I can't use the historian
functions.
> Anybody got a simple solution?
> Thanks,
> Brian Long
> E&I Superintendent
> Green Bay Packaging
> Arkansas Kraft Division
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
>

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: