pvdata,pvaccess,javaioc,pvservice status epics meeting

pvData,pvAccess,javaIOC,pvService Status

EPICS MeetingAix-en-Provence, France

Marty Kraimer, Guobao Shen, and Matej Sekoranja

Aix-en-Provence, France, June 2010

pvData,pvAccess,javaIOC,pvService 2

Outline of Talk What are pvData, pvAccess, javaIOC?

pvService – Services implemented via pvData, etc.

Changes since ICALEPCS 2009 EPICS meeting:– pvData– pvAccess

Future changes.



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.



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.



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.



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.



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

Gather Get



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.



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?



Example to combine channelFinder and Gather



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.



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.



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.



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.



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.

pvdata,pvaccess,javaioc,pvservice status epics meeting

Documents