EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: a technicality ?
From: Kay-Uwe Kasemir <[email protected]>
To: Heinrich du Toit <[email protected]>
Cc: TechTalk EPICS <[email protected]>
Date: Tue, 14 Aug 2007 09:05:03 -0400

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
References:
a technicality ? Heinrich du Toit

Navigate by Date:
Prev: RE: dm2k not compiling :( Heinrich du Toit
Next: RE: dm2k not compiling :( guobao shen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: a technicality ? Benjamin Franksen
Next: bug fixes for R3.14.8.2 Geoff Savage
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·