Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Thu, 1 Sep 94 15:17:04 MDT

> 
> --------------------------------------------------------------------------------
> 
> 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? 

Mechanisms for passing application dependent data types through CA are under serious 
consideration for EPICS V4. Under V3 EPICS, adding a new data type would 
require code changes to the core components of EPICS.

> A DBR_OPAQUE value (or some such; meaning that no conversion is to be
> attempted) would seem like a useful concept?
> 

My preference (for V4) is to create a data type description compiler.

> 
> 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.
> 

This mechanism is often employed by EPICS applications.

> 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.

Within EPICS you can fetch all process variables together with the time that they
were last processed (read in from the hardware).

> 
> 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? 

Sync groups provide blocking until a specified group of requests
complete. Sync groups can be used to implement (a) by guaranteeing
that all parameters have been set (one sync group) prior to
setting the parameter that initiates a move.

> 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 

yes. Note that sync groups show up in 3.12 EPICS.

> or does it spill into the server and guarantee that they are
> performed strictly in order, INITIATED strictly in order, or ...?
> 

All CA operations are completed in the order that they are initiated
if all operations are (1) performed by the same CA server and (2)
are not communicating with asynchronous hardware (GPIB etc).

If you force synchronous operation through the CA interface then
all operations will of course be performed in the order that
you initiate them (because you wait for a set of operations to
complete before starting another one).

> 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.
> 

Some discussion is ongoing about the addition of multiparameter puts
and/or client side mutual exclusion (record processing) locking to CA V4.

Currently it is reasonable to write all of the parameters 
into separate records. Once you have completed all of
the parameter writes then a flag could be poked that initiates
the move.

> 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?

Currently aligning incoming data by time stamp is performed by client side 
libraries (above the CA client library). 

> 
> 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"!
> 

The answer is no. Sorry, sync groups only block the client process until
all requested operations complete. Adding an option for time stamp 
correlation to this interface is an interesting idea however.

Jeff

______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM USA 87545	FAX		505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System