Re: [foxboro] Timer Question
- From: "Johnson, Alex P \(IPS\)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 9 Oct 2007 12:36:35 -0400
It was corrected for the ACCUM block some time ago; I can't remember the
release.
Regards,
Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Douglas G. Lloyd
Sent: Tuesday, October 09, 2007 5:42 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Timer Question
Hi All,
The CP overrun time loss issue used to affect all blocks that have time
based algorithms (TIM, ACCUM, RAMP, CALC family, PID family, etc). CP
overruns are much less of an issue with the latest processors, but it
would
be interesting to know if this problem has actually been corrected.
Does
anyone know for sure??
Regards,
Doug
DGL Controls
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Johnson, Alex P (IPS)
Sent: Tuesday, October 09, 2007 2:15 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Timer Question
All blocks are processed without exception - today. This was not the
case in very early versions of the I/A Series. If you have a Y2K
compliant version, all blocks will run.
The BPC will be extended (typically doubled) and the left over time in
the new, improved (longer) BPC is used for overheads.
This behavior allows the CP to degrade gracefully under overload
situations, but does impact timers. The ACCUM blocks suffered this
problem through many releases, but I believe that it has been corrected
to use the current reading for the previously missed cycles as a better
estimate than ignoring the cycle.
Regards,
Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kevin Fitzgerrell
Sent: Tuesday, October 09, 2007 4:30 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Timer Question
Ken,
Sorry, I missed your point before.
Does this mean that TIM blocks are processed in an extended BPC while
other blocks in the same overloaded CP may be processed in an overrun?
My understanding was that in a control station, all blocks were
processed without exception, the BPC overrunning to allow that. Seems
a bit odd if the TIM blocks are treated differently, as that could
change the normal compound/block processing order.
Which manual was that quote from?
Regards,
Kevin FitzGerrell
On 10/9/07, Kevin_Fitzgerrell@xxxxxxx <Kevin_Fitzgerrell@xxxxxxx> wrote:
> Ken,
>
> While the TIM blocks are always processed, the next cycle is delayed
if
> overloaded. The timing on the TIM blocks depends on each block
> executing in it's scheduled slot. So, although the TIM blocks are
> always executed, the extra overrun slots in between the normal block
> execution slots affects the timing. This also affects ACCUM blocks
and
> I believe CALC block timing (DON, DOFF, etc).
>
> Kevin
>
> -----Original Message-----
> =3D3D46rom: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Moore, Kenneth, Celanese/US
> Sent: Tuesday, October 09, 2007 6:31 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Timer Question
>
>
> I'm looking at an old block book, but the last entry is a Note that
> states:
> "In a serious system overload, TIM blocks are always processed, even
if
> it delays the next BPC".
>
> So if you seriously overloaded, every additional TIM block added to
the
> system extends the BPC.
>
>
>
> Ken Moore
> Celanese
> Enoree SC
>
=
=
_______________________________________________________________________
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=3Djoin
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=
Confidentiality Notice:
This e-mail and any associated files are intended solely for the individual=
or entity to whom they are addressed. Please do not copy it or use it for =
any purposes, or disclose its contents to any other person. Further, this e=
-mail and any associated files may be confidential and further may be legal=
ly privileged. This email is from the Invensys Process Systems business uni=
t of Invensys plc which is a company registered in England and Wales with i=
ts registered office at Portland House, Bressenden Place, London, SW1E 5BF =
(Registered number 166023). For a list of European legal entities within t=
he Invensys Process Systems business group, please click here http://www.in=
vensys.com/legal/default.asp?top_nav_id=3D77&nav_id=3D80&prev_id=3D77.
If you have received this e-mail in error, you are on notice of its status.=
Please notify us immediately by reply e-mail and then delete this message =
from your system. Thank you for your co-operation. You may contact our Help=
desk on +44 (0)20 7821 3859 / 2105 or email inet.hqhelpdesk@xxxxxxxxxxxxx T=
his e-mail and any attachments thereto may be subject to the terms of any a=
greements between Invensys (and/or its subsidiaries and affiliates) and the=
recipient (and/or its subsidiaries and affiliates).
_______________________________________________________________________
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:
