Re: [foxboro] TIM block vs CALCA for timers

  • From: Terry Doucet <Doucet427@xxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Fri, 7 Jul 2017 17:45:36 +0000

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.thecassandraproject.org/disclaimer.html>

thecassandraproject.org<http://www.thecassandraproject.org/disclaimer.html>
www.thecassandraproject.org
Disclaimer. The Cassandra Project. The Cassandra Project is an independent 
project by individuals interested in sharing their knowledge or information 
with like ...




foxboro mailing list:               //www.freelists.org/list/foxboro

FreeLists / Foxboro Discussion List<//www.freelists.org/list/foxboro>
www.freelists.org
The Foxboro Discussion List is an electronic mailing list by the users for the 
users. Topics mostly revolve around the I/A product platform, but discussion 
about other Foxboro products is also welcome and encouraged.



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 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.thecassandraproject.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



 
 
_________________________________________________________________________
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
 
foxboro mailing list:               //www.freelists.org/list/foxboro
to subscribe:           mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:        mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: