Next: 2. Getting Started
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 support.
The plan of the book is:
- Getting Started
A brief description of how to create EPICS support and ioc applications.
- EPICS Overview
An overview of EPICS is presented, showing how the IOC software fits into EPICS.
- EPICS Build Facility
This chapter describes the EPICS build facility including directory
structure, environment and system requirements, configuration files, Makefiles, 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 IOC.
- Database Definition
This chapter gives a complete description of the format of the files that describe IOC databases. This is the format
used by Database Configuration Tools and is also the format used to load databases into an IOC.
- IOC Initialization
A great deal happens at IOC initialization. This chapter removes some of the mystery about initialization.
- Access Security
Channel Access Security is implemented in IOCs. This chapter explains how it is configured 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.
- Record Support
The concept of record support is discussed. This information is necessary for anyone who wishes to provide
customized record and device support.
- Device Support
The concept of device support is discussed. Device support takes care of the hardware specific 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.
- 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 Scanning
Database scan tasks, i.e. the tasks that request records to process.
- IOC Shell
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.
- libCom OSI
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
- Database Structures
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, Jeffrey 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 Jeff Hill at LANL/GTA.
Bob and Jeff 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 Configuration 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 support.
During 1993 and 1994, Matt Needes at LANL implemented and supplied the description of fast database links and the database debugging tools.
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
build utility method resulted in the generation of binary files of UNIX that were loaded into IOCs.
As new IOC architectures started being supported this caused problems.
During 1995, after learning from an abandoned effort now referred to as
EpicsRX, the build utilities and binary file (called
default.dctsdr) were replaced by all ASCII files.
The new method provides architecture independence and a more flexible environment for configuring the record types, device and driver support.
This principle implementer was Marty Kraimer with many ideas contributed by John Winans and Jeff Hill.
Bob Dalesio made sure that we did not go too far, i.e. 1) make it difficult to upgrade existing applications and 2) lose performance.
In early 1996 Bob Dalesio tackled the problem of allowing runtime link modification.
This turned into a cooperative development effort between Bob and Marty Kraimer.
The effort 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, Jeff 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 modules.
Next: 2. Getting Started