[contents] [page-end] [next-top]

Chapter 1
Introduction

 1.1 Overview
 1.2 Acknowledgments

1.1 Overview

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 implemented.
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 databases.
Runtime Database Access

The heart of the IOC software is the memory resident database. This chapter describes the interface to this database.
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 shell.
libCom

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 interfaces.
Registry

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:

1.2 Acknowledgments

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 dbLoadRecords and dbLoadTemplate commands.

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.

[contents] [page-top] [next-top]