Re: [foxboro] Timing changes on loaded CP40
- From: <jmowrey@xxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 12 Sep 2005 16:21:22 -0400
I believe that there is one exception to the use of BPC in blocks vs. clock. I
think that AIN blocks connected to a pulse input card (with appropriate SCI)
use clock time vs. BPC.
Any others?
Jim Mowrey
>
> From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
> Date: 2005/09/11 Sun PM 09:56:10 EDT
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Timing changes on loaded CP40
>
> Actually, I was trying to say that the blocks DO NOT use the clock directly.
> They count BPCs. So, skipped BPCs can have an impact on CALC block timers
> (last longer), ACCUM block totals (read low), and PID block tuning.
>
> Since the PID block is running less often than expected, the tuning should
> be adjusted to match the change in execution frequency (or you should fix
> the overruns).
>
>
> Regards,
>
> 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
> I hope to see you at the Invensys Process System User Group meeting October
> 3-6 in Houston, TX -
> www.invensys.com/usergroup2005
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of Adam.Pemberton@xxxxxxxxxxxx
> Sent: Sunday, September 11, 2005 4:16 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Timing changes on loaded CP40
>
> So Alex, are you saying that the PID algorithm timing should still be
> correct since it's off some sort of scanning scheduler based on the
> clock?
>
> Regards
> Adam
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx
> <mailto:foxboro-bounce@xxxxxxxxxxxxx> ] On Behalf Of Johnson, Alex P
> (IPS)
> Sent: Monday, 12 September 2005 4:31 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Timing changes on loaded CP40
>
> The blocks don't actually use elapsed time for their calculations, they
> use a BPC counter.
> For that reason, you see the observed behavior on things like ACCUM
> block and CALC block in heavily loaded Control Stations.
>
> Regards,
>
> 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
> I hope to see you at the Invensys Process System User Group meeting
> October
> 3-6 in Houston, TX -
> www.invensys.com/usergroup2005
> <outbind://4/www.invensys.com/usergroup2005>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx
> <mailto:foxboro-bounce@xxxxxxxxxxxxx> ] On Behalf Of
> Adam.Pemberton@xxxxxxxxxxxx
> Sent: Thursday, September 08, 2005 4:54 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Timing changes on loaded CP40
> I have recently discovered that the timer for the OSP instruction of a
> LOGIC block that is configured to run at 60 seconds continuously is
> running at around 72 seconds. The relevant instructions are:
> CST
> IN ~BO02
> OSP 60
> OUT BO02
> which is meant to generate a low pulse for one scan very 60 seconds.
>
> The CP is heavily loaded (~1.5 overruns/sec, 973328 total memory free)
> but I would not expect it to affect times. Of course it probably also
> means the PID integral gains for the CP are also being affected
> (admittedly only by around 17%).
>
> Is this normal behaviour for a heavily loaded CP40?
>
> Regards
> Adam Pemberton
> Coordinator Process Control
> Lihir Management Company
>
> Adam Pemberton
> Coordinator Process Control
> Lihir Management Company
> Ph: +675 9865 655
> Fax: +675 9865 666
> Mob: Nogat
> Postal:
> Australia: GPO Box 905, Brisbane, QLD 4001
> PNG: PO Box 789, Port Moresby, NCD
>
>
> ----------------------------------------------------------------------------
> ----------------------------------------
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed.
> If you have received this email in error please notify the
> originator of the message. This footer also confirms that this
> email message has been scanned for the presence of computer viruses.
>
> Any views expressed in this message are those of the individual
> sender, except where the sender specifies and with authority,
> states them to be the views of LMC.
>
> ----------------------------------------------------------------------------
> ----------------------------------------
>
>
>
> _______________________________________________________________________
> 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
>
>
_______________________________________________________________________
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:
