Re: a technicality ?

[Kay-Uwe Kasemir <kasemirk@ornl.gov>]

On Aug 14, 2007, at 06:59 , Heinrich du Toit wrote:

> Hi
>
> I was wondering if somebody could clear this up for me:
>
> What is the relationship between:
> a record
> a pv (process variable)
> and a record field

Hi:

From past EPICS training sessions it's become obvious to me
that this is one of the most confusing things about EPICS.

The IOC database has Records.
A Record has Fields:
The analog input record "fred" has fields
VAL, EGU, TIME, HOPR, LOPR, STAT, SEVR, ...
You use the database file or later at runtime
the dbgf and dbpf commands to deal with
fields of a record.

Over the network protocol, ChannelAccess,
you access Channels.
A Channel has Properties:
A Channel "fred" has properties value, time stamp,
units, upper display limit, status, severity, ...
You use the DBR_... request types to read/write
the properties of a channel
(called "database request types" DBR_...,
 should be "channel" or "property" request types)

How do Records map to Channels,
how do Fields of a Record
map to the Properties of a Channel?
To really know, you have to use the force
and read the source. The result makes sense
in the few but most common cases.
It doesn't make sense in most of the other
possible cases.

The one example that makes perfect sense:
You have a channel "fred" for an AI record "fred",
and ask for a DBR_CTRL_DOUBLE.
Your channel will provide the following properties
in a dbr_ctrl_double structure, mapped to the
following fields of the record:
value = VAL
status = STAT
severity = SEVR
precision = PREC
units = EGU
upper_disp_limit = HOPR
lower_disp_limit = LOPR
upper_alarm_limit = HIHI
...
You can also ask for a DBR_TIME_DOUBLE and get the
value = VAL
stamp = TIME
...
The time stamp is of course the time of the last value update,
so it's the time stamp that belongs to the value.
This case makes perfect sense.

The next good example is a channel "fred.SCAN",
which is of type ENUM and you can get the DBR_CTRL_ENUM properties:
value = SCAN
strs = { "Passive", "Event", ..., ".1 second" }
Good, that's the current value as well as coresponding
enumeration strings.
But there's also
status = STAT
severity = SEVR
Those are status & severity of the VAL field.
A "NO_ALARM"/"NO_ALARM" or "READ"/"INVALID" in there doesn't say  
anything
about the SCAN field.

Now attach a channel to "fred.HOPR" and read the DBR_TIME_DOUBLE:
value = HOPR
stamp = TIME
You get a time stamp that has nothing to do with the value.
It's not the time when HOPR was last updated.

Attach a channel to "fred.HOPR" and read a DBR_CTRL_DOUBLE:
value = HOPR
units = EGU
status = STAT
severity = SEVR
lower_ctrl_limit=-32768
upper_ctrl_limit=32767
value and units are OK.
But status & severity again apply to the VAL of the record, not the  
HOPR field.
The control limits are simply the range of the 16 bit number that's
in the PREC field. Is a negative PREC of any use?

So if your channel name is simply a record name,
the mapping of record fields to channel properties makes sense.
In other cases, you have to look at the source code of the record
to figure out what you'll get, and in many cases it's questionable.
You also have to understand that ChannelAccess cannot introspect
the record (iterate over the fields). There's no DBR_ALL_FIELDS,
only a fixed set of DBR_... requests with a hardcoded mapping to
fields inside each record's code.

-Kay