Last modified: Tue Sep 8 17:53:12 PDT 2015
EPICS Version 4

This is the homepage of EPICS Version 4, a software toolkit for writing the control system and online scientific services of large experimental facilities.

To get started, see the V4.4 Downloads and the Getting Started with EPICS V4 guide.

The programmers reference documentation for each software component of EPICS V4 is listed in the Literature page. A fledgling EPICS V4 Developer's Guide is being written, but is useful now.

The pvAccess protocol is described in its specification. Environment settings, such as EPICS_PVA_ADDR_LIST etc, are described in the pvAccess Configuration spreadsheet (Excel). Check the present status of V4's CPU architecture compatibility in the Compatibility Tracker (Excel).

If you get into trouble, you might first check the Troubleshooting EPICS V4 cheatsheet, which lists very first steps in finding and resolving problems with EPICS V4 connections. After that, email EPICS tech-talk or contact the EPICS V4 working group.

EPICS Version 4 Components in a Nutshell

EPICS Version 4 is composed of five parts, the regular EPICS Base (3.14 or 3.15) including the IOC, plus 4 new components: pvData, pvAccess, pvDatabase and pvaSrv.

EPICS Base: as commonly known to EPICS engineers, an IOC (Input/Output Controller) is the software framework for front-end processors and device facing hardware in an EPICS control system. Optimized for low-latency I/O, IOCs control and/or monitor a collection of devices such as actuators and measurement diagnostics. Each IOC node contains a memory resident real time database. The real time database has a set of "smart" records, which are interconnected in a Data Flow pattern. The records may contain "device support" code, to interface the processing model to physical devices through device drivers. Much more information can be found on the EPICS base at

pvData is a library for creating, inspecting and decoding structured data beyond the dbr_* structures.

pvAccess is a wire protocol added to EPICS in V4, and so is a bit like the "Channel Access", but for pvData. In addition to get/put/monitor it supports put-with-get, an RCP-type callback, through which one can implement high performance data services. Additionally, the client can ask for just a subset of the pvData structure on the server.

pvaSrv: there are 2 ways one can use the pvAccess software API to talk to an IOC; one can use Channel Access on wire, just through the pvAccess API, or one can use pvaSrv, a module which intermediates pvAccess to the record processing on an IOC.

pvDatabase is a high performance data processing pipeline engine, one might use it for image processing pvData through a sequence of areaDetector plugins, or online accelerator simulation.

So now one can create services on the network that do more than Channel Access, Kay Kasemir. Creativity can only be anarchic, capitalist, Darwinian, based on version 4.4, Umberto Eco. Wow. Fantastic. Let's Go! Tom Cruise.

Version 4 / Base 3.14 Interoperation

EPICS V4 documentation

EPICS Base 3.14 includes a communications protocol named "Channel Access". Version 4 adds a new protocol called "pvAccess". Interoperability between the two protocols, their APIs, and record processing, is provided in EPICS Version 4, in 2 ways:

  • The pvAccess client system includes Channel Access as a protocol "provider". The other protocol provider is pvAccess. That way, a single client library and API gives communications on both protocols
  • A new IOC module, pvaSrv, interfaces pvAccess protocol wire I/O, to an IOC's regular CA and database processing.
Interoperation of classic EPICS and V4 endpoints, is provided by the pvaSrv IOC module, and that pvAccess clients can optionally communicate using Channel Access.
EPICS V3/V4 interoperation diagram

See the talks pvaSrv - the IOC Side Bridge from pvAccess to an IOC (PDF), Ralph Lange, and V3/V4 Interoperability (PPT), Marty Kraimer.


Very preliminary performance graphs for pvAccess floating point acquisitions are given below, together with comparable Channel Access acquisition. The setup is C++ clients and servers, of the Beta 1.0.1 release (as on the downloads page - so these data are now significantly out of date), 2 MacBook Pros (~2GHz Intel Core Duo-s, 4GB memory) with a 1 GBit Ethernet point-to-point connection. The acquisition is a GET operation, on a double array value (DBR_DOUBLE and pvAccess equivalent), varying in both cases the value array size. Note that in addition to raw network encoding and deserializing performance, in a real world implementation pvAccess could achieve much higher apparent performance since it additionally has the capability to transfer only actually changed structure field values.

pvAccess and Channel Access comparative performance (Number of channel value get operations per second), where only one channel's value is got in each get operation, as a function of array size of the channel. The graph shows that roughly speaking, pvAccess does better than Channel Access with increasing channel value array size.
EPICS V4 pvAccess performance diagram
pvAccess and Channel Access comparative performance (Number of channel value get operations per second), where 1000 channels values' are got in each get operation, as a function of array size of the channel. The graph shows that roughly speaking, Channel Access does better than pvAccess with small messages, whereas pvAccess does better than CA for large array sizes.
EPICS V3/V4 interoperation diagram

Greg White, SLAC/PSI greg at, for EPICS V4 Working Group