Experimental Physics and
Industrial Control System

"Dalesio, Leo" <[email protected]> · Sat, 31 Jan 2009 09:05:34 -0500

A Proposal (half-baked):

Modify channel access and db scanning to support the following:
1) Add a flag to the .dbd for each field that indicates if the regular record parameters for display and control pertain.
2) Add defaults by record type for display and control parameters for fields such as doubles, ints, strings.
3) Use these new configurations to determine how to construct display and control structures.
4) keep a flag for each field that denotes it has been changed by a caput since the last process
5) during process, flag each field that has been modified as part of record processing.
6) post monitors at the same place in the record processing - but look at the flags to know what has changed. (I think that this is what is going on for redundancy already).

Doesn't this fix the previously mentioned time stamp issue?
It is also intended to address display and control data for non-value related fields in a record.

I did not include alarm and time stamp as I am sure that others have used the fact that you get the record's status when you connect to fields. Any arguments against?

Bob

-----Original Message-----
From: [email protected] on behalf of Andrew Johnson
Sent: Fri 1/30/2009 6:30 PM
To: Dirk Zimoch
Cc: EPICS tech-talk
Subject: Re: wrong timestamps in monitors

On Friday 30 January 2009 02:30:05 Dirk Zimoch wrote:
> Andrew Johnson wrote:
> ...
>
> > I believe it is well-recognized that the status and severity of a PV
> > reflect the state of the record containing that PV rather than the state
> > of PV value itself.
>
> This is not fully true.
> * The "pseudo fields" RTYP and VERS report random (?) status and severity.

That's a bug that I wasn't aware of which I'll try to fix for R3.14.11.  It 
might be tricky to return the record's status and severity for these (I 
haven't found the relevent code yet), but the results ought not to be random 
in any case.

> * When using monitors on fields, lets say EGU, status and severity are not
> updated when they change and thus do not reflect the state of the PV.

We only post monitors when the named value changes, not as a result of any 
attributes changing.  I think it would be possible to create a record type 
that did that, but I'm not sure I'd like the result:

 * It would have calls to db_post_events() for every field in the record that 
could be monitored through CA.
 * Every writable field that is used as an attribute would have to be marked 
special, so it can catch external puts to that field.
 * An appropriate set of db_post_events() calls would have to be made whenever 
one of the record's attribute fields was changed.

The record doesn't know whether any of its fields are being monitored at all, 
so it has to post monitor events for every observable field and let the CA 
server ignore the ones that aren't currently connected to any clients.

I'm not sure how useful the result would be in practice; I'd be interested to 
hear if anybody actually tries it.

> BTW: Many records have a general problem reporting correct attributes to
> any field but VAL. For example, reporting the EGU field as the units of the
> PREC field is obvious nonsense.

I agree this is a long-standing issue in most record types which could be 
fixed.  For your specific example most records currently return the EGU field 
contents for any request to their get_units() routine, which is obviously 
wrong.  This can be fixed pretty easily, it just requires modification of one 
record support routine to only return the EGU contents for those fields that 
actually contain values in that unit.

I'll see what I can do.  I'm going to assume that returning an empty string is 
better than the wrong string, but it's not obvious what to do for the A-L 
fields of the CALC or SUB records for example - there are probably databases 
in use right now that rely on the current behavior to supply EGU as the unit 
string for one or more of these fields, so I will avoid breaking them.

The PREC field value is currently returned as an attribute of only the VAL 
field for most analog record types; I think it should be used for the alarm 
and display limit fields too.

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System