Experimental Physics and Industrial Control System
On Nov 3, 2005, at 12:29 , Liyu, Andrei wrote:
Then checkAlarms() function calls recGblSetSevr( precord, ...)
function.
It is macros. So we can EASY change macros and new function will write
message to errlog server (I don't know another suitable central engine
in Epics).
After that we will have all alarms in one place. I believe that
advantages are clear.
Hi:
As far as I understand, the current idea is
- each record _determines_ its alarm state,
reflects the result in STAT/SEVR field.
A CA client can ask for data with alarm info.
- the alh alarm handler _monitors_ alarms,
_logs_ them, _displays_ them to users,
allows users to _acknowledge_ alarms, ...
- some part of the acknowledgement is actually
also handled by special fields in the records
which remember the highest no-ack'ed alarm.
There are alternate ideas. The D0 significant event server is one.
I agree that combining monitoring, logging, displaying, ack'ing
all in one GUI tool is too much.
I'm not sure about your idea of _adding_ the logging to the IOC.
Sure, it's a comparably easy thing to add a message log 'write'
to recGblSetSevr.
But it just adds one more network dependency to the IOCs,
and then how do you display the message log,
how do you acknowledge alarms?
If you're serious about re-thinking the alarm handling,
I'd rather remove the special alarm ack fields from the IOCs,
since non-database-CA-servers sometimes don't implement these
anyway, and also split the alh task, resulting in this separation:
- records/IOCs/CA servers determine alarms
- one or more alarm monitor daemons monitor values & alarms,
log them
(maybe as last time & value before alarm, time & value with alarm),
remember the highest non-acked alarm,
provide network API for ack'ing alarms,
where the acknowledgement (w/ user, maybe comment) gets logged.
- GUI clients to the alarm daemon can display the current alarms.
They also offer the option of acknowledging alarms,
though that's probably limited to certain users.
Of course these are just my ideas, I've probably missed many details,
but I think it's clear that just adding a log message doesn't
really improve much.
-Kay
- References:
- Alarm in Epics Liyu, Andrei
- Navigate by Date:
- Prev:
Alarm in Epics Liyu, Andrei
- Next:
Base 3.14.7 build error on SUSE machine alcocer
- 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
2025
- Navigate by Thread:
- Prev:
Alarm in Epics Liyu, Andrei
- Next:
RE: Alarm in Epics Liyu, Andrei
- 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
2025