Experimental Physics and
Industrial Control System

[email protected] (Tim Mooney) · Thu, 17 Sep 1998 16:08:17 -0500

re...

>   First, there are several fields in a record which reference arrays
> (as in the waveform record) for which we need the actions associated
> with both the SPC_DBADDR (because the fields are arrays) and SPC_MOD
> (because a "put" to the field must result in a transfer to the
> hardware device). Is it possible to specify both actions in the record
> "dbd" file? If not, how can the equivalent effect be realized?

Can't do this because special is not a bitmap.  You could put the code
you'd like to have in special() in the record-support routine
put_array_info().  To write the array to hardware on a dbPutField, I
would make the field "process-passive", jot a note to myself while in
put_array_info() about which field was written to, and do the actual
writing in process(). 

I haven't actually *tried* this, but I think it will work.

>   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.
>
>   One solution is to introduce a dummy field in the record for which a
> dbPutField would cause the hardware register to be read. This would be
> followed by a dbGetField to another field which contains the value
> which was just read. I find this option distasteful because it
> requires two separate transactions over the network to accomplish a
> simple read of a register; and, since the two actions are not
> "atomic", there is the usual problem of two users interleaving their
> caPut/caGet sequences with the subsequent loss of one reading.
> 
>   Any suggestions or clarifications on these issues would be greatly
> appreciated.

It would be nice in some ways to have Get operations cause actual reads,
and database Gets can do this, of course.
For arrays, you could kludge this in get_array_info(), but I'd worry
about side effects.  (Ok, *I* wouldn't worry; I just wouldn't do it.)
The next best thing might be to put a monitor on the field you want to
read, and write to some other field that causes processing, which results
in the field you want to read getting posted.  That would be atomic, and
it would not require two transactions.

Tim Mooney

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System