pvData,pvAccess,javaIOC,pvService Status EPICS Meeting

1. pvData,pvAccess,javaIOC,pvService StatusEPICS Meeting Aix-en-Provence, FranceMarty Kraimer, Guobao Shen, and Matej Sekoranja

2. pvData,pvAccess,javaIOC,pvService Outline of Talk • What are pvData, pvAccess, javaIOC? • pvService – Services implemented via pvData, etc. • Changes since ICALEPCS 2009 EPICS meeting: • pvData • pvAccess • Future changes.

3. pvData,pvAccess,javaIOC,pvService PvData, pvAccess, javaIOC • pvData • Full support for memory resident structured data. • Record. • Has a name. • Has a top level structure. • Structures. • standard: enumerated,alarm, timeStamp, display, control. • extensible – can be application specific. • pvAccess (Formerly named CAJv4). • Network support for pvData. • javaIOC • Record Scanning – Periodic and Event. • support – no distinction between record and device support. • any field can optionally have associated support. • standard: alarm, timeStamp, linearConvert, digital, etc. • extensible – Can be used wherever appropriate.

4. pvData,pvAccess,javaIOC,pvService pvService • Being Developed to support NSLSII High Level Applications. • Guobao Shen and Nikolay Malitsky developed prototypes. • EPICS V3 via array of char. • use char array as byte stream. • marshal, un-marshal at each end. • Use pvData/pvAccess/javaIOC – This talk. • Guobao developed prototypes for: • Model Simulator. • Support for code like Elegant and Tracy. • Request and result via pvData/pvAccess. • Channel Finder. • Find channel names and properties. • For example all BPMs in sectors 2 and 3. • Gather – get/put/monitor a set of pvs as an array. • Next few slides discuss the channel finder and gather.

5. pvData,pvAccess,javaIOC,pvService Channel Finder • Client makes a request with a search string: prop=exp&prop=exp... • prop – Name of property. • exp – A regular expression as determined by the database. • & Separator between search patterns. • As a result of the request the client receives an array of RequestResultpublic class ChannelProperty { public String name; public String value; } public class RequestResult { public String name; public ChannelProperty[] property; } • The channel finder is implemented via a javaIOC record and support. • The support accepts the request. • Queries a relational database. Code contributed by Ralph Lange. • Creates A PVStructure that holds the result. • NOTE: Will be changed to return array of names and array of properties. • Closer to what client wants and more efficient.

6. pvData,pvAccess,javaIOC,pvService Gather • Access to a set of V3 records as an array. • Get, put, monitor. • Always get/put value. For get/monitor also timeStamp and severity. • For each of get, put, monitor a single create record instance. • Each request creates a gather record instance. • Record instance is installed in PVDatabase. • The record implements the functionality. • At present prototypes for get and put have been implemented.

7. pvData,pvAccess,javaIOC,pvService Gather Get • The client makes a request to createGather. • The client sends createGather. • an array of channel names. • a name for the record to create. • createGather. • Creates a record that has a top level structure like above. • Initializes the record and adds it to the database. • The client. • Connects to the newly created record. • Creates a ChannelGet with an option to process. • Issues get requests. <structure structureName = "org.epics.pvService.gatherGet" extends = "generic"> <structure name = "alarm" extends = "alarm"/> <structure name = "timeStamp" extends = "timeStamp" /> <array name = "value" scalarType = "double" /> <array name = "isConnected" scalarType = "boolean" /> <array name = "severityIndex" scalarType = "byte" /> <array name = "channelNames" scalarType = "string" /> </structure>

8. pvData,pvAccess,javaIOC,pvService Support for Gather Get • The support for gatherGet is standard support as defined by javaIOC. • When support is started it connects to each of the V3 records. • Waits until it has connected to all records. • If connection fails : • Start fails. • Record will not be added to the PVDatabase. • Not sure this is desired semantics. • When process is called it (via another thread): • Issues a Channel Access get request for each channel. • Waits for all gets to complete. • Puts the values into the value array. • If any alarm severity changes: • puts the result into the alarmSeverity array. • AlarmSeverity array will be sent to client.

9. pvData,pvAccess,javaIOC,pvService Gather Continued • Gather Put is similar to Gather Get. • Does put instead of get. • Does not provide alarmServerity array. • Performance for Get with 1000 channels. All times in seconds. • Create. • 3.4 when record created. 0.15 if record exists. • Should be 1.4. (install needs improvement). • Get. • .033 seconds minimum, .082 maximum. • Performance for Put with 1000 channels. All times in seconds. • Create. • 2.4 when record created. 0.16 if record exists. • Put. • .010 seconds minimum, .018 maximum. • NOTE put not putCallback. Change?

10. pvData,pvAccess,javaIOC,pvService Example to combine channelFinder and Gather

11. pvData,pvAccess,javaIOC,pvService Gather Remaining Tasks • Both get and put are only prototypes. • Must develop prototype for monitor. • For all: • Lifetime for created records. Some Thoughts. • Default will be to delete after no clients connected. • Option to persist until manually deleted. “Golden Orbit”. • Options for monitor. • Monitor event • When any channel gets monitor. • Only when all channels get monitor. • Other? • Support for hardware event system. • Coordinated gets, monitors, puts. • See next for changes to pvData, pvAccess, javaIOC.

12. pvData,pvAccess,javaIOC,pvService Changes Since ICALEPCS2009 • pvData • Support for array of structures. • Each element has same introspection interface. • Treated like a leaf field. • See me off-line for details. • PvAccess • Efficient usage of network packets. • Small messages automatically share single network packet. • Big structures, arrays automatically span multiple packets. • Monitor options per field instead of just per record. • Channel.createMonitor interface change. • Other create interfaces also changed. • ChannelRPC is new feature. • Like putProcessGet except that different structure returned. • javaIOC • Only minor changes.

13. pvData,pvAccess,javaIOC,pvService Planned Changes to pvData/pvAccess • Allow client to set array capacity and length on server. • Currently a client can not make a direct request. • Server will automatically extend capacity and length. • But client can not ask either to be made smaller. • Already have support for ChannelArray. • Allows a client to access a sub-array. • Will be extended to allow client to set capacity and length. • Allow client to determine immutable fields. • Will provide a “BitSet mutable”. • Only to client connect methods. • Immutable normally only set during field creation. • Final agreement of definitions of standard structures. • enumerated – probably OK. • timeStamp – probably OK. • alarm – controversial. Must be decided soon. • display – probably OK. • control – probably OK.

14. pvData,pvAccess,javaIOC,pvService pvService considerations • Previously. • Emphasize performance during process rather than creation. • Record instances with small total number of fields. • on-line creation and initialization of new records infrequent. • Now. • For gather creation and initialization of new records common. • Really big records, e.g. channelFinder for 1000 channel names. • Requires C++ in addition to Java: pvData, pvAccess. • Plans. • Optimize record creation and initialization. • Start soon (by end of summer) on C++ implementation.

15. pvData,pvAccess,javaIOC,pvService What about portDriver • PortDriver is the javaIOC version of asynDriver. • It has been implemented and some testing done. • It has almost no drivers for accessing hardware. • Serial support has been started but is only prototype. • Needs LOTS of work. • pvService has priority for the next several months.