Related to what Tom added below, the Timer blocks are not connected to the time
on the station block. They merely accrue value based upon their period. We
use Timer blocks to ensure minimum duration for processes and whenever we
experience CP over-runs, the duration is extended and not accounted for since
the Timer block does not update when it is not run. Not something we like to
see, but it does not hurt our application.
Matt
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Terry Doucet
Sent: Friday, July 07, 2017 11:46 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] TIM block vs CALCA for timers
Tom, Joe,
We used an ACCUM block to count, then used a peer connection to save the count
and then use that count if your ACCUM block initializes or it's CP reboots.
You lost the count for the reboot or initialize time span, but at least you did
not have to start at zero.
Terry
________________________________
From: foxboro-bounce@xxxxxxxxxxxxx <foxboro-bounce@xxxxxxxxxxxxx> on behalf of
Tom VandeWater <tjvandew@xxxxxxxxx>
Sent: July 7, 2017 1:13 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] TIM block vs CALCA for timers
Joe,
I have used TIM blocks as motor run timers/run hour meters. I connect the
run status .CIN Parameter of a CIN block to the .TIMR1R parameter of a TIM
block so .TIMR1V increments in seconds any time the motor run status is true.
I tested to see if there was a limit to the value that can accumulate in
.TIMR1V and it can at least accumulate to 10 years worth of seconds, but the
value will be lost if the CP ever initializes. If you want to display hours you
will have to do the math in another block. I don't know if the TIM block uses
the .SECOND parameter of the STATION block as a trigger or if it is based on
the Period/Phase processing of the TIM block itself.
Tom Vandewater
Control Conversions, Inc.
Sent from my iPhone
On Jul 7, 2017, at 5:08 AM, Currano, Joe <Joseph.Currano@xxxxxxx> wrote:
List,
I would like to know about the accuracy/capabilities of a TIM block for
measuring equipment run time.
Awhile back I created a CALCA block for runtime based on info from the list.
Looking at data in an external historian, I notice some inaccuracy, and
sometimes 1 minute of actual runtime shows up as less than a minute in the
block output, i.e. running "slow" at times. (Before the CALCA block we had a
RAMP block, with appropriate scaling, which sometimes ran fast, giving more
than 24 hours in a day.) So I'm thinking of trying a TIM block in case it is
more accurate. Question for anyone who uses TIM blocks:
-How accurate is it?
-What does it use to count time? In the CALCA timer, I count up 1 sec each
bpc with a period of 1 second. Does TIM use the station block date and time,
or is it based on bpc too? The Period parameter doesn't seem to make a
difference in how fast it counts.
-What's the maximum time it can count up to? Measuring run time, we are going
into the thousands of hours, and TIM block seems to measure in seconds, so
maybe 10,000 hours or 36,000,000 sec would be a good capability. Just want to
make sure it doesn't hit some limit too early.
-Can the timers in TIM blocks be reset by a Boolean from a CIN block or do
you need a sequence block to do it? I want one timer to count forever anytime
the equipment runs, and one to be reset to zero occasionally by the
operators. Don't need a preset value.
Thanks for any info you can give.
-Joe
______________________________________________________________________
___ This mailing list is neither sponsored nor endorsed by Schneider
Electric (formerly The Foxboro Company). Use the info you obtain here
at your own risks. See the disclaimer at
www.thecassandraproject.org/disclaimer.html<http://www.thecassandrapro
ject.org/disclaimer.html>
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
