Re: [foxboro] Locking Individual Alarms from Detail Display Inhib iting

Hi all,
Kurt wrote:
> One idea that [...] was to modify the detail display alarm overlay files.

I'd recommend not to modify these as with new I/A releases these may be
changed and either your customization is gone afterwards or (if you took
care) you have to re-customize the new overlays to fit your needs.

It's a better approach to create a new set of detail alarm inhibit overlys
in a custom directory (e.g. in /opt/customer/ovr), one per alarming block
type, where the current status of INHALM is displayed and can be set bitwise
by the operator according to his individual rights. It could also be
possible to associate an additional MCIN block beside each alarm block and
use it's 32 bits for allowing and forbidding of each individual single alarm
bit on the INHALM array for operation, in case this is needed.

It's always better do create something customized rather than changing the
foxboro standard files.

Best regards -

Marcel Sieling
Senior Application Consultant

Invensys Systems GmbH
Emanuel-Leutze-Str. 11
40547 Duesseldorf
Germany
T: +49-211-5966-302
F: +49-163-99-5966302 
M: +49-163-5966302
Skype:  marcel.sieling
mailto:marcel.sieling@xxxxxxxxxxxxxxxx
http://www.foxboro-deutschland.de


> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx 
> [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Kurt J Russell
> Sent: Monday, June 12, 2006 6:12 PM
> To: freelist
> 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: