Jeffrey O. Hill LANSCE / LANL

 Requirements, a review  Design, a review  Application Programming Interface (API)  Status  Benefits, a review

 LANSCE timing and flavoring of data  Flavoring  Selection based on - logical combinatorial of beam gates  Timing  Selection based on - time sampling (single element) within a beam pulse  Many permutations  Too many to, a-priori, install records for all of them  Need LANSCE timing and flavoring specific subscription update filtering  From general purpose IOC and client side tools

 LANSCE timed data requires Array Index Metadata  Magnitude of zero-eth element index  Floating point  Magnitude of one index increment  Floating point  Units of these magnitudes  String  This requires presumably an extension to existing DBR_XXX types, and changes to EPICS process control runtime database

 Channel Access client must  specify LANSCE timing, flavoring needed when subscribing  Channel Access service must  tag the data with LANSCE timing, flavoring attributes  Channel Access server must  Appropriately filter subscription updates  but …  This must be done in a generic way to allow parallel capabilities at other EPICS installations  Minimal to no impact on performance if the client does not request a filtered update stream  Within the IOC, record processing must not be disturbed by filtering activities in the server

 Filtering expression specified, as a string, when subscribing  The client side remains general purpose  Filter is specified as a CALC expression  Evaluates true, update sent to the client  Evaluates false, update suppressed for this client  No revolutionary changes in wire protocol  Only minor changes to client side tools  Service specified data types  Parameter name to application specific datum bindings  Parameter hierarchical sets  Service data is introspected using a generic interface  The IOC can remain general purpose

CA Server Record Event Queue Legacy Fixed Event Parameter Set Scalar Value Time Stamp Alarm Status Legacy Fixed Event Parameter Set Scalar Value Time Stamp Alarm Status Upgraded Record Specific Event Parameter Set Scalar or Vector Value Time Stamp Alarm Status … Upgraded Record Specific Event Parameter Set Scalar or Vector Value Time Stamp Alarm Status … Upgraded Device Specific Event Parameter Set LANSCE Beam Gate Specification Upgraded Device Specific Event Parameter Set LANSCE Beam Gate Specification

Record Event Queue Event Filter Discard Event Filter Expression value < 10.0 and value > log ( currentMonitor0007.current ) and requireFlavor ( beamGateA | beamGateB ) and excludeFlavor ( beamGateC ) Event Filter Expression value < 10.0 and value > log ( currentMonitor0007.current ) and requireFlavor ( beamGateA | beamGateB ) and excludeFlavor ( beamGateC ) TCP Circuit

 Catalog – implemented by users  Subordinate class in c++ or an interface in Java  Introspector – called by users class CatalogTelesopeCoordinate : public Catalog { public: CatalogTelesopeCoordinate ( MyData & ); void traverse ( Introspector & introspector ) const { introspector.reveal ( piRA, _refTC._rightAscension ); introspector.reveal ( piDecl, _refTC._declination ); } private: TelesopeCoordinate & _refTC; };

 Clerk – called by users  Library implements get  Throws an exception if source datum is out of range in destination datum’s primitive type TelesopeCoordinate telescopeCoordinate; CatalogTelesopeCoordinate catalogTelescopeCoordinate ( telescopeCoordinate ); Clerk clerk ( catalogTelescopeCoordinate ); Double rightAscension, declination; Clerk.get ( piRA, rightAscension ); Clerk.get ( piRA, declination );

 Guard  Takes Mutex in its constructor, releases it its destructor  Benefits  Exception safe Mutex release  Avoids locking overhead, locked API calls locked API  Mutable Guard can be temporarily released  Negatives  Guard reference argument, every function in the API  Not obvious, which Mutex used, which interface Guard guard ( this->_mutex ); caClient->createChannel ( Guard &, …);

 After, locking smart pointer  Smart pointer  Takes Mutex in its constructor, releases it its destructor  Benefits - essentially same as Guard, but …  One less argument passed to every function  Target tells us which Mutex is needed when it creates Ptr  Ptr has embedded Guard – often built efficiently using preexisting Guard reference (avoids recursive locking)  Negatives  Must carefully limit access to raw pointers, synchronized interfaces Ptr pService = createService (); pService->createChannel (…);

 Reference - used by the event queue to track references to 3 rd party Catalog used by each client’s event queue  Destruction of last reference causes automatic release notification to target Catalog  All accesses to target Catalog are synchronized  Have to create a locking smart pointer to receive access Ref refCatalog; { Ptr pCatalog = createCatalog (); refCatalog = pCatalog; } Ptr pCatalog = ref.release ();

 RefMgr - implemented by the library  Maintains, contains  The reference count  A pointer to Handle interface  One-to-one relation with instance of T  Handle interface  Implemented by author of T  One-to-one relation with instance of T template class Handle { public: virtual Ptr createPtr ( const Guard & ) = 0; virtual void release ( Guard & ) = 0; };

 Client directly invokes Service  Client library and Service implementation interfaces are one and the same  This is a low level interface designed to allow efficient, flexible implementations  All requests are completed via callbacks  Used only by programmers that prefer to have, need to have, more control  legacy, EZ, ultimate CA …  … this is layered value added  With a flexible low level interface we always get what we want  First corollary of API design  Its impossible to satisfy everyone’s needs with a simple, easiest-to-use high level interface

 Service – called by client Ptr createType ( Ptr & ); Ptr createChannel ( Ptr & );

 Channel – called by client Ptr = pChannel->createRequest ( Ident & method, Ptr & reqParmsType, Ptr & resParmsType );

 Request – called by client pRequest->initiate ( Ptr & responder, // callback interface Ptr & reqParms ); // request parameters

 Responder  Callback interface – called by service Ptr pCatalog ( guard, refMgr, myCatalogImpl ); pResponder->successNotify ( pCatalog ); pResponder->failNotify ( pCatalog );

 MagViz distinguishes potential-threat liquids from harmless shampoos and sodas screened at airport baggage checkpoints

 I am working on this project again since the start of the calendar year  The server and event queue changes are very close to completion  The next step, a Service snap-in for iocCore

 LANSCE style dynamic on-the-fly ad-hoc beam flavoring and beam timing experiments  But, in homogenous EPICS system  Tool based approach to LANSCE applications  Applications have abstract model of hardware  Incremental upgrades hopefully easier  Multi-element “Timed” data  COTS digitizer  Window in time selected

 Flexible event snapshots  Parameters other than alarm status, time stamp, scalar value correlated on event queue  Array update bursts buffered on event queue  Subscription update filtering  Expression (string) based means  Project and site independent – tool based approach  Minimally invasive for existing client side tools  Array index meta data  Expanding intersection of EPICS with data acquisition systems