I meant to add something about the CAG.

I don't like it very much because it's operations are broadcast based. In
one large system with a heavy number of broadcasts, we found that 75% of the
broadcasts were CAG broadcasts.

Since this customer is using the CAG to silence the horns only, I suggested
that they move to shared external horns. The WP is supposed to "optimize"
the sets to those horns and that should result in a much lower number of
broadcasts.


Regards,

Alex Johnson
The Foxboro Company
10707 Haddington
Houston, TX 77043
713.722.2859 (v)
713.722.2700 (sb)
713.932.0222 (f)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


        -----Original Message-----
        From:   Johnson,Alex [SMTP:[EMAIL PROTECTED]]
        Sent:   Tuesday, May 02, 2000 3:30 PM
        To:     Foxboro DCS Mail List
        Subject:        RE: External Horn For Process Alarms

        The CAG is good for two things:

        1)      Silencing all horns on the WPs in the CAG when the horn is silenced
        on any WP in the group.
        2)      Clearing an alarm from all WPs in the CAG when the alarm is cleared
        from any other WP in the group.

        When the horn silence button is pressed on an annunciator keyboard (it's
        sometimes (mis)labeled ACK), all horns on that WP (internal and external)
        are silenced regardless of priority.

        So, to get to your questions:

        1)      what happens [to the horns -ed] when one of the WP's [in the CAG
        -ed] is turned off?

                Basically, the answer is nothing special. Internal horns are
        silenced because they are now off too. External horns shared with another WP
        continue to be driven by that WP. External horns driven uniquely by the WP
        that is now off, remain in their last state - blaring away perhaps.


        2)      If they are all members of the same Common alarm group, will the
        backup WP take over for the downed WP and sound its alarms for it?

                The surviving WP will sound the horns that it is configured for when
        it receives an alarm. If the WPs share external horns, the surviving WP will
        of course drive them. If the WPs have a disjoint set of horns, the "dead"
        WPs horns just hang there.


                3) Or do I lose 5 of my alarm horns?
                Well, not literally, but they will no longer be driven assuming that
        on the "dead" WP works with them.


        3)      [I -ed] want to have 64 different external horns, is it possible to
        do this through the horn.cfg file [? -ed]

                No, the system supports only six external horns (5 for process
        alarms and 1 for system alarms).


        4)      or do I have to come up with something else?

        You need something else.


        Can you explain what you want to accomplish? Maybe there is another route.



        Regards,

        Alex Johnson
        The Foxboro Company
        10707 Haddington
        Houston, TX 77043
        713.722.2859 (v)
        713.722.2700 (sb)
        713.932.0222 (f)
        [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 


                -----Original Message-----
                From:   [EMAIL PROTECTED]
        [SMTP:[EMAIL PROTECTED]]
                Sent:   Tuesday, May 02, 2000 2:55 PM
                To:     [EMAIL PROTECTED]
                Subject:        RE: External Horn For Process Alarms

                I have a question about the horn.cfg file when used to sound
an
        external
                horn. I am going to use an example to pose my question.

                If I have 3 WPs, each specifying different external horns to
sound
        on
                Priority 1 -5 alarms (so I have a total of 15 digital
outputs), what
        happens
                when one of the WP's is turned off? If they are all members
of the
        same
                Common alarm group, will the backup WP take over for the
downed WP
        and sound
                its alarms for it? Or do I lose 5 of my alarm horns?

                Another related question:
                If I have 3 WPs, but want to have 64 different external
horns, is it
                possible to do this through the horn.cfg file or do I have
to come
        up with
                something else?

                BTW, I am not the nutjob who thinks having 60 different
external
        horns in
                one building is a good idea. I unfortunately, was asked to
try to
        implement
                it.

                Thanks-

                Marci Sewell
                Process Automation and Control
                115 Bldg, Mail 032
                ph: (517)496-5071   page: (517)926-1487
                email: [EMAIL PROTECTED]


                -----Original Message-----
                From: Duc M Do [mailto:[EMAIL PROTECTED]]
                Sent: Tuesday, May 02, 2000 3:06 PM
                To: Foxboro DCS Mail List; Foxboro DCS Mail List
                Subject: RE: Process Alarms


                At 02:48 PM 5/2/00 -0400, Johnson,Alex wrote:

                >2)     Use a PC as your "alarm printer" and one of several
3rd
        party
                >packages to capture the alarms.

                We do something similar. We feed all the process alarms (and
system
                alarms, too, for that matter) to a VAX. Our friendly VAX
guru sets
        up
                automatic capturing and parsing of the alarms into process
area
                specific files (text files, one file per day) and put them
on a web
                server. The process people can grab them at their leisure
and do
                whatever with them. These files are kept on the web server
for 3
        months
                and then archived to CD-ROM for who knows how long.

                Duc M. Do
                Dow Corning Corp.
                Carrollton Plant
                Carrollton, KY, US


                

-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]

Reply via email to