We are getting intermitent INVALID alarms from a rather loaded IOC
(order 1000 records.) the file ALH-default.alhAlarm is filled with
things like:
Fri Sep 19 13:13:19 1997 : B_hv_TAC_2_L_TOP NO_ALARM NO_ALARM NO_ALARM NO_ALARM 0
Fri Sep 19 13:13:19 1997 : B_hv_TAC_3_R_BOT NO_ALARM NO_ALARM NO_ALARM NO_ALARM 0
Fri Sep 19 13:13:19 1997 : B_hv_TAC_4_L_BOT NO_ALARM NO_ALARM NO_ALARM NO_ALARM 0
1) The alarms come and go on about a 30 second time scale. In other
words, they clear themselves and reappear again.
2) The alarms are always for many, many records, sometimes all of
them.
3) It's only this one IOC, even though we are running the same
application on another IOC connected to the same subnet, that one with
not as many channels.
4) The alarm handler displays: <NO_ALARM,NO_ALARM><TIMEOUT,INVALID>
for all of the alarms.
5) I infer from the output above that the records themselves are not
in an invalid state.
Seems like the alarm handler is a bit too impatient about deciding if
it has a connection to the channel. Does that sound right? Is there a
way to configure the alarm handler to avoid this?
--
Mark M. Ito, Thomas Jefferson National Accelerator Facility
12000 Jefferson Ave., Mail Stop 12H, Newport News, VA 23606
Email: [email protected], Office: (757)269-5295, Pager: (757)680-7175
- Navigate by Date:
- Prev:
Re: Capfast symbols for transform or ANL motor record? Len Lawrence
- Next:
XYCOM-244 Andy Foster
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS support of RGA's Daniel S. Lowe
- Next:
alarm handler problem Janet B. Anderson
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|