EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Alarm in Epics
From: "Liyu, Andrei" <[email protected]>
To: "Kasemir, Kay" <[email protected]>, tech talk <[email protected]>
Date: Tue, 08 Nov 2005 14:26:54 -0500
Hi,

	I don't refuse from current alarm too. This way just adds
another mechanism to collect all alarms. So maybe ALARM subsystem should
have 2 ways? One way is narrow what there is now. Another one is wide
that collect all.
	I intentionally missed details of implementation. Like ALARM
thread in IOC, ALARM logger server and GUI client. I also missed data
interface between thread and logger, logger and client. I am sure that
correct implementation gives possibility to jump from to edm screen of
alarm device.

> But it just adds one more network dependency to the IOCs
Actually, IOC has one network dependency for all network connections.
But other ends of connections are question. Fortunately, control system
can have small quantity types of tools servers (Error, DB, Alarm,
Archive, File server ...) :)
Another way is new network. Control system has timing, mps. I suppose
this way will be a little expensive ... 

Thanks, Andrei.

-----Original Message-----
From: Kay-Uwe Kasemir [mailto:[email protected]] 
Sent: Thursday, November 03, 2005 1:24 PM
To: tech talk
Subject: Re: Alarm in Epics

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



Navigate by Date:
Prev: Re: Running softIoc's in the background Steven Hartman
Next: RE: linux-xscale port, SYSFS device support Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Alarm in Epics Kay-Uwe Kasemir
Next: Base 3.14.7 build error on SUSE machine alcocer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·