Re: [foxboro] Clearing Accum block
- From: Kevin FitzGerrell <fitzgerrell@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Fri, 21 Oct 2005 08:43:13 +1300 (NZDT)
Brian,
CPxxxx_STA:STATION.MINUTE.~X0000 should work fine and will reset on the hour,
although as Alex was pointing out a connection to the minute without the boolean
extension would reset on the minute after the hour.
I usually just use CPxxxx_STA:STATION.MINUTE.~
The .~ in my connection is a NOT so I get a TRUE when the time ticks over to a
new hour, and a FALSE the rest of the time. CLEAR is true for the whole zero
minute, but that's OK because as Alex pointed out, it only clears the
accumulator on the rising edge.
Francois's solution is a bit more elegant. Where I rely on any number not zero
to be considered a boolean TRUE, he actually inverts a bitwise XOR with 0000 and
the CP minute, which is 1 when the minute is 0 and is 0 for the rest of the
hour.
Regards,
Kevin FitzGerrell
Control Systems Engineer
Carter Holt Harvey, Ltd.
+64 27 460 9994
Quoting "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>:
> According to the block documentation for the ACCUM block, the CLEAR =
> (reset)
> input works as follows:
>
> CLEAR=20
> Clear is a Boolean input that sets the accumulator output to zero =
> when
> CLEAR makes a zero-to-one transition. The ACCUM block automatically
> clamps this input at zero if no connection exists.
>
> Since it works on the rising edge, the reset would occur 1 minute after
> =
> the
> top of the hour. That is, at 10:01 not 10:00 the ACCUM block would be =
> reset.
>
> This approach will reset the accumulator every hour, but not at the top
> =
> of
> the hour.
>
>
> The three ways that I know to do it at the top of the hour are:
>
> 1) Connect it to a CALC output
> 2) Write an IND block to set it using an external reference
> 3) Write a script on an AW to reset it.
>
>
> The problem with the first approach is that one would not be able to =
> manual
> reset it from the ACCUM faceplate. The CLEAR parameter would be secured
> =
> to
> the CALC output. Sometimes this is an issue.
>
> The problem with the second approach is that you have to write a =
> sequence
> block, but the CLEAR parameter would not be secured and the =
> implementation
> is not fault tolerant.
>
> The problems with the last approach are:
> 1) If the AW is down, the reset will not occur.=20
> 2) One might forget about the script during an upgrade and not =
> reschedule
> it.
> 3) One-shots across the Nodebus can eventually get expensive.
>
> Me? I'd use the sequence block unless I knew that a manual reset would
> =
> not
> be needed.
>
>
> Hope this is useful.
>
>
> Regards,
> =20
> Alex Johnson
> Invensys Systems, Inc.
> 10707 Haddington
> Houston, TX 77063
> +1 713 722 2859 (voice)
> +1 713 932 0222 (fax)
> +1 713 722 2700 (switchboard)
> alex.johnson@xxxxxxxxxxxxxxxx
> =20
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx =
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of "Perrot, Fran=E7ois"
> Sent: Thursday, October 20, 2005 3:56 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Clearing Accum block
>
> Brian,
>
> An idea is to make the following connection on the reset param:
>
> CPxxxx_STA:STATION.MINUTE.~X0000 where CPxxxx is the name of the CP =
> which
> contents the ACCUM block.
>
> Each time the minute is equal to zero (Once per hour) it will reset the
> accum
>
> Regards
> F.PERROT
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx =
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of BrianLong
> Sent: jeudi 20 octobre 2005 14:32
> To: Foxboro
> Subject: [foxboro] Clearing Accum block
>
> There are a number of ways to do this but I though someone out there =
> might
> have a "better or clever" way. I need to clear an ACCUM block at the =
> top of
> every hour.
> Thanks in Advance,
> Brian Long
> Arkansas Kraft
>
>
> =20
> =20
> ___________________________________________________
> ____________________
> 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
> =20
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>
> =20
> =20
> ______________________________________________________________________
> _
> 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
> =20
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe: =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>
>
>
> ______________________________________________________________________
> _
> 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: //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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
