Re: [foxboro] Locking Individual Alarms from Detail Display Inhibiting

I have used the same method as George's to prevent HOLD option in the detail 
display of PIDA block from being used by unathourized persons.

Rgds,
Ali Ahmed Zahidi
Pakistan Refinery Ltd.
Karachi, Pakistan.

----- Original Message ----- 
From: "Kurt J Russell" <RUSSELL_KURT_J@xxxxxxxxx>
To: "freelist" <foxboro@xxxxxxxxxxxxx>
Sent: Monday, June 12, 2006 9:12 PM
Subject: Re: [foxboro] Locking Individual Alarms from Detail Display 
Inhibiting


> George,
>    One idea that I implemented at a couple of sites overseas when I was
> with Foxboro was to modify the detail display alarm overlay files.  These
> are the ones listed under /usr/fox/dd/[blocktype].  The alarm overlay for
> each blocktype is the one ending in "_09".  I wound up modifying the
> overlays by placing two rectangles over all the fields that need to be
> protected.  Each box had a visibility based upon the priority of the
> alarm.  So priority 1 and 2 alarms were able to be given one access class
> protection, priority 3 and 4 alarms were given another, and priority 5
> alarms (which was the original box field on the overlay) a third access
> class.
>   Granted this approach would be a global one on a workstation basis,
> since you are modifying the detail display overlay template.  There are
> many ways to utilize this approach to protect alarms and settings from
> operators/engineering/etc.
>   Hope that this helps.
> Kurt Russell
>
> Senior Project Engineer
> Forteo Process Automation (KYJ03)
> Phone: 317-277-1008
> Fax: 317-655-6536
> Mobile: 317-997-5715
> krussell@xxxxxxxxx
> ------------------------------------------------------------------------------
> KY/358/01, Drop Code 3418
> Technology Center North
> United States of America
> www.lilly.com
> ----- Forwarded by Kurt J Russell/AM/LLY on 06/12/2006 12:04 PM -----
>
> George Bocancea <GBocance@xxxxxxxxxx>
> Sent by: foxboro-bounce@xxxxxxxxxxxxx
> 06/12/2006 12:00 PM
> Please respond to
> foxboro@xxxxxxxxxxxxx
>
>
> To
> freelist <foxboro@xxxxxxxxxxxxx>
> cc
>
> Subject
> [foxboro] Locking Individual Alarms from Detail Display Inhibiting
>
>
>
>
>
>
> Hi all,
>
> Can anybody help with this:
> What can we do If we don't want people to be able to inhibit one
> particular block's individual alarm?
>
> We know how to lock ALL alarms from inhibiting (toggling the INHIB_ALL
> option on Detail Display) by changing the following parameter into ICC:
>
> INHIB = CMP:BLK.INHIB.0
> (The same way we lock alarm limits of this CMP:BLK from changing, i.e.
> HHALIM= CMP:BLK.HHALIM.26)
>
> This helps but we do not want to take away the possibility of
> inhibiting SOME alarms;
> People should be able toggle fields like HHABS, HIABS which inhibit the
> respective alarms, one at the time.
> I believe the ICC parameter we should be working on is INHALM and it is
> 0x0 by default.
>
> For instance, we would like to lock from inhibiting HHABS only, but
> keep HIABS unlocked, available to operators to inhibit when it becomes a
> nuisance.
>
> Please advise,
>
>
>
>                            IMPORTANT NOTICE !
> This E-Mail transmission and any accompanying attachments may contain
> confidential information intended only for the use of the individual or
> entity named above. Any dissemination, distribution, copying or action
> taken
> in reliance on the contents of this E-Mail by anyone other than the
> intended
> recipient is strictly prohibited and is not intended to, in anyway, waive
> privilege or confidentiality. If you have received this E-Mail in error
> please
> immediately delete it and notify sender at the above E-Mail address.
>
> Agrium uses state of the art anti-virus technology on all incoming and
> outgoing E-Mail. We encourage and promote the use of safe E-Mail
> management
> practices and recommend you check this, and all other E-Mail and
> attachments
> you receive for the presence of viruses. The sender and Agrium accept no
> liability
> for any damage caused by a virus or otherwise by the transmittal of this
> E-Mail.
>                        IMPORTANT NOTICE
>
>
>
>
>
> _______________________________________________________________________
> 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

Other related posts: