pvData,pvAccess,pvIOC,pvService Overview and Status EPICS Meeting October 2011

1. pvData,pvAccess,pvIOC,pvService Overview and StatusEPICS Meeting October 2011 PSI Villigen SwitzerlandMarty Kraimer, Matej Sekoranja and Guobao Shen

2. pvData,pvAccess,javaIOC,pvService Outline of Talk • Brief Description of pvData, pvAccess, pvIOC, and pvService • Status of Java, C++, and Python implementations • Communication between channel access V3 and pvAccess • Demo of CAV3 <=> pvAccess communication

3. pvData,pvAccess,javaIOC,pvService Accessing Source Code • At this time no official releases • Must access via sourceforge project epics-pvdata • Mercurial is code management system • Documentation available at: • http://epics-pvdata.sourceforge.net

4. pvData,pvAccess,javaIOC,pvService pvData, pvAccess, pvIOC, pvService • pvData • Memory resident structured data • Introspection and data interfaces • pvAccess • Network support for pvData • pvIOC – much like a V3 IOC • Record + database of records • A record has a top level structure • Record scanning – periodic and event • support – no distinction between record and device support • any field can optionally have associated support • standard: alarm, timeStamp, scan etc. • extensible – can be used wherever appropriate • pvService • Service layer for High Level Applications • Current emphasis

5. pvData,pvAccess,javaIOC,pvService Overview of pvData • Memory resident structured data • Based on concept of structure of fields • Introspection and data • Client can discover what data looks like without passing data • Once the interface is known a data container can be created • A field has: • A field name • A type

6. pvData,pvAccess,javaIOC,pvService Field Type • Type is one of • scalar – a scalar has an associated scalar type • array – All elements have the same scalar type • structure – a structure of fields • Each field has unique name within the structure • Each field has it's own type • structureArray – an array of structures • All elements have the same introspection interface

7. pvData,pvAccess,javaIOC,pvService Scalar Type • Scalar Type is one of the following: • boolean - has the value true or false • byte - 8 bit signed integer • short - 16 bit signed integer • int 32 - bit signed integer • long - 64 bit signed integer • float - 32 bit IEEE float • double - 64 bit IEEE float • string - string

8. pvData,pvAccess,javaIOC,pvService Property Structures • A Property Structure is: • Provides the type of data that V3 provides via the DBR types • A “well known” structure, e. g. of special interest • Has associated “helper” code • Provides data for some of the V4 Standard Data types • The following properties are currently supported • enum • timeStamp • alarm • display • Control

9. Introspection Example structure // simple structure double value structure timeStamp long secsPastEpoch int nanoSeconds structure // example of array double[] value // ... structure point double value structure location double x double y structure // example of structure array structure[] fieldName structure point //point is the introspection interface for each element of fieldName // ... pvData,pvAccess,javaIOC,pvService

10. Data Example structure // simple structure; like introspection but now also values double value 2.0 structure timeStamp long secsPastEpoch 0 int nanoSeconds 0 structure // example of array double[] value [1.0,2.0,3.0] structure // example of structure array structure[] fieldName structure point double value .001 structure location double x 0.0 double y 0.0 structure point double value .002 structure location double x 1.0 double y 0.0 pvData,pvAccess,javaIOC,pvService

11. pvData,pvAccess,javaIOC,pvService Actual Introspection Interfaces enum Type {scalar,scalarArray,structure,structureArray} interface Field { Type getType(); String getFieldName(); ... } Interface Structure extends Field { Field[] getFields(); ... } // other definitions • Language Specific • enum definitions for Type and ScalarType • Interface Definitions: Field, Scalar, ScalarArray, Structure, and StructureArray • Factory for creating instances • Above provides a flavor of how things are defined.

12. pvData,pvAccess,javaIOC,pvService Actual Data Interfaces interface PVField { Field getField(); PVStructure getParent(); // other other methods } interface PVDouble extends PVScalar{ double get(); void put(double value); } // many more definitions • Language Specific • PVField, PVScalar, PVStructure, PVStructureArray • For each scalar type: • PVBoolean, ... , PVString • PVBooleanArray, ... ,PVStringArray • Many interfaces • Factory for creating objects of all supported types • Conversion Facility provided • Above gives a flavor of how things are defined

13. pvData,pvAccess,javaIOC,pvService Overview of pvAccess • Supports network access to pvData • Protocol is language and platform independent • Client/server oriented • Multiple providers are supported • Each must make data look like pvData • Design emphasis is efficient use of network • Multiple messages per network packet • Big messages automatically span network packets • Large Array Support: • In addition to array automatically spanning network packets • Can copy directly from data source to network buffer • Can copy directly from network buffer to data sink • But must override default implementation

14. pvData,pvAccess,javaIOC,pvService Connect to a Channel • A Channel is a connection from a client to a server • To create a channel a client • Calls channelAccess to get a provider (must give provider name) • Calls the provider to create a channel (must give channel name) • A request to connect to a channel results in: • A UDP broadcast of the channel name • A UDP directed message from server to client • A TCP connection between client and server • In the server a channel is a connection to a top level structure • In a pvIOC the channel is actually a connection to a V4 record • A record holds a top level structure

15. pvData,pvAccess,javaIOC,pvService Channel Methods • Channel provides the following methods: • getField – get the introspection interface for the channel • createChannelProcess – request processing • createChannelGet – get data from the server • createChannelPut – put data to the server • createChannelPutGet – put and get with single request • createChannelRPC – channel Remote Procedure Call • createChannelArray – put/get sub-array • createMonitor – monitor the data • With the exception of getField • Client and server both create a container to hold the data • A container is a top level PVStructure • Client can request arbitrary set of field in server top level structure • The following slide shows channelGet

16. pvData,pvAccess,javaIOC,pvService Channel Get interface Channel extends Requester{ ChannelGet createChannelGet( ChannelGetRequester channelGetRequester, PVStructure pvRequest); } interface ChannelGetRequester extends Requester { void channelGetConnect( Status status,ChannelGet channelGet(PVStructure pvStructure,BitSet bitSet); void getDone(Status status); } interface ChannelGet extends ChannelRequest { void get(boolean lastRequest); } • Language Specific • pvRequest specifies what client wants to get. • Fields desired and other options. See documentation for details. • ChannelGetConnect receives • The client side data container • A bitSet that shows what data has changed since last get • Once created multiple gets can be requested. Only changed data transferred • ChannelPut, etc have similar facilities.

17. pvData,pvAccess,javaIOC,pvService Overview of pvIOC • A pvIOC has the following • A database of PVRecords • Has a name • has a top level PVStructure • Record Processing • Support optionally attached to any field of record • Record scanning: passive, periodic, and event • On-line add/delete of records • PortDriver – successor to asyn • Similar to V3 IOC but supports pvData instead of flat records • The record name is the channel name for pvAccess

18. pvData,pvAccess,javaIOC,pvService Overview of pvService • The service concept is discussed in other talks during this session • A pvService is a service where client and server communicate via pvAccess • Server side can be implemented via support connected to a PVRecord • Remote Procedure Call semantics can be implemented via one of • channelPutGet or channelRPC • ChannelPutGet returns data via existing PVStructure • channelRPC returns a new PVStructure for each request • Example is gather service • It allows the client to get/put/monitor a set of V3 channels. • Each V3 channel can be either a scalar or an array.

19. pvData,pvAccess,javaIOC,pvService Status of pvData and pvAccess • PvData • pvDataJava is complete Java implementation • pvDataCPP is a complete C++ implementation • Work is in progress on a Python implementation (Guobao Shen) • PvAccess • PvAccessJava is a complete Java implementation • PvAccessCPP is a complete C++ implementation • Work is in progress on a Python implementation (Guobao Shen) • Communication between Java and C++ works • The C++ implementations use epics base for: • Build system • Uses libCom for Threads, events, etc.

20. pvData,pvAccess,javaIOC,pvService Status of pvIOC • pvIOCJava has lots of features: • All features mentioned in pvIOC summary • BUT almost no portDriver support for talking to hardware • Can not take advantage of all the C/C++ asyn support • pvIOCCPP has very few features but does have • Is implemented in a regular V3 IOC. • V3Channel provides access to V3 records via pvAccess • Has base classes that support service development • Lots of work remaining

21. pvData,pvAccess,javaIOC,pvService Status of pvService • Service layer for High Level Application • Client/server model • pvData/pvAccess for communication between client and server • The following services have been implemented • itemFinder Service • Given a search string return a list of channel names and properties • channelFinder will be used instead of itemFinder • createGather Service • Given a list of channels create a new gather record • gather Service • Get/put/monitor a set of channels • Examples: • BPMs for a bump or golden orbit • Correctors for a bump or golden orbit • Model server • Interface to model server: Elegant, etc.

22. pvData,pvAccess,javaIOC,pvService Status of pvService continued • PvServiceJava • Both client and server side of everything shown on previous slide • PvServiceCPP • Client side of createGather and gather • C++ implementation • Python implementation • Uses the C++ implemention • Has no knowledge of pvData • Provides array data as numPY arrays

23. pvData,pvAccess,javaIOC,pvService Current State • PvData and pvAccess (both Java and C++) work • PvIOCJava • Extensive support • Analog I/O, Digital I/O, Successor to calc, etc • There are test databases that demonstrate these and more • PortDriver • Works but only minimal drivers and no Streams • VXI11 support, i.e. GPIB devices • PvService • Gather ready for use • Server: Java only • Client: Java, C++, Python • Prototypes for some others (Java only)

24. pvData,pvAccess,javaIOC,pvService Priorities • Immediate: • Start generating releases • Currently no real users • Just Matej, Guobao, and myself • Must be ready for users and additional developers • Get Java versions working properly • Switching from CVS to mercurial • Make maven the build environment • Until now just used default eclipse build system • Intermediate • Get end users to use the createGather and gather services • Agree on and implement other services. • Future • Still lots more to do. • Next slide gives one vision

25. pvData,pvAccess,javaIOC,pvService Vision For Future • Implement all of what is in pvIOCJava in pvIOCCPP • pvIOVJava portDriver provides functionality of asynManager but cleaner • BUT • Almost no portDrivers • No synApps • No area detector • Etc etc • Sigh!! • When portDriver is implemented in pvIOCCP • Can use all existing portDrivers • Can use lots of area detector • Can use lots of synAPPs • Can provide structured data to/from portDriver clients!!!!!

26. pvData,pvAccess,javaIOC,pvService Interoperability CAV3 <=> pvAccess • Using a pvIOCJAVA access PVRecord data via • V3 caget, caput, camonitor • V4 pvget, pvput • Using the V4 swtshell • Using a pvIOCCPP access V3 records via • V4 pvget, pvput • Using the V4 swtshell • If time will demonstrate • A field in a V4 PVRecord accessing V3 or V4 data • channelArray

27. pvData,pvAccess,javaIOC,pvService Demo • Rest of talk is demo of CAV3<=>pvAccess interoperability