Re: [foxboro] Restricting the operators access to PID blocks

Ricordo , Kevin thanks again for your inputs.Andrini,
Now you know what we should do   :-)

In the absence of SSC , it is common to have  .RSP  parameter as interface
point to APC.
But as Kevin said , it gets more complicated when you want to use .RSP for
inner cascade loops , as they already have .RSP coming from existing  master
controller .

So to avoid the hassles of tracking and bumpless transfer (especially when
you have lot of slave loops),I think  it is better to write to .SPT and
restrict the operators from changing the setpoints in APC mode ( though I
dont know whether it is an accepted practice)

Regarding your next question, I think , we can make a custom  face plate
that will restrict the operators from changing the set point only but still
 allow them  to change the mode .

- Sivaram



On Thu, Jul 30, 2009 at 3:07 PM, Andriny Bt Rusman (R&T/PETH) <
andriny@xxxxxxxxxxxxxxx> wrote:

> Ricardo,
>
> That idea of using a customised faceplate is cool.  I think it is a very
> simple way if you really don't want the operators to write to the setpoint
> without all the logics required. I do have an issue using this way when an
> external controller is writing into the PIDE.
>
> To build on Sivaram's case, say we want to restrict it because another
> external controller, e.g. an APC controller will write the setpoint to a
> Manipulated Variable (MV), i.e. typically a PIDE/A.  I know PIDE/A SPT para
> is con/no-set, so this means APC can write to the SPT para.  Is this an
> accepted practice?
>
> Additionally, if we use the customised faceplate & if operator wants to
> take back control of the MV during an upset, won't the operator have to go
> to an APC MV list page to enable the SPT change?  This means he has an extra
> step to think about during an upset instead of just going to the controller
> faceplate & take back control (by putting it to Manual or Local).
>
> Best regards,
> Andriny Rusman
> Staff Engineer,
> Advanced Process Control,
> Group Technology Solutions,
> Level 8, Menara Dayabumi
> Phone: 03-2783 6317
> Petronet: 8-333-6317
> Fax: 03-2783 6499
> email: andriny@xxxxxxxxxxxxxxx
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Kevin Fitzgerrell
> Sent: Thursday, July 30, 2009 9:57 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] Restricting the operators access to PID blocks
>
> Hi Sivaram,
> Alternatively, you can connect the RSP and the LR parameters to other
> blocks
> and use those as your master - CALC block works nice for locking down a
> group of controls.  When your master block sets the LR of the PID to 0, the
> operator can change the setpoint as desired.  When LR is set through it's
> connection to 1, the RSP comes from the master and can't be changed in the
> faceplate.
>
> This can then be documented in your control logic.
>
> This method gets a bit more complicated for inner loops in a cascade
> control.
>
> Similar to Ricardo's point, most of the plants I've worked for don't give
> the full faceplate and select control to operators - we normally have loop
> specific overlays that give only the desired level of control to
> operations.
>
> Cheers,
>
> Kevin
>
> On Thu, Jul 30, 2009 at 10:45 AM, Ricardo Abech <abech@xxxxxxxxxxxx>
> wrote:
>
> > Hi Sivaram,
> >
> > You can do what you want by using a customized faceplate, where the you
> > have 2 SPT fields that toggle visibility depending on the condition
> trigger.
> >
> > When the condition is true, the SPT field has the PICK configured and
> then
> > SPT changes are allowed. If The condition is False, then is READ ONLY and
> no
> > SPT changes can be performed.
> >
> > I hope that helps.
> >
> > Best regards,
> >
> > Ricardo P. Abech
> > Chief Software Architect
> >
> > LimeWare Company, Inc.
> > [USA phone]: (408) 786 5140
> > [USA mobile]: (907) 687 8113
> > [Brazil phone]: +55 51 3372 0104 NEW!
> > [Brazil mobile]:  +55 51 8192 9723
> > [email]: abech@xxxxxxxxxxxxxxxxxxx
> > [http://]: www.limewarecompany.com
> >
> > **The contents of this email are intended for the named addressee only.
> > This transmission may contain information that is privileged,
> confidential,
> > legally privileged, and/or exempt from disclosure under applicable law.
> If
> > you are not the intended recipient, you are hereby notified that any
> > disclosure, copying, distribution, or use of the information contained
> > herein (including any reliance thereon) is STRICTLY PROHIBITED.   If you
> > received this transmission in error, please immediately contact the
> sender
> > and destroy the material in its entirety, whether in electronic or hard
> copy
> > format.**
> > ï??Please consider the environment before printing this email.
> >
> >
> >
> > -----Original Message-----
> > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Sivaram Murugan
> > Sent: Wednesday, July 29, 2009 10:14 PM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: [foxboro] Restricting the operators access to PID blocks
> >
> > Hello ,
> > We would like to restrict the operators from changing the set points of
> > some
> > PID blocks , based on some condition.
> > Say , if the condition is true , No change in setpoint allowed - but
> still
> > the operators should be able to open and see the face plate.
> > If the condition is false , the operators should be able to change the
> set
> > point.
> >
> > Any idea ,how it can be done ?
> > Thank you in advance.
> >
> >
> > -Sivaram
> >
> >
> >
> >
> > _______________________________________________________________________
> > 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:             http://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:             http://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:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.28/2259 - Release Date: 07/24/09
> 18:24:00
>
>
> DISCLAIMER : This e-mail and any files transmitted with it ("Message") is
> intended only for the use of the recipient(s) named above and may contain
> confidential information.  You are hereby notified that the taking of any
> action in reliance upon, or any review, retransmission, dissemination,
> distribution, printing or copying of this Message or any part thereof by
> anyone other than the intended recipient(s) is strictly prohibited.  If you
> have received this Message in error, you should delete this Message
> immediately and advise the sender by return e-mail. Opinions, conclusions
> and other information in this Message that do not relate to the official
> business of PETRONAS or its Group of Companies shall be understood as
> neither given nor endorsed by PETRONAS or any of the companies within the
> Group.
>
>
> _______________________________________________________________________
> 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:             http://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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: