Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: AlarmHandler as a daemon or service
From: Maren Purves <m.purves@jach.hawaii.edu>
To: Matthias Clausen <Matthias.Clausen@desy.de>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Wed, 05 Apr 2006 09:54:35 -1000
Matthias Clausen wrote:
Back from my trip to eclipsecon and my visit at SLAC - thanks to the organizers of the little eclispe/XAL workshop I want to summarize where we are with the alarm message approach.




The messages will get written to the Oracle database by a message client receiving the messages from the alarm message queue.
- Point (4) on the to do list
(This will be implemented in due time)

not sure we need or want an Oracle database here (I very much agree with Andrei on this one). If this is optional fine, but I wouldn't like it to be mandatory.

Displaying messages from the (Oracle) archive
Implemented in eclipse-BIRT - is one of the results of the eclipsecon!

Displaying online messages:
Open questions:
- What shall the hierarchy look like?
- How to configure the hierarchy? (using the existing alhConfig files?
- How to implement acknowledge alarms?

and please don't have acknowledging mandatory ... (in most cases we don't care whether there was an alarm some time in the past. If the instrument isn't warming up nobody has to go and check the compressor/chiller even if the temperature was above alarm limit at some point)

- What kind of filters are currently used/ necessary - or missing?
- Point (5) on the to do list

Alarm actions:
What kind of actions are necessary?
- Sending mail
- Sending SMS messages
- Send speech messages
- Changing values on the same - or other - records
- Point (6) on the to do list

I always liked the "you can make it do whatever you can write a command for" feature, and I don't think I'd like that restricted. It's easy enough to make it execute a shell script that does whatver the user requires, no?

Aloha,

Maren
References:
AlarmHandler as a daemon or service Ernest L. Williams Jr.
Re: AlarmHandler as a daemon or service Matthias Clausen
Re: AlarmHandler as a daemon or service Ernest L. Williams Jr.
Re: AlarmHandler as a daemon or service Matthias Clausen

Navigate by Date:
Prev: Re: Ethernet/IP Device Support and CompactLogix Kay-Uwe Kasemir
Next: RE: AlarmHandler as a daemon or service Liyu, Andrei
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: AlarmHandler as a daemon or service Andrew Johnson
Next: Re: AlarmHandler as a daemon or service Michael Borland
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·