Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: alarm hook
From: "Dalesio, Leo `Bob`" <dalesio@slac.stanford.edu>
To: "Matthias Clausen" <Matthias.Clausen@desy.de>, "Andrew Johnson" <anj@aps.anl.gov>
Cc: "Geoff Savage" <savage@fnal.gov>, "EPICS core-talk" <core-talk@aps.anl.gov>
Date: Tue, 20 Jun 2006 04:10:32 -0700
It would be nice if there was one place to plug in all new things that were interested in monitors.

We have one for redundancy. You would like one to handle alarms differently. I expect that one could use this to make a ca client that filters on event and triggers. It could also be used for a  logging facility. The real point of all of this, is that we need to be able to have connection-less clients. These are clients that do not want to make tcp/ip connections to each channel - but have changes pushed out to them.

I assume that intial record processing causes all fields that are changed to call dbPostEvents. Any clients listening would see each new record that just came online.

Can this hook be put into one place?
Is it a problem if the alarm hook has to check the alarm_flag to see if it is a change of alarm? It is an extra call to the alarm hook for many things that did not change alarm state - but it would be one hook into record processing that monitors changes.

Bob
 

-----Original Message-----
From: Matthias Clausen [mailto:Matthias.Clausen@desy.de] 
Sent: Monday, June 19, 2006 8:03 PM
To: Andrew Johnson
Cc: Geoff Savage; EPICS core-talk
Subject: Re: alarm hook

Hi Andrew,

I had a meeting today with Geoff, Fritz and Vladimir at Fermilab.
We discussed the implementation based on the proposed function call and agreed on an implementation which should be as generic as possible.
After Geoff's and Bernd Schoeneburg's vacation (next two weeks) we will work on an implementation.
If Geoff does not see any unforeseen problems I would like to give you a 'go' for the change in base.

Thanks for your help!
And - by the way - thanks for your clarification regarding Andrei's mail.

Matthias


Andrew Johnson wrote:
> Hi Matthias,
>
> Matthias Clausen wrote:
>>
>> in preparation for my meeting with Geoff at Fermilab I wand to send 
>> you the proposed hook into base which Bernd Schoeneburg and Bob 
>> already 'somehow' agreed on:
>>
>> Here's Berns mail to Bob:
>>
>>>
>>> recGblResetAlarms is called in monitor() which is called in the end 
>>> of record processing just before recGblFwdLink and after 
>>> recGblGetTimeStamp. After calling recGblResetAlarms in monitor() the 
>>> value changes are checked (not interesting for us).
>>> recGblResetAlarms checks for alarm changes and returns the fist 
>>> approach of the monitor mask, which is later used for postEvents.
>>> postEvents can be called from anywhere like device support, snl, 
>>> subroutines, 'homebrew' records etc. I think recGblResetAlarms is 
>>> called in the monitor function of records only. So I think it is the 
>>> perfect place. Please check it and correct me if I am wrong.
>>>
>>> The code could look like this (the end of recGblResetAlarms):
>>>
>>>     if(sevr!=nsev || stat!=nsta) {
>>>
>>> ++:    logAlarm (pdbc, sevr, stat);
>>> ++:    /* nsev and nsta are in pdbc->sevr and pdbc->stat */
>>>
>>>         ackt = pdbc->ackt; acks = pdbc->acks;
>>>         if(!ackt || nsev>=acks){
>>>             pdbc->acks=nsev;
>>>             db_post_events(pdbc,&pdbc->acks,DBE_VALUE);
>>>         }
>>>     }
>>>     return(mask);
>>> }
>>
>> My question:
>> Do you also agree with approach?
>
> I agree with the location and arguments of the call, which I believe 
> are the same as Fermilab have been using.
>
>> And - what would be implemented in base for logAlarm ()?
>> This could be an empty function which just returns - or it could be 
>> the 'real' thing where you'll have to check whether alarm logging 
>> should be used at all.
>> The empty function could be replaced/ overloaded by the 'real' 
>> function if you want to use putAlarm.
>
> I think we just need a global pointer for the routine which will be 
> called if it's not NULL, so your code just sets it to hook in.  Here's 
> my proposed patch:
>
>
> Index: recGbl.h
> ===================================================================
> RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/db/recGbl.h,v
> retrieving revision 1.9
> diff -u -b -r1.9 recGbl.h
> --- recGbl.h    12 Feb 2003 21:22:23 -0000      1.9
> +++ recGbl.h    19 Jun 2006 15:25:16 -0000
> @@ -30,13 +30,23 @@
>       : FALSE\
>  )
>
> +/* Structures needed for args */
>
> -/* Global Record Support Routines*/
>  struct link;
>  struct dbAddr;
>  struct dbr_alDouble;
>  struct dbr_ctrlDouble;
>  struct dbr_grDouble;
> +struct dbCommon;
> +
> +/* Hook Routine */
> +
> +typedef void (*RECGBL_ALARM_HOOK_ROUTINE)(struct dbCommon *prec,
> +    unsigned short sevr, unsigned short stat); extern 
> +RECGBL_ALARM_HOOK_ROUTINE recGblAlarmHook;
> +
> +/* Global Record Support Routines */
> +
>  epicsShareFunc void epicsShareAPI recGblDbaddrError(
>      long status, struct dbAddr *paddr, char *pcaller_name);  
> epicsShareFunc void epicsShareAPI recGblRecordError(
> Index: recGbl.c
> ===================================================================
> RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/db/recGbl.c,v
> retrieving revision 1.60.2.2
> diff -u -b -r1.60.2.2 recGbl.c
> --- recGbl.c    4 Nov 2004 19:21:08 -0000       1.60.2.2
> +++ recGbl.c    19 Jun 2006 15:25:16 -0000
> @@ -42,6 +42,10 @@
>  #include "recGbl.h"
>
>
> +/* Hook Routines */
> +
> +RECGBL_ALARM_HOOK_ROUTINE recGblAlarmHook = NULL;
> +
>  /* local routines */
>  static void getMaxRangeValues();
>
> @@ -239,6 +243,7 @@
>      if(stat_mask)
>          db_post_events(pdbc,&pdbc->stat,stat_mask);
>      if(sevr!=nsev || stat!=nsta) {
> +       if (recGblAlarmHook) (*recGblAlarmHook)(pdbc, sevr, stat);
>         ackt = pdbc->ackt; acks = pdbc->acks;
>         if(!ackt || nsev>=acks){
>             pdbc->acks=nsev;
>
>
> If there is general agreement between DESY and FNAL about this, I'll 
> commit the change which will then appear in R3-14-9.
>
> - Andrew


--
------------------------------------------------------------------------
Matthias Clausen                         Cryogenic Controls Group(MKS-2)
phone:  +49-40-8998-3256                Deutsches Elektronen Synchrotron
fax:    +49-40-8994-3256                                    Notkestr. 85
e-mail: Matthias.Clausen@desy.de                           22607 Hamburg
WWW-MKS2.desy.de                                                 Germany
------------------------------------------------------------------------



Replies:
Re: RE: alarm hook Andrew Johnson
References:
Re: alarm hook Matthias Clausen

Navigate by Date:
Prev: Re: alarm hook Matthias Clausen
Next: Re: RE: alarm hook Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: alarm hook Matthias Clausen
Next: Re: RE: alarm hook Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·