EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Alarm Limits
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 19 Mar 2009 18:18:53 +0100
On Donnerstag, 19. März 2009, Dirk Zimoch wrote:
> Changing the alarm limits on the fly might confuse some client programs.
> The records will behave correctly (i.e. change their alarm status at the
> new limits), but client programs that display alarm limits (e.g. as
> colored areas on a meter or bar) usually only read the limits when they
> connect for the first time.

Since this question/problem comes up so often, I'll take the opportunity and 
hijack this thread to ask why this hasn't been fixed years ago. According 
to the spec, CA uses only 3 of 16 available bits for the event mask. So 
let's use a few more of those bits for the most commonly needed event 
types! Even using only /one/ more bit would be extremely useful, while 
retaining complete compatibility at the protocol level:

DBE_CONTROL	An attribute of the PV has changed. This includes any
		attribute of the DBR_XXX_GR and DBR_XXX_CTRL types
		other than thos in DBR_XXX_TIME, i.e. stamp, status,
		severity, time, value.

Adding this to CA would pave the way. The next step is in the database 
layer, namely at the record support level and in base, where the new bit 
mask must be added to the right db_post_events calls. However, this can be 
done incrementally, one record at a time. Updating clients can be done, 
too, whenever someone has the time and energy available, there is no hurry 
and no need to closely synchronize developments.

If I have overlooked some serious drawback in this proposal I'm sure someone 
will point it out soon...

Cheers
Ben


Replies:
Re: Attribute events; was: Alarm Limits Andrew Johnson
References:
Alarm Limits Pierrick Hanlet
RE: Alarm Limits Mark Rivers
Re: Alarm Limits Dirk Zimoch

Navigate by Date:
Prev: RE: Prosilica cameras and bug in EPICS signal handlers Mark Rivers
Next: Re: RTEMS-mvme5500 BSP update Kate Feng
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Alarm Limits Dirk Zimoch
Next: Re: Attribute events; was: Alarm Limits Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·