Re: Attribute events; was: Alarm Limits

[Andrew Johnson <anj@aps.anl.gov>]

Hi Ben,

On Thursday 19 March 2009 12:18:53 Benjamin Franksen wrote:
>
> 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.

Probably because the information about which fields are used for attributes is 
currently *only* known to the code in the record type's get_* routines.  
There's nothing in the IOC or in any DBD file that says that the EGU field is 
used for the engineering units string, or which fields the HIHI..LOLO alarm 
limits apply to for example.  I would love to fix this, but it does require 
changes to the record support interface to do so automatically.

> 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.

Can I propose the name DBE_ATTRIBUTE instead, although I suspect Jeff would 
prefer DBE_PROPERTY (which admittedly is shorter).

> Adding this to CA would pave the way.

I just tried this and discovered that CA already transports and handles the 
bottom 8 bits of the event mask in R3.14.10+, so with a modified mbbi record 
and a modified caMonitor client I am able to change one of the mbbi *ST 
fields and see the ENUM strings change in the monitor callback at the client.  
The only thing we would need to change to add this is the caeventmask.h file.

> 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.

Actually we would need to add additional calls to db_post_events(), none of 
the existing ones will do the right thing.  When we write a new string to 
EGU, we would have to call
	db_post_events(prec, &prec->val, DBE_ATTRIBUTE);
since the VAL field is the one that has the attribute.  Strictly speaking 
right now, most record types return EGU as the units string for every field, 
so to match that we'd have to post a DBE_ATTRIBUTE update to all fields 
whenever the EGU field is modified, but IMHO that's actually a mistake and we 
should only be returning EGU for a limited subset of the fields.

There's nothing stopping a record type from doing the necessary work itself 
right now, but it would be rather tedious to code.  It would have to mark 
every attribute field as special, then have its special() routine look at the 
field being written to and call db_post_events() for every other field for 
which that particular attribute can be supplied (the record has no way to 
know what monitors are in place, so it has to assume every field is monitored 
with every DBR_ type and call db_post_events() for all of them).

It would be nice to not have to add special() routines to every record type 
just for this though, I'd much prefer to have stuff in the record type's DBD 
description for each attribute field and code to dbAccess.c to call 
db_post_events() for all the relevent fields whenever an attribute field gets 
written to.  We might even be able to automate the writing of the various 
get_ routines in the RSET if we do that right.

> 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...

Just the question about how we get db_post_events() called for the right 
fields.

The mbb[io] records already mark their *ST and *VL fields as special in order 
to recalculate the SDEF field, so for my experiment above I was able to 
easily hook into this code and post a DBE_ATTRIBUTE event on the VAL field at 
the same time.  Unfortunately MEDM doesn't monitor ENUM fields using a 
DBR_CTRL_ENUM type; it only requests the graphical data whenever the channel 
connects, so while it is encouraging, my experiment is a long way from being 
useful.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte