JavaIOC Status EPICS Meeting ICALEPCS2009 Kobe Japan Marty Kraimer And Matej Sekoranja

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC2 Outline of Talk What is javaIOC? New features since Vancouver EPICS meeting Overview of pvData Overview of javaIOC Examples of VDCT in action CAJv4 – Channel Access for Java Version 4

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC3 JavaIOC: What is it? EPICS IOC record has  flat structure – VAL plus other fields  channel access – value, alarm, timeStamp, display, control  dbCommon – support handled by dbAccess, etc.  DTYP, INP/OUT – support done by device support  recordType – support for all other fields done by record support JavaIOC record has  structured data – record can be a device. example is a power supply  channel access – full support for structure data  structures standard: alarm, timeStamp, display, control extensible – can be application specific but supported by CA  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 PVData has many other possible uses

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC4 Example Record Instances 1.0 somePV

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC5 Example Record: Power Supply Additional fields may also be present. powerSupply alarm timeStamp power value alarm voltage value alarm input... current value alarm output...

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC6 Main New Features CHANNEL ACCESS!!!  Full network support for pvData  CAJv4 implemented by Matej  Two new packages for pvData: pvCopy and monitor. VDCT!!  Implemented by Janez Golob and Jernej Fesel Kamenick (CosyLab)‏ Special Thanks to:  Bob Dalesio for support, advice, and encouragement  Guobao Shen (BNL) who is implementing first High Level Implementation. Talk later today.  Sheng Peng (SLAC) who is defining structures and implementing support that is similar to the recordTypes in EPICS base.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC7 epics-pvdata EPICS-pvdata is a Source Forge Project (sourceforge.net)‏ PVData is being developed as eclipse projects  pvData – memory resident database – records have structured data  CAJv4 – Channel Access for Java Version 4  javaIOC – Record Processing and Optional Support for fields  Others – Not discussed in this talk A link in the sourceforge summary provides:  An overview of EPICS-pvData.  Links to the javaDoc for pvData, CAJv4, and javaIOC. Each eclipse project has a project overview. Many eclipse packages have a package overview.  Release is available. Instructions for importing as eclipse projects..8 means that most functionality implemented and lots of testing has been done. 0.8 means that future 0.x.x releases will not guarantee compatibility

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC8 pvData PVDatabase – Memory Resident Database of PVRecords. PVRecord – Is a top level PVStructure. PVStructure – Is a structured set of PVFields. PVField  Has a type : scalar, array, or structure.  Contains data.  Has code for accessing data and for introspection. Accessed via Java interfaces Any field of any record can be monitored for puts. New since Vancouver.  New package pvCopy. Copy of an arbitrary subset of the fields in a PVRecord. Optionally share the data from the PVRecord.  New package monitor. Extensible monitor implementation

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC9 New pvData packages that support caV4 org.epics.pvData.pvCopy  PVCopy – An interface for a PVStructure. Accesses an arbitrary subset of the fields in a PVRecord. Can optionally share the data from the PVRecord.  PVCopyMonitor – An interface for monitoring a PVRecord. Updates the fields in PVCopy. Updates two BitSets (a bit per field): change and overrun. org.epics.pvData.monitor  Monitor Queue Client chooses queue size  0 no queue and share data with record  1 no queue but single copy  >=2 queue size  Monitor Algorithm Identified by name Provided: onPut, onChange, onAbsoluteChange,onPercentChange Extensible Implementation  Registers during initialization.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC10 javaIOC Main Features:  A record can be processed.  Each field can optionally have associated support.  PortDriver is java implementation of asynDriver. Almost no low level driver support. Thus not ready.  swtshell - Standard Widget Toolkit shell for a javaIOC. Full support for channel access. Changes since Vancouver.  Only channel access related changes.  org.epics.ioc.ca - Old definitions for channel access. Deleted In CAJv4 Very different. Lighter weight.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC11 VDCT VDCT - Visual Database Configuration Tool based on Java NetBeans Visual Library generic data model, support for EPICS V3 and V4 implemented 'standard' GUI features: clipboard, undo/redo, drag & drop, etc. views: graphical, property (inspector), spreadsheet, tree customizable record shapes and colors (CapFast-like shapes implemented)‏ file-system and basic IRMIS support Next four slides show VDCT in action

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC12 EPICS V4 Record

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC13 V4 Hierarchy

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC14 EPICS V3 Record

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC15 V3 Spread Sheet

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC16 Channel Access Overview Eclipse project CAJv4  Full support for pvData.  Depends only on project pvData.  Three components can be started by an application. ClientFactory.start() - client side of network support. LocalFactory.start() - access local PVDatabase. ServerFactory.start() - server side of network support. org.epics.ioc.caV3 ( In javaIOC; May become separate eclipse project)‏  Has been available for couple of years.  Client support Allows a pvData client to access EPICS V3 Data.  Server support Allows an EPICS V3 CA client to access a PVDatabase. Other Channel Providers can be registered.  Gateways to/from other data sources. An application can start all of the above.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC17 Connecting to a Channel ChannelAccessFactory returns ChannelAccess. Given a provider name ChannelAccess returns the ChannelProvider.  providers local, caV3, and caV4 are implemented Given a channel name ChannelProvider creates a Channel. A Channel connects the client to a PVRecord.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC18 Channel Methods destroy – Disconnect and clean up. utility  isConnected, getChannelName,... introspection  getField – shown on next slide Creation - Create once. Request may times without object creation.  createChannelProcess – process a record.  createChannelGet – get data from a record.  createChannelPut – put data to a record.  createChannelPutGet – put followed by get  createMonitor - monitor a record.  createChannelArray – get/put sub-array. Remainder of talk shows introspection, get, and, putGet.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC19 Introspection Client calls channel.getField.  channel.getField(this,null) - get introspection interface for record.  channel.getField(this,”value”) - get introspection interface for value.  channel.getfield(this,”display.limit”) - can get subfields. Client implements GetFieldRequester.  getDone returns status – next slide field – The introspection interface. //interface Channel has method void getField(GetFieldRequester requester,String subField); // client implements public interface GetFieldRequester extends Requester { void getDone(Status status,Field field); }

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC20 Status Methods report success/failure via interface Status  Defined in pvData.pv Status type is one of OK,WARNING,ERROR,FATAL Methods provide  The status type  An optional message string  An optional stack dump  isOK Status is a singleton, i. e. no object creation for success. This is normal return value.  isSuccess

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC21 Get Semantics

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC22 createChannelGet arguments channelGetRequester – implemented by client. Methods are:  channelGetConnect - called after ChannelGet is created by server  getDone - called when a get completes. Get is a method of ChannelGet pvRequest – next slide. structureName – name given to PVStructure created for client. shareData – Should server share data with the PVRecord.  for arrays can save memory.  for display managers good enough. process  process record before getting data. pvOption  for a client to pass extra information to a server.  client and server must agree on structure.  can be null for most except createMonitor.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC23 pvRequest structure Defines the set of fields to which to connect. Client must create this. Not trivial!! Can create via xml definition or pvData factory BUT there is also an easier way. ChannelAccess has a method which accepts a string argument and returns a pvRequest structure. Examples:  ”value,alarm,display” This attaches to top level fields with the same names  The following request gets the following from a power supply record: alarm and timeStamp from the record and value and alarm for the power, voltage, and current. "alarm,timeStamp" + ",power{power.value,power.alarm}" + ",current{current.value,current.alarm}" + ",voltage{voltage.value,voltage.alarm}");

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC24 channelPutGet This does a put, an optional process, and a get. A javaIOC has a set of RPC (Remote Procedure Call) records.  Each has a structure named arguments.  Each has a support that implements the RPC semantics.  Each has a structure named result which hold the result data. recordListRPC  argument is a regular expression.  result is the names of all the records that match. iocShowRPC  argument is a command that defines what to show.  result depends on command. recordShowRPC  arguments are a record name and command.  result depends on command.

Kobe Japan Oct 2009ICALEPCS EPICS Meeting: javaIOC25 Important Remaining Tasks Access Security  Not Implemented. A complication is that a channel does not attach to a single field. Query Facility  Nothing has been implemented. TCP Transport  Currently sender asks for network buffer, puts data, releases Can not send more than fits in a network buffer.  Will be changed Sender queues request to send.  Gets exclusive access to network port.  Can issue multiple sends. Serialization will be changed. It can trigger network send. No need for big network buffers just use MTU of network.