EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: AlarmHandler as a daemon or service
From: "Ernest L. Williams Jr." <[email protected]>
To: Matthias Clausen <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Fri, 24 Mar 2006 02:45:32 -0500
On Fri, 2006-03-24 at 06:12 +0100, Matthias Clausen wrote:
> Of course we are also using the alarm handler...
> It seems that you want to achieve a reliable service which will not be 
> shut down just because the X-Terminal wend down on which you are running 
> your alh which collects all the alarms - true?
That is correct.


> So the first step was to add the Master/Slave mode to alh.
> Now you can run several instances of the alarm handler (with the same 
> configuration file). This is good - so you can allow that one of the 
> alh's will shut down. Another one will take over and write the data to disk.
Yes, here I am throwing the "-L" option for file locking.

I plan to have a "slave" for each major subsystem and one "master"
called "Global"

=================== alhLogger_PPS =========================
 
#!/bin/bash
# alhLogger script for PPS alarm logging
source /ade/epics/site-setup/epicsSetup-bash-R3.14.8.2-HOME

alh -f /ade/epics/supTop/alhTop/cfg/PPS \
    -l /ade/epics/supTop/alhTop/logs/PPS \
    -a PPS-Chmks-Alarms.alhAlarm \
    -o PPS-Chmks-Alarms.alhOpMod \
    -desc_field \
    -caputackt \
    -global \
    -m 0 \
    -L \
    -T \
    -version \
     PPS-Chmks-Alarms.alhConfig
====================================================================



> But - if all your systems reboot - or at least those running your alh's?
> 
> Ideally you would want to run alh from the command line during system 
> reboot.
> Well we've actually created an alh version from which we stripped all 
> the X-Windows stuff.
> But - in this case it's really a completely new program! alh IS X-Window 
> and highly dependent from lot's of X-Window features (like the main 
> execution loop). This version never seriously went into production.
> 
This is where we need to use "Model -- View -- Controller" (MVC) in
future designs. :)


> So here's your solution:
> Create one or more vnc sessions on your server machines and start your 
> main alh instances in Master/Slave mode on these machines during startup.
> We are starting the main alh instances at least on two machines each in 
> an individual vnc session.
Great idea.


> 
> For the future we want to change the alh message stream from opt-in (as 
> it is now) to opt-out - any alarm will be sent from the IOC to an alarm 
> queue. 
Following the idea of iocLogServer?  This is a really good idea; what is
your time frame?


> This way you will run a system process in the background which 
> makes sure that any alarm from an IOC (independent of any configuration 
> file) will be written to e.g. Oracle or a file.
> 
I saw an option in the current alarmhandler to write to ORACLE. hmmm?


By the way have you thought about having the AlarmHandler speak
messages?

We are playing with text annunciation (on miniMAC) here at the SNS.


> See attached drawing ...

Thanks for your advice and insight. :)


Thanks,
Ernest L. Williams Jr.
SNS Control System Group
ORNL



> 
> -Matthias
> 
> 
> Ernest L. Williams Jr. wrote:
> > Hi everyone,
> >
> > Two questions:
> >
> > (1) How many sites used the EPICS AlarmHandler.
> >
> > (2) Has anyone changed the EPICS AlarmHandler to run in daemon mode or
> > as a service?
> >
> > This would be a useful mode when the logging option is used.
> >
> > So, basically we would need a commandline option to enable this and give
> > us an alhLogger, ah?
> >
> >
> >
> >
> > Thanks,
> > Ernest L. Williams Jr.
> > SNS Control Systems Group
> > ORNL
> >
> >   
> 
> 


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

Navigate by Date:
Prev: Re: AlarmHandler as a daemon or service Michael Borland
Next: Re: AlarmHandler as a daemon or service Thomas Birke
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: AlarmHandler as a daemon or service Matthias Clausen
Next: Re: AlarmHandler as a daemon or service Matthias Clausen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  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 ·