Experimental Physics and
Industrial Control System

[email protected] (William Lupton) · Thu, 1 Sep 94 10:03:25 HST

Dear all,

  I am preparing for a workshop here next week where I will be doing my best to
explain what EPICS is and why we want to use it. I have installed R3.11.4 and
have it working but in the course of setting it up and doing some simple things,
several questions have arisen. Please bear with me if the answers are very
obvious or well-documented in some place that I haven't looked!

  Thanks,

  William Lupton

--------------------------------------------------------------------------------

1. User-defined record field datatypes
--------------------------------------

The CA manual states that the "chtype" parameter to ca_put() and ca_get() must
be one of the DBR_xxxx values from db_access.h. What does one do when one has
defined a record one of whose fields is itself record-structured. Does one have
to make a local version of db_access.h? Or does one simply not do this sort of
thing? A DBR_OPAQUE value (or some such; meaning that no conversion is to be
attempted) would seem like a useful concept?

2. Documentation
----------------

I have pulled several documents from the ANL WWW server. At the course that Deb
and Bill gave here in Hawaii we had some chapters from another manual that was
(I think) being put together at LANL. For example, chapter 2 was called "Anatomy
of a record support file". Is this manual available ... or is everything going
to come together with R3.12?

3. CA synchronous groups
------------------------

Often the state of some system will be described by several PVs, all of which
must have self-consistent values. A simple example from our world would be:

a) for writing PVs, the desired telescope position might be described by a
   tel:targra (Target Right Ascension) and tel:targdec (Target Declination)
   PV pair. Setting these PVs should not initiate a telescope move since the
   move should not start until all relevant parameters have been set; this
   should be initiated by setting another PV, tel:movetel say.

b) for reading PVs, the current telescope position might be defined by tel:az
   (Azimuth) and tel:el (Elevation). tel:utc (Universal Coordinated Time) might
   contain the exact time corresponding to this position.

In case (a), one approach would be in fact to define a new record type called
something like "targdef", which contains all the 10 or so parameters which
completely define a target position. Now a write to a "targdef" record could
both set the parameters and initiate the move. However, I feel that this is not
within the spirit of EPICS: everything should be visible.

Another approach to (a) is perhaps to use a synchronous group. Is this one of
things they are for? Is a synchronous group primarily a client-side concept to
ease programming of the "do this, this and this and wait for them all to comp-
lete" paradigm or does it spill into the server and guarantee that they are
performed strictly in order, INITIATED strictly in order, or ...?

In case (b), one approach is to use the same "targdef" record as above, in which
case the data are guaranteed self-consistent. I don't like this, for the reasons
stated above (counter to perceived philosophy), and because I can forsee a lot
of record types with a lot of information common to several.

Another approach to (b) is to use the time-stamp information (indeed for our
application I imagine that we will use UTC as the reference for our time-
stamps). That way you can tell which data correspond to a given time, but at
the expense of some client-side effort (matching time-stamps). Presumably the
archiver contains such code ... or does CA itself help here at all?

Does the synchronous group help here. If I do a synchronous group of gets, am
I guaranteed that all the returned data correspond to the same time-stamp value?
Across IOCs too? I feel that the answer must be "yes"!

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System