EPICS: Extensible Record and Device Support*
M.R. Kraimer and L.R. Dalesio
Argonne National Laboratory and Los Alamos National Laboratory
prompt("Input Specification")
promptgroup(GUI_INPUTS)
interest(1)Abstract
An important feature of an Experimental Physics andIndustrial Control System (EPICS)-based input/output
controller (IOC) is extensible record and device support.
This feature allows each site to add custom record types
and device support. This paper discusses the current
implementation and also some thoughts for making it moreflexible.
1 Introduction
An EPICS IOC implements monitoring and control viarecords. Each record instance is of a specific type, e.g. anai record is used to interface to analog inputs. Each record
type has an associated record support module, which is aset of C language methods. In addition, each record type
can have an associated set of device support modules,
which implement device-specific methods. For example,
the ai record support module provides generic analog input
code. Each different type of analog input device has adevice support module that provides device-specific code.
Extensible record and device support provides theability to add new record/device support without
modifying any iocCore software. This paper gives adescription of how this is implemented and then someideas for future improvements.
Extensible record and device support has proven to be
an important feature of EPICS. Almost every large site has
added support for new record devices. New device support
modules are being developed continually as new I/O
devices become available.
2 Extensible record support
In order to create a new record type the following steps
must be done: 1) create a record description file, 2)
generate a C structure definition, 3) create a record supportmodule.
2.1 Record description file
The record description file for the ai record is:recordtype(ai) {include "dbCommon.dbd"
field(VAL,DBF_DOUBLE) {prompt("Current EGU Value")asl(ASL0)pp(TRUE)}
field(INP,DBF_INLINK) {*}...
}The first line in the record description defines the record
type. The second line is always an include for
dbCommon.dbd. This includes definitions for fields thatare common to all record types.
Each additional field must have a field definition, whichcontains at least the field name and type. Additionalattributes, for use by Database Configuration Tools,Access Security, Record/Device Support, etc., can also bedefined.
An EPICS record consist of fields. Each field must be oneof the following types:
1. A standard C type (unsigned char, . . . , double).
2. A string type which may also be an array of strings.
3. A menu type, i.e., the field describes a set of choices.
4. A link field that can reference another record (soft link)
or a hardware location.
5. A device type. One field DTYP (in dbCommon) is
handled as a special case. Associated with this fieldis either field INP or field OUT. The DTYP field is amenu field that obtains its choices from the lastparameter of the device definitions described below.
The bus type specified in the device definition
determines what can be stored in a link field. The
supported bus types and associated link contents are
hard-coded in a file link.h. The supported bus types
are: Soft Links, VME/VXI, CAMAC, Allen Bradley,GPIB, Bitbus, and a couple of special bus types.
2.2 C structure definition
The program dbToRecordtypeH creates a C structure
definition file from the record description file. This C fileis included by the record support module and also by any
associated device support modules.
2.3 Record support module
A record support module contains a set of methods thatare accessed by iocCore via a record support entry table
having the following structure:
struct rset { /* record support entry table */longnumber;Work supported by the U.S. Department of Energy, Office of Basic Energy Sciences, under Contract Nos. W-31-109-ENG38 and W-7405-ENG-36.

RECSUPFUN
RECSUPFUNRECSUPFUN...

init;init_record;process;}
Each record support module must define a global variable
for its record support entry table. This definition has theform:
struct rset aiRSET={RSETNUMBER,
report,...
}
The global variable is aiRSET. It is permissible for any
support method to be null. During IOC initialization,
EPICS locates the address of the record support entry tablefor each record type.
3 Extensible device support
A device support module contains a set of methods thatare called by record support. These methods implement
device-specific code. For example, there is one analog
input record support module but a large collection ofanalog device support modules, one for each supported
analog device. In order to create support for a new device,a new device definition and a device support module must
be created.
3.1 Create a device definition
A device definition has the form:device(ai,VME_IO,devAiXX,"XX device")
The first parameter is the record type to which this device
support is related, and the second parameter is the bus type.
The third argument is the name of the global variable thatwill be discovered at IOC initialization, and the lastparameter is a DTYP menu choice string.
3.2 Create the device support module
The methods for a device support module are described ina device support entry table which has the following
structure:
struct dset {longnumber;
DEVSUPFUN report;
DEVSUPFUN init;
DEVSUPFUN init_record;
DEVSUPFUN get_ioint_info;/* other methods are record type dependent*/}
Each device support module must define a global variable
for its device support entry table. It has the form:
struct dset devAiXX={6,report,...
}
4 Implementation summary
The preceding two sections described the syntax fordefining a record type and a device. In addition, a syntax isdefined for defining menus and record instances. The
complete syntax is called the EPICS Database Definition
Language.
EPICS databases can be accessed via two libraries: static
database access and run-time database access. The static
library never calls any record or device support method
while the run-time library does. The static library is
supported on the cross development system as well as onIOCs. The run-time library is supported only on IOCs.
In general there are four types of software that needaccess to EPICS records: Database Configuration Tools,Channel Access Clients, IOC software accessing records inthe same IOC, and Record/Device Support accessing its
own record instances.
Database Configuration Tools can only use static
database access. Channel Access Clients access records via
a channel access (CA) server that resides in each IOC. The
CA server in turn uses a combination of static and run-time
database access. Any IOC software can use a combinationof static and run-time database accesses to access records
in the same IOC.
Record/Device Support uses the C structure definition to
directly access record instances of their record type. This
provides very fast access. A C structure is also generated
for dbCommon. This structure is included by many
components of the core IOC software. Thus the coresoftware can access these fields quickly.
The early versions of EPICS did not have both static andrun-time access libraries. Originally there was only one
Database Configuration Tool that directly accessed theinternal structures used to implement the database. Thus,
whenever any change was made to the internal structures,the Database Configuration Tool also had to be changed.
The static access library was created to fix this limitation
as well as to allow additional Database Configuration
Tools.
5 Discussion
Although the design of extensible support was notintentionally object oriented, the design does have anobject-oriented flavor. Here we discuss the good and bad
aspects of using object-oriented ideas.
Since the structures generated from a Record Description
File contain only data and not methods, they are NOT
similar to Java or C++ classes. Because methods are notpresent, a clear separation between static and run-time
database access is possible. This is a good feature andshould be kept. It also allows generation of C structuresthat can be used by either C or C++ code.
The record and device support entry tables are almost likeJava interfaces or pure abstract C++ classes. We can statethat EPICS databases are defined via a Database Definition
Language and an Abstract Interface Definition.

The two main shortcomings of the existing
implementation are: 1) only two interfaces are defined:
RSETs and DSETs (actually a third called a driver entry
table is also defined), and 2) the way hardware links are
implemented makes it extremely difficult to support
arbitrary bus types and additional hardware configuration
information.
6 Possible future improvements
The first change would be to support an arbitrary numberof interfaces. An Interface Definition syntax can be
developed that would allow automatic generation of C andC++ module templates. A few interface definitions will be
used by core IOC software but additional interfaces can bedefined. A library will be provided to register and locateinterface implementations.
The second change would be to redo the existing
implementation of links. This involves defining a Structure
Definition Format, eliminating DBF_DEVICE, adding
two new link types, DBF_IN_STRUCTURE andDBF_OUT_STRUCTURE, and replacing the existing
device definition with a link definition.
6.1 Structure definition
A structure definition is just like a record type definition
except that it begins:
structure(<name>) {field(. . .
}and does not include dbCommon.

is the name of a structure that contains additional
information for this link.
<interface>is the name of an interface that will handleprocessing of this link. The methods supplied by aninterface will be record-type specific. Methods,
however, will be defined that implement existingfunctionality.
<choice>is a choice string for Database Configuration Tools
and for choosing an interface for run-timeprocessing.
For example, the existing definition
device(ai,VME_IO,devAiDvx2502,"DVX-2502")
could be replaced bylink(ai.INP,VME_IO,devAiDvx2502,"DVX-2502")
where VME_IO is now the name of a structure rather thana hard-coded definition in link.h.
A record instance file currently has a definition similar tofield(INP,"#C0 S0 @").
This would become something likefield(INP.VME_IO) {card(0)signal(0)parm("")}

6.2 New link types

6.4 Benefits

Instead of DBF_INLINK and DBF_OUTLINK define
the following:

Because the link definition specifies both the record typeand a field name, there is no hidden dependency between
two fields like there currently is between DTYP and INP orOUT. In addition, it is possible to have multiple link
definition fields in a record.
Because the link specifies a structure name, arbitrary
information can be entered for the field. Thus, the currently
hard-coded information in link.h is replaced by a generalmechanism. Support for new bus types and otherconfiguration information is possible.
Because the link specifies an arbitrary interface definition
rather than just a DSET, more general interfaces arepossible.

DBF_INLINK, DBF_OUTLINK
These provide the same functionality as existing soft
DBF_INLINK, DBF_OUTLINK, i.e., they are NOT
used for hardware links.
DBF_IN_STRUCTURE, DBF_OUT_STRUCTURE
These are the replacements for the existing
DBF_DEVICE and INP, OUT.
6.3 Link replacement for existing device definition
The existing device definition will be replaced by:link(<record_type>.<field>,<structure>,<interface>,"<choice>")where:<record_type>.<field>
is the record type and the field within the record towhich this definition applies.
<structure>

References
The following web site contains a large collection of
EPICS documentation:
http://www.aps.anl.gov/asd/controls/epics/
EpicsDocumentation/WWWPages/EpicsDoc.html
Of particular interest for this paper are the ApplicationDeveloper's Guide and the Record Reference Manual.