Re: Two questions about EPICS record support

[Andrew Johnson <anj@ast.cam.ac.uk>]

J. Frederick Bartlett (bartlett@fnal.fnal.gov) wrote:

>   The second difficulty concerns special processing when the field is
> accessed by dbGetField. Some hardware registers have destructive read
> properties; the top of a FIFO stack is one example. This is an
> instance when the hardware register should be read only when there is
> a explicit request for the information and not periodically polled,
> which seems to be the general EPICS philosophy. The problem appears to
> derive from an EPICS assumption that a dbGetField access should not
> cause either record or special processing. I presume that this
> originated in the difficulty associated with returning a value after a
> possibly asynchronous action by the device support level.

I have two suggestions:

1. Would it be possible to have several different record types, one of
which is processed only when the hardware register needs to be read? 
The record set will most likely need to be closely integrated, but this
means you can have several different kinds of processing according to
what you want to do at the time.

2. A possibly better solution might be to make the field which reads the
hardware an array with size one and whatever type you need.  When there
is a get on this field, your record's get_array_info routine is called,
you find out that this particular field is wanted and can go away and
read the hardware.  I haven't actually tried this approach, but I can't
see any reasons why it won't work.

-- Andrew
   ___
 .'   `.	Andrew Johnson, Head of Electronics
/ Royal )	Royal Greenwich Observatory
\ Greenwich	Madingley Road, Cambridge, CB3 0EZ
| Observatory	Tel: +44 1223 374823   Fax: 374700
+----------	WWW: http://www.ast.cam.ac.uk/~anj