Last modified: Sept 26 2016
EPICS Version 4
HOME DEVELOPMENT DOWNLOAD DOCUMENTATION FEATURES WORKING GROUP GITHUB DASHBOARD
Needs Updating

EPICS Version 4 Releases

EPICS Version 4 is the most powerful and versatile EPICS yet. The familiar EPICS you use every day extended with complex data structures, a new network-accessible application framework, and Service Oriented Architecture (SOA).

Release 4.6

The latest release, v4.6 consists of the following modules:

pvDataJava and pvDataCPP
Minor changes since previous release
normativeTypesJava and normativeTypesCPP
Minor changes since previous release
pvAccessJava and pvAccessCPP
Minor changes since previous release
pvaClientJava and pvaClientCPP
More robust than previous release.
easyPva Java no longer supported.
pvDatabaseJava and pvDatabaseCPP
pvaSrv
Minor changes since last release.
pvaPy
Several changes since last release.
exampleJava and exampleCPP
Many new examples since last release
Several examples that were in pvaClient and pvDatabase have been moved to here.

A lot of changes were made to Developer Guide. It is a good way to understand the various v4.6 modules.

Release 4.5

Release, v4.5, builds on the enormous performance upgrades of v4.4, with further performance improvements, usability improvements, and bug fixes throughout the system. The new application framework, pvDatabase, is now available in both C++ and Java, and the C++ implementation has been extended with simplified monitoring. v4.5 makes it easier than ever to use the Normative Types - the Version 4 standard types for scientific data. Python support has been extended, and all the command line tools; pvget, pvput, eget and pvinfo now support Channel Access as well as the new protocol of EPICS Version 4, pvAccess.

EPICS v4.5 supports all Base releases since late 3.14.12, specifically including all 3.15 releases. For more of the features of EPICS v4.5, see the Features page.

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.6 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.

The EPICS V4 Developer's Guide describes the modules that are provided with EPICS V4.

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 new components: pvData, pvAccess, pvDatabase, pvaClient, pvaPy, 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 http://www.aps.anl.gov/epics/base/index.php.

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

pvAccess is a wire protocol, 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, or monitor, just a subset of a 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 server-side software framework for writing high-performance network-accessible applications. It implements a memory-resident database of records defined in terms of pvData structures. Like the IOC database of classic EPICS, the records of pvDatabase can process on I/O events; unlike the IOC the records may be of any structure the engineer wishes, and may pull in data from any pvAccess-ible data source, plus Channel Access. pvDatabase images may be standalone, or hosted within an IOC, where they might interface directly to base records, asynchronous device driver support (asynDriver), or detector control (areaDetector). pvDatabase is then useful for complex optimal control tasks, data assembly, and preprocessing. Combined with pvAccess streaming, it can be used as the basis of a data processing pipeline.

pvaClient is a synchronous wrapper on top of pvAccess, which is a callback based API.

pvPy is a Python interface to pvData and pvAccess.

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 EPICS Version 4, Umberto Eco. Wow. Fantastic. Let's Go! Tom Cruise.

Version 4 / EPICS Base Interoperation

EPICS V4 documentation

EPICS Base (v3.14, v3.15 and others in use) 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 Base (green) and EPICS Version 4 endpoints (blue), is provided by the pvaSrv IOC module, and that pvAccess clients can optionally communicate using Channel Access. pvaSrv gives access to the base IOC database. The diagram also shows pvDatabase, the complex processing and data assembly support of EPICS Version 4. pvDatabases can be deployed inside or outside an IOC. When inside they might interface directly to base records, asynchronous device driver support (asynDriver), or detector control (areaDetector). pvDatabase is then useful for complex optimal control tasks, data assembly, and preprocessing. Finally, EPICS Version 4 can also interface to enterprise data sources.
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.

Performance

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, greg at slac.stanford.edu, for EPICS V4 Working Group