Re: [foxboro] External alarm horns (was: Obsolescence and unavailability of 6 X 8 annunciator keypads)
- From: Terry Doucet <doucet427@xxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 21 Mar 2011 16:55:25 -0400
Frits,
I only meant to raise the issue that the C:B.P must always be writable. And I
gave an example where it would be possible for an auto / man toggle could
prevent your alarms from being enunciated. I have seen sites where inadvertent
A/M toggle has stopped the system from working.
Terry
> From: Frits.Schouten@xxxxxxxxxxxxxxxxxx
> To: foxboro@xxxxxxxxxxxxx
> Date: Tue, 22 Mar 2011 08:09:01 +1300
> Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> unavailability of 6 X 8 annunciator keypads)
>
> Terry,
> Do you mean you want to write to OUT on the COUT block and therefore it must
> be in manual?
> Why not just writing to IN on the COUT block and having the block like all
> other blocks, just in auto?
>
> Cheers,
> Frits.
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> Behalf Of Terry Doucet
> Sent: Tuesday, 22 March 2011 4:17 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> unavailability of 6 X 8 annunciator keypads)
>
> Troy,
> The program that runs horn function does the equivalent of an omset function
> on the C:B.P listed in the horns.cfg file. So you need to ensure that the
> C:B.P remains a writable parameter. The COUT block output is not writable
> when the COUT is in automatic.
> Most times that we found the final element had stopped functioning was due to
> silly things like the block accidentally turned to auto, etc.
> Terry
>
> > From: duc.do@xxxxxxxxxxxxxx
> > To: foxboro@xxxxxxxxxxxxx
> > Date: Mon, 21 Mar 2011 09:05:35 -0400
> > Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> > unavailability of 6 X 8 annunciator keypads)
> >
> > Troy,
> >
> > Yes, of course.
> >
> > In our case, the outputs have to be logically grouped together (Output A
> > activates Light X, Output B Light Y, and Output C Light Z; but either A or
> > B or C activates the common horn) either a PLB or LOGIC or CALC/CALCA has
> > to be used. But these blocks are not necessary of you want to drive the
> > devices(s) directly from your horn.cfg output(s).
> >
> > Duc
> >
> > -----Original Message-----
> > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
> > Behalf Of Brazell, Troy L
> > Sent: Monday, March 21, 2011 8:13 AM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> > unavailability of 6 X 8 annunciator keypads)
> >
> > Duc,
> > I would assume that instead of using PLB Ladder that each Extpri could
> > be taken to a separated COUT?
> >
> > Troy Brazell
> > DCP Midstream
> > Senior Process Control Analyst
> > ISA CCST
> > Office 405-605-3877
> > Cell 405-301-2994
> > tlbrazell@xxxxxxxxxxxxxxxx
> > -----Original Message-----
> > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> > On Behalf Of duc.do@xxxxxxxxxxxxxx
> > Sent: Thursday, March 17, 2011 9:40 AM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> > unavailability of 6 X 8 annunciator keypads)
> >
> > Corey,
> >
> > We are doing this, and have been doing so for a number of years without
> > any problems.
> >
> > In /usr/fox/alarms/horn.cfg, we configure the external contacts for each
> > alarm priority like this:
> >
> > # SYS 1 2 3 4 5
> > # --- -- -- -- -- --
> > 1 LID 04WP01
> > 2 AnnunKeyboard1 0 1 1 0 0 0
> > 3 AnnunKeyboard2 0 1 1 0 0 0
> > 4 Console 0 0 0 0 0 0
> > 5 Extsys None
> > 6 Extpri1 C0401A:ALARM_CELL.BI0002
> > 7 Extpri2 C0401A:ALARM_CELL.BI0001
> > 8 Extpri3 C0401A:ALARM_CELL.BI0001
> > 9 Extpri4 C0401A:ALARM_CELL.BI0001
> > 10 Extpri5 None
> >
> > As configured, priority 1 drives a different output than priorities 2-4.
> > And we take these BI's into a PLB ladder to activate an external horn
> > and/or lights as desired.
> >
> > Duc
> >
> >
> > -----Original Message-----
> > From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Corey R Clingo
> > Sent: Thursday, March 17, 2011 10:14 AM
> > To: foxboro@xxxxxxxxxxxxx
> > Subject: Re: [foxboro] External alarm horns (was: Obsolescence and
> > unavailability of 6 X 8 annunciator keypads)
> >
> > I've seen the multiple alarm sounds that the squirrels in the annunciator
> > keyboards produce mentioned twice in this thread as justification for
> > keeping them, and it brought up another thought in my feeble brain.
> >
> > We are investigating alarm sounds as part of an overall alarm management
> > effort. Yes, the AnKbd makes multiple sounds, but they aren't all equal
> > in volume and some are indistinguishable by people with diminished hearing
> > acuity. So we are looking at driving external horns from COUTs.
> >
> > I know this can be done, but I've never done it. I haven't seen external
> > horns offered up as an alternative to the AnKbd noises in this thread. Are
> > there any issues to doing this that we should be aware of?
> >
> >
> > Thanks,
> > Corey
> >
> >
> >
> >
> >
> > _______________________________________________________________________
> > 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
>
>
>
>
> NOTICE - This message and any attached files may contain information that is
> confidential, legally privileged or proprietary. It is intended only for use
> by the intended recipient. If you are not the intended recipient or the
> person responsible for delivering the message to the intended recipient, be
> advised that you have received this message in error. Any dissemination,
> copying, use or re-transmission of this message or attachment, or the
> disclosure of any information therein, is strictly forbidden. BlueScope Steel
> Limited does not represent or guarantee that this message or attachment is
> free of errors, virus or interference.
>
> If you have received this message in error please notify the sender
> immediately and delete the message. Any views expressed in this email are not
> necessarily the views of BlueScope Steel Limited.
>
>
> _______________________________________________________________________
> 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:
