Experimental Physics and Industrial Control System
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:[email protected]]
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: [email protected] 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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: alarm hook Matthias Clausen
- Next:
Re: RE: alarm hook Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024