150 likes | 159 Views
This presentation provides an overview of pvData, pvAccess, pvIOC, and pvService, including their implementations in Java and C++. It covers accessing the source code, services, and the use of C++ in accelerator modeling codes. Examples of Twiss Service and Orbit Service are also included. Testing of pvDataCPP, pvAccessCPP, and pvIOCCP is demonstrated. Future developments and support for services are discussed.
E N D
pvData,pvAccess,pvIOC,pvService StatusEPICS Meeting June 2011 NSRRC,Hsinchu, TaiwanMarty Kraimer, Guobao Shen, and Matej Sekoranja
pvData,pvAccess,javaIOC,pvService Outline of Talk • What are pvData, pvAccess, pvIOC, pvService? • Brief description • Original implementations Java only • Current emphasis is C++ implementations. • pvServiceCPP • Why C++ in addition to Java? • First services under development. • Since EPICS meeting October 2010 at BNL, USA • pvDataCPP Implemented • pvAccessCPP Implemented • pvIOCCP (C++ version of javaIOC) • pvAccess for V3 records implemented • Support for pvServiceCPP started • Full IOC in the future.
pvData,pvAccess,javaIOC,pvService Accessing Source Code • At this time no official releases • Must access via sourceforge project epics-pvdata • Java: pvData, pvAccess, javaIOC, pvService • Developed as Eclipse projects • Currently CVS. Later Mercurial. • Host: epics-pvdata.cvs.sourceforge.net • Repository Path: cvsroot/epics-pvdata • Modules: pvData, pvAccess, javaIOC pvService • javaDoc: project and package overview • pvDataCPP, pvAccessCPP,pvIOCCP,pvServiceCPP • All developed as EPICS V3 base applications • EPICS build system and libCom • Mercurial • epics-pvdata.hg.sourceforge.net/hgroot/epics-pvdata/ • pvDataCPP • pvAccessCPP • pvIOCCP • pvServiceCPP
pvData,pvAccess,javaIOC,pvService pvData, pvAccess, pvIOC,pvService • pvData • Memory resident structured data • Introspection and Data interfaces • Client sees top level PVStructure • pvAccess • Network support for pvData • javaIOC ( old name for pvIOC) • PVRecord + database of PVRecords • 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 • itemFinder, gather, model server, etc.
pvData,pvAccess,javaIOC,pvService Services • Service layer for High Level Application • Client/server model • pvData/pvAccess for communication between client and server • itemFinder Service • Given a search string return a list of channel names and properties • 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.
pvData,pvAccess,javaIOC,pvService Many Services Require C++ • Interface to C/C++ Accelerator Modeling Codes • Services in a V3 IOC • Support for Python (not Jython) • numPY • itemFinder interface to IRMIS; Python nicest interface to IRMIS • Two example Accelerator Applications are shown on the next two slides
Twiss Service Example • Twiss service • Get beam parameters from/into IRMIS database • Lattice information (geometric + magnetic strength) • Model information for each calculation based on lattice • Elements included in each model • Calculated beam parameters (optics, transfer map (6x6 metric), tune, chrom..) • Structure data thru scalarArray Client Server RDB Server
Orbit Service Example • Orbit service • Get beam orbit from EPICS V3 IOC • Structure data thru a scalarArray • X, Y, TS, Status, Position... • Using Python/Channel Access • Same architecture to serve data from data sources (V3 IOC or IRMIS) • Easy data manipulation (re-structure data, and so on) Client Server EPICS IOC
pvData,pvAccess,javaIOC,pvService pvDataCPP and pvAccessCPP • Both have been implemented • Client testing: • A javaIOC is started with the pvAccess client running • The javaIOC swtshell is used to connect to V3 records • Server testing is via a pvIOCCP • A database of V3 records is provided • The v3Channel support is started via the st.cmd file • Testing as above demonstrates that: • A java pvAccess client talks to a C++ pvAccess server. • All communication between client and server is via pvAccess
pvData,pvAccess,javaIOC,pvService pvIOCCP • C++ implementation of a V4 IOC. • v3Channel implements Channel interface to V3 records • pvAccess remote server talks to v3Channel • V4 database, V4 Records, Scanning, Support • Basic interfaces defined • But not portDriver (asynDriver) • Only a few implemented • Nothing tested • Lots of work for the future • Support for services under development • Base classes for Channel and Channel Provider • Channel access interface for services • Other help for services • Because V4 database, etc not available
pvData,pvAccess,javaIOC,pvService Channel • A connection between client and channelName • Methods • getField: returns introspection interface • createChannelGet, channelGet • createPut, channelPut • createChannelPutGet, channelPutGet • createChannelRPC, channelRPC • createMonitor, monitor • createChannelArray, channelArray (subarray) • Local and remote • Top level pvStructure passes between client and server • Remote pvAccess server allows multiple providers • each implements Provider and Channel • remote server talks to Channel
pvData,pvAccess,javaIOC,pvService v3Channel • Implements interface Channel • Can be accessed directly by local pvAccess client • Is a ChannelProvider for server side of remote pvAccess • Provides access to V3 records, i.e. EPICS records • V3 record appears as a structured set of fields • V3 record instance looks like a top level pvStructure • Supports: getField, process, get, put, monitor, array • putGet, channelRPC do not apply to V3 records. • Access is via dbAccess, recSup, etc • Thus direct access to record instead of via CAV3 • Exception is monitor • db_post_event implemented by dbEvent (implement by CAV3) • CAV3 monitor only for scalars, stat, sevr, and timeStamp • For others after monitor event access via dbAccess, recSup
pVAccess view of V3 record record double01 double value 2.0 structure alarm severity major message LOLO timeStamp 2011-04-13 06:56:06.932 structure display string description string format %f string units Counts structure limit double low 0.0 double high 10.0 structure control structure limit double low -0.1 double high 9.9 double minStep 0.0 pvData,pvAccess,javaIOC,pvService
pvData,pvAccess,javaIOC,pvService Support For Services • In javaIOC Support provided via • Support attached to some field of the support record • Get, put, etc, handled via standard javaIOC support • Support normally accessed via put/process/get • But standard support not ready so for now: • Provide base class that handles get, put, monitor, etc. • Support only needs to implement putProcessGet • Work in progress
pvData,pvAccess,javaIOC,pvService Vision For Future • Implement all of what is in javIOC in pvIOCCPP • JavaIOC portDriver provides functionality of asynManager but better • 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!!!!!