As far as reducing alarm traffic goes: It seems to me that we may have a limited way of removing alarm reports to workstations while still recording the events. This is a way I have not tried myself, but Rich Bakke wrote about it last summer. Instead of moving alarms from group to group, you remove (or add) devices to the list receiving the alarms. http://www.freelists.org/archives/foxboro/06-2005/msg00149.html Granted, there are only 5 configurable alarm groups (GR4-GR8) per CP, but there are 16 devices (e.g.--14 workstations, a historian, and a printer) that may be included in or excluded from each group with a script that changes the hex value at :STATION.GRx. If you have less than 5 major processes per CP and less than 15 workstations for each CP to report to, it looks like it could work for you. For those of us that are still using pre-CP60 processors it looks like it can be rather useful. Kevin FitzGerrell suggests changing alarm priority--instead of alarm group--to reduce alarm traffic. Alarm Manager filters could selectively not report alarms of lower priorities. =20 http://www.freelists.org/archives/foxboro/06-2005/msg00114.html This is another way that alarms would be recorded by the system historian without getting in the way of busy operators. Chuck Jones Automation Technologist Tate & Lyle -- Lafayette Plant Office 765.477.5324 | Cell 765.586.5290 -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Armour, Alan Sent: Tuesday, December 19, 2006 5:15 PM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] alarm inhibiting vs. alarm disabling - process summary reporter Good one Michael, The annoying thing that I find is that as soon as you use INHIB or INHALM to configure logically driven alarm suppresion the block automatically appears as "inhibited" on the inhibited alarms report. What I have done is to use INHALM for logically supressing alarms, so that the operators can still overide the logical inhibits by using INHIB. I have walked away from the Foxboro inhibited alarms reports and used a script which looks for INHIB =3D3D1, and combined with another script which extracts alarm inhibiting actions from the operator action logs. This gives me a time stamp of when an alarm was operator inhibited. The other annoying thing is as part of my overall alarm philosopy I want to reduce alarm traffic to the operator during abnormal situations. There is important data which can be used in post event analysis which would be lost if a blanket inhibit of non immediately important alarms are suppressed, so I have a desire to divert many alarms to an "historian only" alarm group. This would be easy to do if the alarm group paramaters on any block which produces alarms was connectable, but....(hope Alex is looking!). At the moment what I am doing is run two blocks, one for the operators, and one for historian, and use block names which are as close as possible to each other. regards, Alan =3D20 -----Original Message----- From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Kessler Sent: Wednesday, 20 December 2006 12:22 AM To: foxboro@xxxxxxxxxxxxx Subject: Re: [foxboro] alarm inhibiting vs. alarm disabling - process summary reporter > 2. You can send a HEX pattern to the AIN's INHALM parameter. Again=3D20 > this =3D3D parameter is connectable and settable, so any display or=3D20=20 > program can set =3D3D the hex pattern if there is no connection. For=3D20=20 > example a pattern 0x0003 =3D3D will inhibit HIGH and LOW alarms. > You can also toggle the HEX bits individually from block detail in Select. For example, to inhibit only the HI alarm, 1. Call up block detail for the AIN. 2. Click Alarms 3. From Select pick the HIABS parameter. 4. Click Toggle A black INHIBITED should appear indicating that the HEX bit to disable HIABS has been set. mk ***************************************************************************= ************************** This email and any files transmitted with it are confidential and intended = solely for the=20 use of the individual or entity to whom they are addressed. If you are not = the intended=20 recipient or the person responsible for delivering the email to the intende= d recipient, be=20 advised that you have received this email in error that any use, disseminat= ion,=20 forwarding, printing, or copying of this email is strictly prohibited. If = you have received=20 this email in error please notify the sender immediately. Please note that = we reserve=20 the right to monitor and read any emails sent and received by the Company i= n=20 accordance with and to the extent permitted by applicable legal rules. ***************************************************************************= ************************** _______________________________________________________________________ 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