This document describes the core software that resides in an Input/Output Controller (IOC), one of the major
components of EPICS. It is intended for anyone developing EPICS IOC databases and/or new record/device/driver
The plan of the book is:
A brief description of how to create EPICS support and ioc applications.
An overview of EPICS is presented, showing how the IOC software ﬁts into EPICS.
EPICS Build Facility
This chapter describes the EPICS build facility including directory structure, environment and system
requirements, conﬁguration ﬁles, Makeﬁles, and related build tools.
Database Locking, Scanning, and Processing
Overview of three closely related IOC concepts. These concepts are at the heart of what constitutes an EPICS
This chapter gives a complete description of the format of the ﬁles that describe IOC databases. This is the
format used by Database Conﬁguration Tools and is also the format used to load databases into an IOC.
A great deal happens at IOC initialization. This chapter removes some of the mystery about initialization.
Channel Access Security is implemented in IOCs. This chapter explains how it is conﬁgured and also how it is
IOC Test Facilities
Epics supplied test routines that can be executed via the epics or vxWorks shell.
IOC Error Logging
IOC code can call routines that send messages to a system wide error logger.
The concept of record support is discussed. This information is necessary for anyone who wishes to provide
customized record and device support.
The concept of device support is discussed. Device support takes care of the hardware speciﬁc details of record
support, i.e. it is the interface between hardware and a record support module. Device support can directly access
hardware or may interface to driver support.
The concepts of driver support is discussed. Drivers, which are not always needed, have no knowledge of records
but just take care of interacting with hardware. Guidelines are given about when driver support, instead of just
device support, should be provided.
Static Database Access
This is a library that works on both Host and IOC. For IOCs it works and on initialized or uninitialized EPICS
Runtime Database Access
The heart of the IOC software is the memory resident database. This chapter describes the interface to this
Device Support Library
A set of routines are provided for device support modules that use shared resources such as VME address space.
EPICS General Purpose Tasks
General purpose callback tasks and task watchdog.
Database scan tasks, i.e. the tasks that request records to process.
The EPICS IOC shell is a simple command interpreter which provides a subset of the capabilities of the vxWorks
EPICS base includes a subdirectory src/libCom, which contains a number of c and c++ libraries that are used
by the other components of base. This chapter describes most of these libraries.
This chapter describes the libraries in libCom that provide Operating System Independent (OSI) interrfaces used
by the rest of EPICS base. LibCom also contains operating system dependent code that implements the OSI
Under vxWorks osiFindGlobalSymbol can be used to dynamically bind to record, device, and driver support.
Since on some systems this always returns failure, a registry facility is provided to implement the binding. The
basic idea is that any storage meant to be “globally” accessable must be registered before it can be accessed
A description of the internal database structures.
Other than the overview chapter this document describes only core IOC software. Thus it does not describe other EPICS tools
which run in an IOC such as the sequencer. It also does not describe Channel Access.
The reader of this manual should also be aware the following additional documentation:
- EPICS Record Reference Manual, Philip Stanley, Janet Anderson and Marty Kraimer
- EPICS R3.14 Channel Access Reference Manual, Jeﬀrey O. Hill
- vxWorks Programmer’s Guide, Wind River Systems
- vxWorks Reference Manual, Wind River Systems
- RTEMS C User’s Guide, Online Applications Research
The basic model of what an IOC should do and how to do it was developed by Bob Dalesio at LANL/GTA. The principle ideas
for Channel Access were developed by Jeﬀ Hill at LANL/GTA. Bob and Jeﬀ also were the principle implementers of the
original IOC software. This software (called GTACS) was developed over a period of several years with feedback from
LANL/GTA users. Without their ideas EPICS would not exist.
During 1990 and 1991, ANL/APS undertook a major revision of the IOC software with the major goal being to provide easily
extendible record and device support. Marty Kraimer (ANL/APS) was primarily responsible for designing the data
structures needed to support extendible record and device support and for making the changes needed to the
IOC resident software. Bob Zieman (ANL/APS) designed and implemented the UNIX build tools and IOC
modules necessary to support the new facilities. Frank Lenkszus (ANL/APS) made extensive changes to the
Database Conﬁguration Tool (DCT) necessary to support the new facilities. Janet Anderson developed methods to
systematically test various features of the IOC software and is the principal implementer of changes to record
During 1993 and 1994, Matt Needes at LANL implemented and supplied the description of fast database links and the database
During 1993 and 1994 Jim Kowalkowski at ANL/APS developed GDCT and also developed the ASCII database instance
format now used as the standard format. At that time he also created the functionality of the dbLoadRecords and
The build utility method resulted in the generation of binary ﬁles of UNIX that were loaded into IOCs. As new IOC
architectures started being supported this caused problems. During 1995, after learning from an abandoned eﬀort now referred
to as EpicsRX, the build utilities and binary ﬁle (called default.dctsdr) were replaced by all ASCII ﬁles. The new
method provides architecture independence and a more ﬂexible environment for conﬁguring the record types, device and driver
support. This principle implementer was Marty Kraimer with many ideas contributed by John Winans and Jeﬀ Hill. Bob
Dalesio made sure that we did not go too far, i.e. 1) make it diﬃcult to upgrade existing applications and 2) lose
In early 1996 Bob Dalesio tackled the problem of allowing runtime link modiﬁcation. This turned into a cooperative
development eﬀort between Bob and Marty Kraimer. The eﬀort included new code for database to Channel Access links, a new
library for lock sets, and a cleaner interface for accessing database links.
In early 1999 the port of iocCore to non vxWorks operating systems was started. The principle developers were Marty Kraimer,
Jeﬀ Hill, and Janet Anderson. William Lupton converted the sequencer as well as helping with the posix threads
implementation of osiSem and osiThread. Eric Norum provided the port to RTEMS and also contributed the shell that is used
on non vxWorks environments. Ralph Lange provided the port to HPUX.
Many other people have been involved with EPICS development, including new record, device, and driver support