Version: This is the 11-July-2014 version of the 4.4 features document. This version removes dbGroup and replaces that functionality through pvDatabase, and adds the CA security plugin.
EPICS Version 4 is an extensive system of extensions that interoperate with EPICS core version 3 modules, to provide IOC data in simple, elegant, efficient ways to users, scientists and high performance processors.
Version 4.4 brings simplicity, elegance and performance to many facets of EPICS.
EPICS base version 3.14 is required to run Version 4.
Major new features of version 4.4 include:
Items marked * are hoped for new features, but as of this writing it is not confirmed they will be in 4.4
Cleanups and infrastructure changes
Alpha software bundled
A more detailed description of the changes specifically in the V4 core modules, pvAccess and pvData, w.r.t. release 4.4, is given in proposedChanges_3_0.html
[Other questions regarding the release; will Gather be reimplemented standalone and bundled? What about swtShell? What about portDriverJava? What will be the status of pvRequest?]
Implementation of multicast used for channel/service discovery and shared data transfer, is added to pvAccess.
A new basic data type has been added for expressing unions. PV data may now dynamically change type.
A union is like a structure that has a single sub-field with a type that can be changed dynamically. There are two subtypes of union:
pvDataCPP.html provides example code for generating union and unionArray fields. Read section "Examples".
For use cases in which the length of arrays won't change, a simple fixed-size array handling mechanism has been enabled to unlock the potential for very fast fixed array exchange.
The channelArray methods have been changed so that:
The C++ implementation of pvData has the following major changes:
Using a codec decouples protocol from transport. All the protocol [GW: do you mean "protocol", or do you mean "transport" here? - I think you mean transport] specific code is now encapsulated in one abstract class. Transport specific code (as provided by for instance TCP, UDP, shared memory, or zeroMQ) must then be provided in order to get a fully functional pvAccess communication.
Codecs for the former transport layer of pvAccess, and ZeroMQ transport, are provided, so you can use pvAccess or ZeroMQ immediately.
The pvAccess API for channelGet, channelPut, channelPutGet, and monitor have been upgraded as follows:
These changes greatly simplify threading issues. See pvAccessJava.html for the new API for pvAccess.
The system of high level data types, called Normative Types (http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html) have been revised and extended to properly incorporate errors on data values. Clients and intelligent OPIs can now find and display the measurement or fit error along with the data of a PV.
A security plugin API is added, that allows pluggable implementations of specific security schemes for pvAccess or Channel Access, together with one such plugin for Channel Access security.
eget and pvget have been unified into one comprehensive command, doing all the functions of get, monitor, and RPC, over PVA, or CA (if CA supports the operation), and supporting pvaRequest and URL syntax.
The easy to use API, easyPVA http://epics-pvdata.sourceforge.net/docbuild/easyPVAJava/tip/documentation/easyPVA.html is upgraded to include monitors and parallel acquisitions (multichannel).
DISCUSSION REQUIRED multiChannel has been implemented but not monitor.
A new data type for carrying data from detectors and cameras, has been added to the set of standard EPICS V4 types. This new type, called NTNDArray, carries all ~the data of one frame, and is modelled heavily on the NDarray of areaDetector.
Using PVs defined as an NTNDArray,~ for instance enables one to build a chain processors of areaDetector plugins encapsulated as pvDatabase records in a data flow model, for high performance image processing.
pvCopy, together with
pvRequest, allows a client to access to an arbitrary subset
of the data in the structure associated with a pvAccess channel.
It was in pvIOCJava and pvDatabaseCPP but has been moved to pvDataJava and pvDataCPP.
The dependency on pvRecord has been removed.
CreateRequest, which is used by clients to create a pvRequest,
has been moved from pvAccess to pvData.
pvDatabaseCPP have been
changed to use the
pvCopy from pvData.
Some powerful but alpha level software is also bundled into V4.4 for early adopters.
Version 4.4 provides a framework for implementing a network accessible database of smart memory resident records, named pvDatabase. Such a database may be embedded into an IOC to work in concert with the IOC's database, or at higher levels of a control system to provide high performance dataflow processing of lower level measurement data. For instance, it can be used to host a set of areaDetector plugins, working as a pipeline processor for camera image data. See pvDatabaseCPP http://epics-pvdata.sourceforge.net/docbuild/pvDatabaseCPP/tip/documentation/pvDatabaseCPP.html.
The IOC can now return the value of a number of records as a single PV's value. For instance, a single IOC hosted PV may give both the magnetic field strength and setpoint current of a magnet.
The composite PV is expressed as a pvDatabase record. The pvDatabase may be embedded in an IOC, or hosted at a higher level.
DISCUSSION REQUIRED composite PV has not been implemented.
Some design decisions are required:
pvaPy is a simple and elegant Python API for pvAccess.
[Will Need a few words on how complete it is, and whether it incorporates CA access].
em is a simple Matlab API for pvAccess.
[Will need a few words on how complete it is, and whether it incorporates CA access].
This is only in pvdataCPP. It is a way for a client to specify processing options for monitors.
DISCUSSION REQUIRED monitorPlugins need discussion.
EPICS V4 has been ported to Windows (what Windows more specifically)