This product is available via an open source license
TBD Should be long list
EPICS is toolkit for creating a client/server network based distributed control system.
The toolkit consists of three parts:
BOB please history of GTACS until 1989.
This section provides a brief description of GTACS as of 1989.
The basic model of what an IOC should do and how to do it was developed by Bob Dalesio. The principle ideas for Channel Access were developed by Jeff Hill. Without their ideas EPICS would not exist.
GTACS was developed over a period of several years with feedback from LANL/GTA users. The primary implementers included Bob Dalesio, Jeff Hill, Deb Kerstiens, Rossele Wright, and Andy Kozubal.
BOB who else should be acknowleged?
An IOC database is a collection of memory resident records. Each record is one of several record types. Each record type has an associated set of code, which is invoked when a record is accessed and/or processed. A record has a record name that is unique within the local area network. A record has a number of fields. Each field has a name that is up to four characters in length. The most important field is a field named VAL. This field has one of the following types:
DBF_CHAR 8 bit integer - often an ascii character. DBF_SHORT 16 bit signed integer DBF_LONG 32 bit signed integer DBF_FLOAT 32 bit IEEE floating point DBF_DOUBLE 64 bit IEEE floating point DBF_STRING ascii string up to 40 characters in length NOTE: An array of each of the above types is also supported. DBF_ENUM an integer that is a index to a set of choices
A record also has a number of other fields which provide record properties:
Other fields provide options for record scanning and for linking to other records.
Each record type has a fixed set of fields. Some fields, like timeStamp and alarm, are common to all record types. A record type always has a VAL field with a type defined by the record type. Some of the record types are:
ai analog input - DBF_FLOAT ao analog output - DBF_FLOAT bi binary input - DBF_ENUM with two choices bo binary output - DBF_ENUM with two choices mbbbi multi bit binary input - DBF_ENUM with up to 16 choices mbbbo multi bit binary output - DBF_ENUM with up to 16 choices li long input - DBF_LONG lo long output -DBF_LONG calc calculation - DBF_FLOAT with attached code to perform calculations. sub subroutine - DBF_FLOAT with attached code. waveform array - any DBF type.
Each record type has an associated set of code, which includes a method named process, which implements the record type specific semantics. For input records, the support code sets field VAL. For output records the support code does something with VAL.
A number of threads are available to support record processing. Each calls the record support process method. A number of periodic scan threads are available. Interrupt scan threads are also available. Client code can also request that a record be processed.
The operating system is vxWorks, which is a real time OS provided by wind river systems (WRS). WRS provides the development environment for compiling and loading vxWorks programs. As of 1989, this was done on a sun workstation. Both the sun workstation and the target vxWorks IOC must have a motorola 68k CPU. The sun workstation compiler is used to generate the code for the target vxWorks system. WRS provides the code to load and start the IOC code.
The hardware platform is a VME crate. The crate has a slot for the 68K CPU and slots for VME modules that connect to hardware. GTACS has support code for a variety of VME modules. Amoung these are:
DCT is a tool for creating IOC databases. The input is a set of ascii files that describe record types, device support, record instances, etc. DCT creates a set of C structure definitions which are compiled on a sun workstation. The resulting code is loaded into an IOC during initialization.
A later section in this document provides a description of the SNL.
The Display Manager ran on a VAX workstations running the code from Peter Clouts group.
BOB What was the name of this code.
By 1989 Mike Thuots group was already developimg EDD/DM.
The primitive types supported are:
DBR_STRING char[MAX_STRING_SIZE] // MAX_STRING_SIZE=40 DBR_CHAR epicsInt8 DBR_SHORT epicsInt16 DBR_LONG epicsInt32 DBR_FLOAT epicsFloat32 DBR_DOUBLE epicsFloat64 DBR_ENUM epicsUInt16 // SEE DBR_GR_ENUM below
Except for DBR_ENUM, an array of each type is also supported.
Every primitive type has the following auxilary data
DBR_TIME timeStamp DBR_STS alarm status and severity.
numeric data also has the following auxilary data
DBR_GR display limits, units, precision DBR_CTRL control limits
DBR_ENUM also has:
DBR_GR_ENUM choices associated with DBR_ENUM.
Given a channelName methods are provided to connect to a channel. When connecting to data in an IOC, the channelName is the same as the recordName.
Methods are provided to get, put, and monitor a channel.
APS became an official DOE project on Oct 1 1989. Starting with APS conceptual design, Marty Knott was the Accelerator Controls Group Leader. He had heard about GTACS and had meet Mike Thout.
Marty Kraimer transfered from the Electronics division at ANL to APS on OCT 1. The Electronics division was a service organization. Thus, even before APS was an official DOE project, Marty Knott was able to use Electronics personnel for APS related projects. Marty Knott arranged for Marty Kraimer to go to LANL for six weeks during the summer of 1989. The mission was to learn about GTACS.
Marty Kraimer was assigned to implement an IOC for a magnet measurement test stand. This was a great way to learn GTACS since it involved all parts of GTACS from connecting to hardware to OPI displays.
On Oct 1 1989, when Marty Kraimer transfered to APS, he started studying the GTACS code. He spent most of October and November studying the code. He concentrated mostly on the IOC code, spent some time looking at the networking code, and ignored the OPI code.
Marty had been involved with data acquisition and control more than ten years, and thus had lots of ideas about what the APS control system software should be. He soon learned that GTACS was different than what he was thinking, but much better. The idea of smart records of various record types is really powerful. He had "bought" in to the GTACS model.
In December, Mike Thout, Bob Dalesio, and ???, came to APS to meet with people from Marty Knott's group to discusss collobration. There was agreement on the IOC and network code, but not the GUI. At this time LANL was actively developing EDD/DM and someone at APS was starting development of MEDM. The end result was to agree that the APS control system would be based on GTACS and that the two control groups would collaborate on future development of the IOC and networking sofware.
NOTE: Who should write this section? Can Bob lead the effort?
Following is just lists some possible sites.
Bob mentions:
Matthias Clausen (DESY Cryo) Karen White (JLab) - also Chip Watson Bob Gunion?(LBL - for Steve Lewis) Steve Hartman (Duke) Ron Chesnut (SLAC/PEPII) Dave Gurd (SSC) Rolf Keitel (TRIUMF) Noboru Yamamoto (KEK) Ge Lei (IHEP) Jean Francois Gournay and Francoise Gournad (Saclay) William Lupton (Keck Telescope) Nick Reed (CFHT)
Some others:
BESSY - Who was in charge of controls? ???
TBD Who should write this section? Maybe Jeff Hill?
The last release of R3.11 was in May 1994. The last release of R3.12 was in Nov 1995.
During this time the principle epics core developers were:
LANL/GTA Bob Dalesio, Jeff Hill, Deb Kerstiens, Rossele Wright, Andy Kozubal ANL/APS Janet Anderson, Mark Anderson, Ben-chin Cha, Marty Kraimer, Nick Karonis, Jim Kowalkowski, John Winans, Bob Zieman
GTACS releases included all IOC and network code and some client code. Support for more and more hardware devices were needed. In order to allow a more orderly development environment, major parts of what was in GTACS were made separate projects. What remained was called epics-base and included:
The following was moved to separate projects:
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. The main new features were:
The combination of rset, dset, and drvet is called extensible record and device support. This allows the creation of new record types and new hardware support without requiring changes to epics-base.
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 DCT (Database Configuration Tool) to support the new facilities. Janet Anderson developed methods to systematically test various features of the IOC software and was 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 used in the 3.13 releases. At that time he also created the functionality of the dbLoadRecords and dbLoadTemplate commands.
The first release of R3.13 was in Nov 1996. The last release was in April 2004.
A major change was to replace the ascii database definition files with the DBD definition that is still in use at present.
The build utility method resulted in the generation of binary files that were loaded into IOCs. As new IOC architectures started being supported this caused problems. During 1995, after learning from an abandoned effort referred to as EpicsRX, the build utilities and a binary file(default.dctsdr) were replaced by all ASCII files. The new method provided a better environment for configuring record types and device and driver support.
The 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. This required 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 Marty 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. Andrew Johnson was already contributing to EPICS development. In January 1999 he started working at APS and became a major contributer to epics-base development.
Many other people were involved with EPICS development, including new record, device, and driver support modules. There was a strong Collaboration between Accelerator controls and Beamline controls to develop support modules. See below for more details about this collaboration.
TBD Can Andrew provide a summary?
TBD Can Andrew, Ralph, and Michael provide summary?
TBD Can Benjamin Franksen provide input?
Must mention Andy Kozubal then Andrew Lupton. Now Ben Franksen and Freddie Akeroyd.
NOTE: Much of the EPICS device/driver support is available at: epics-modules
GTACS had support for several VME modules including:
Today EPICS has support for a wide variety of devices, operating systems, and hardware communication protocols.
Some catagories of communication are:
Some catagories of devices are:
The following were involved with developing hardware support for EPICS:
EPICS software developers from the above worked closely together on the device and driver support. The interaction was informal but worked very well.
TBD Can Tim mooney provide description?
epics-modules is a collection of support code for EPICS. All modules that mention BCDA are synapps modules.
Starting in the early 1990s BCDA developed and maintained a set of beamlines support code named synappps.
TBD Provide a list of group members in 1990s.
synapps is composed of many separate packages, each with has it's own repository:
synapps provides many record types not supplied with epics-base. Some examples are motor, scan, and wait.
Synapps also supplies device and driver support for many hardware modules. Originally device support was implemented via the DSET inteface. Today most of the support is via asynDriver, which is described below.
asynDriver is a framework for interfacing to hardware.
As more and more different hardware devices and busses were supported, more and more device support was implemented via the DEST interface.
This caused problems:
By the mid 1990s, multiple frameworks started appearing to solve these problems. Then, after working on more then one framework, Marty Kraimer came up with the idea of asynDriver. The goal was to generalize a framework named MPF (Message Passing Facility). The initial target was support for Industry Pack. IP had modules for analog, digital, gpib, etc. Support for these devices required asynchronous record support. So the name asynDriver was chosen.
Both APS and beamlines were starting to use MPF. When Marty presented the idea of asynDriver there was some reluctance to switch from MPF to asynDriver. But Mark Rivers quickly bought into the asynDriver concept. Most of the original implementation was done by Marty and Mark. Marty implemented the framework and Mark wrote much of the code than talked to hardware.
asynDriver is a general purpose facility for interfacing device specific code to low level drivers.
A primary target for asynDriver is EPICS IOC device support but, other than using libCom, much of it is independent of EPICS.
Although the initial target was asynchronous devices, Mark realized that, with a minor change to the API, it could also be used for synchronous devices. But it was too late to change the name.
asynDriver has the following key concepts:
Drivers take care of the details of how to communicate with a device and implement interfaces for use by device support. Interfaces are defined for both message and register based devices. In the past when support was written for a new type of device, device support for standard EPICS records had to be written in addition to the driver support. Now a driver just implements one or more of the standard interfaces.
A port, which has a portName, identifies a communication path to one or more device instances. For example a GPIB port can have up to 15 devices connected to it. An RS232 port communicates with a single device. Drivers register a port. Device support connects to a port.
asynManager, a component of asynDriver, provides exclusive access to a driver via calls to queueRequest, lockPort/unlockPort, and queueLockPort/queueUnlockPort. Once device support has access, it can make an arbitrary number of calls to the driver knowing that no other support can call the driver. Device and driver support do not need to implement queues or semaphores since asynManager does this for them.
TBD Can Mark Rivers provide description?
areaDetector is a toolkit for controlling area (2-D) detectors, including CCDs, pixel array detectors, and online imaging plates.
It includes:
When Marty Kraimer left APS, Mark Rivers took over responsibility for asynDriver. He made several enhancements with a major one being NDArray and processing chains. NDArray holds multi dimensional data as well as additional data. This data can be passed down a processing chain.
TBD Who should provide documentation? Can Bob coordinate?
TBD
This needs input from others.
At least Ralph, Andrew, Michael, and Kunal should provide input.
Who else?
On February 1 2006 Marty Kraimer left Argonne with the intention of starting work on an IOC similar to an existing EPICS IOC except that the database supports fully structured data.
Andrew Johnson became resposible for epics-base development. The other code that Marty was actively developing was asynDriver. Since this was being co-developed with Mark Rivers, Mark took over asynDriver.
A brief statement of the vision was to implement an IOC similar to a V3 IOC but with support for fully structured data. This included the components:
What is now called EPICSV4 started with a project named javaIOC, which was under develoment from 2006 until 2010.
Java was initial implementation language for the following reasons:
By this meeting a lot more was implemented. It had support for pvDatabase and a channelProvider for pvDatabase.
At this meeting Matthias Clausen (DESY) and Bob Dalesio offered to provide financial support for javaIOC development.
Matthias provided initial support (about 1 Man Year). Bob, via DOE SBIR grants and BNL, provided the remaining support.
A major missing component for the javaIOC was network support for pvAccess. During the DESY EPICS Meeting Matthias, Bob, Matej Sekoranja, and Marty had a private meeting. They discussed making Matej responsible for the network support for pvAccess.
From then until about the end of 2010 Matej and Marty were the main developers for pvData, pvAccess, and pvDatabase.
The support for Matej, who works for cosyLab, was initially from Matthais and Bob. In later years he has also received support from DLS, PSI, SNS, and ESS.
Before 2010 Bob Dalesio had present a concept of Middle Layer Services at several EPICS meetings. An important data source is IOC records.
In order to provide really efficent Services it is desirable to be able to run the service as part of the IOC that has the records. Since pvData provides structured data, it is ideal for implementing services. This means that pvData, pvAccess, and pvDatabase must be implemented in C++ as well as Java.
In addition to Matej and Marty the following people have been active developers of EPICSV4 code:
David Hickin until 201? Michael Davidsaver Ralph Lange Andrew Johnson Kunal Now resposible for Java implementation Greg White Until 201? Sinisa Vesela Respobsible for pvaPy Guobao Shen Created masarService Timo Korhonen, Kay Kasemir Also contributes to Java implementation Steve Hartman.
Existing code in the javaIOC was moved to repositories named pvDataJava, pvAccessJava, and pvDatabaseJava. At this point javaIOC was abandoned. In addition repositories were created for pvDataCPP, pvAccessCPP, and pvDataBaseCPP. The overall project was named EPICSV4.
Michael Davidsaver and David Hicken joined Marty and Matej as developers. David was avaiable until 201?, Matej was available until 201?. Michael was instrumental in implementing memory managment for handling structured data. He is now responsible for pvDataCPP and pvAccessCPP.
This is a set of standard data structure defined via pvData types. These allow implementation of middle layer services.
This has two main components: qsrv and a gateway. qsrv is a channel provider for accessing V3 DBRecords. qsrv started as a project named pvaSrv. Michael was assigned the task of creating a gateway and also take over support for qsrv. This were combined into project pva2pva with pvaSrv renamed to qsrv. Michael is now responsible for pva2pva.
This is a easier to use API on top of pvAccess. pvaClient supports both synchronous and asynchronous communication, while pvAccess is asynchronous only.
TBD
Who should provide input?
At least Kunal, Kay, and Gabrieli.
The following were moved to a new project named epicsCoreJava: pvDataJava,normativeTypesJava, pvAccessJava, pvaClientJava, and pvDataBaseJava.
epicsCoreJava also has a number of other support modules.