Re: [foxboro] Timer Question
- From: "Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Thu, 11 Oct 2007 12:20:00 -0400
Matt,
You might want to ignore IDLE time for the CP's. You do not see the =
total of CPLOAD + IDLE =3D 100 very often. =20
Guidelines recommend 60 max for Fieldbus load and 80 Max for Total =
CPLOAD. If you can get to these values, you should be OK.
But the real truth lies in CP overruns. You really want the integrator =
reading zero at all times. Maybe if you are doing an engineering =
function like ICC and you exit which causes a CHECKPOINT you could allow =
a count or two on the overrun.
You can grab the CP60 loading spreadsheet (Excel) from EDOC or the Fox
Web site if you have a contract. The Excel will allow you to do a=20
"what if" analysis without actually changing block periods or phases in =
the CP60 until the Excel says your loading is OK.
The Excel for CP60 should be pretty darn close to what you see in the =
running CP. If you have a lot of sequence blocks you might have to play =
with the Excel defaults.
If you slow down all blocks on a particular input IO card, you should =
actually change the period of the corresponding ECB so that the IO =
integration period matches your AIN period. Try to eliminate aliasing.
If you phase your control loops (AIN, PIDA, AOUT) watch that you do not =
accidentally change the order of block processing and add an extra =
period of delay.
The OM overruns are a different matter. If you have no peer connections =
for control loops or shutdown control, you may be able to accept a few =
OM overruns per day. This usually means a delay in Historian receiving =
data changes or CRT screens being delayed in their updates. In most CP's =
the OM overrun is less critical. But there may be cases where OM =
overruns are totally unacceptable, too.
Terry
-----Message d'origine-----
De=A0: foxboro-bounce@xxxxxxxxxxxxx =
[mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Gunter, Matt
Envoy=E9=A0: 11 octobre 2007 11:08
=C0=A0: foxboro@xxxxxxxxxxxxx
Objet=A0: Re: [foxboro] Timer Question
MeeOuch! As Spencer Katt of eWeek would say!
Thanks to everyone for their comments.
We are running CP60s and I have suspected loading. Here's the skinny
...
CP Field Bus Scan Cont Blks Seq Blks Total
Station Idle
Good Timer CP 61.4 13.4 3.2 78.0
62.9
Bad Timer CP 1 121.2 15.8 7.6 144.6
77.6
Bad Timer CP 2 114.8 13.0 6.0 133.8
80.4
When I check the loading in our lab, the field bus scan is zero - of
course since it is not hooked to any real hardware.
Apparently the higher station idle time is not indicative of resources
available to process timer blocks. It appears that I am going to have
to figure out a way to reduce field bus scanning.
Best Regards
Matt Gunter
ATK Launch Systems
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex P (IPS)
Sent: Tuesday, October 09, 2007 10:37 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Timer Question
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=3D20
> executing in it's scheduled slot. So, although the TIM blocks =
are=3D20
> always executed, the extra overrun slots in between the normal =
block=3D20
> execution slots affects the timing. This also affects ACCUM blocks
and
> I believe CALC block timing (DON, DOFF, etc).
>
> Kevin
>
> -----Original Message-----
> =3D3D3D3D46rom: 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
>
=3D3D
=3D3D
_______________________________________________________________________
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
=3D3D
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
=3D3D
Confidentiality Notice:
This e-mail and any associated files are intended solely for the
individual=3D3D or entity to whom they are addressed. Please do not =
copy =3D
it
or use it for =3D3D any purposes, or disclose its contents to any other
person. Further, this e=3D3D -mail and any associated files may be
confidential and further may be legal=3D3D ly privileged. This email is =
=3D
from
the Invensys Process Systems business uni=3D3D t of Invensys plc which =
is =3D
a
company registered in England and Wales with i=3D3D ts registered office =
=3D
at
Portland House, Bressenden Place, London, SW1E 5BF =3D3D (Registered =3D
number
166023). For a list of European legal entities within t=3D3D he =
Invensys
Process Systems business group, please click here http://www.in=3D3D
vensys.com/legal/default.asp?top_nav_id=3D3D3D77&nav_id=3D3D3D80&prev_id=3D=
3D3D=3D
77.
If you have received this e-mail in error, you are on notice of its
status.=3D3D Please notify us immediately by reply e-mail and then =
delete
this message =3D3D from your system. Thank you for your co-operation. =
You
may contact our Help=3D3D desk on +44 (0)20 7821 3859 / 2105 or email
inet.hqhelpdesk@xxxxxxxxxxxxx T=3D3D his e-mail and any attachments =3D
thereto
may be subject to the terms of any a=3D3D greements between Invensys =3D
(and/or
its subsidiaries and affiliates) and the=3D3D recipient (and/or its
subsidiaries and affiliates).
=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=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
Other related posts:
