Experimental Physics and
Industrial Control System

"J. Frederick Bartlett ([email protected])" <[email protected]> · Thu, 17 Sep 1998 13:21:33 CDT

  We (the D0 experiment at Fermilab) are in the process of building
EPICS record support for several complex devices and have encountered
a few difficulties whose solutions does not seem to be covered in the
Application Developer's Guide. There are two which are of immediate
interest.

  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?

  A possible alternative appears to be setting the "process passive"
attribute for the field and then, during record processing, using the
value in the PUTF field, which indicates when a dbPutField caused
record processing, and the dbGetFieldIndex function to determine which
field is associated with the action. This, however, feels to me like a
"hack" to handle a "special" action in record processing.

  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.

						Fritz Bartlett

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System