1 / 23

CA Server Subscription Filtering in EPICS R3.15

CA Server Subscription Filtering in EPICS R3.15. Jeffrey O. Hill LANSCE / LANL. Outline. Requirements, a review Design, a review Application Programming Interface (API) Status Benefits, a review. Requirements – LANSCE Needs. LANSCE timing and flavoring of data Flavoring

naava
Download Presentation

CA Server Subscription Filtering in EPICS R3.15

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CA Server Subscription Filtering in EPICS R3.15 Jeffrey O. Hill LANSCE / LANL

  2. Outline • Requirements, a review • Design, a review • Application Programming Interface (API) • Status • Benefits, a review

  3. Requirements – LANSCE Needs • 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

  4. Requirements – LANSCE Needs • 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

  5. Requirements – Client Decides • 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

  6. Design • 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

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

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

  9. API -Data Access • 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; };

  10. API Changes -Data Access • Clerk – called by users • Library implements get • Throws an exception if source datum is out of range in destination datum’s primitive type TelesopeCoordinatetelescopeCoordinate; CatalogTelesopeCoordinate catalogTelescopeCoordinate ( telescopeCoordinate ); Clerkclerk ( catalogTelescopeCoordinate ); Double rightAscension, declination; Clerk.get ( piRA, rightAscension ); Clerk.get ( piRA, declination );

  11. API Changes -Before, Guard Reference Passed • 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 &, …);

  12. API Changes -After, Locking Smart Pointer • 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 < Service > pService = createService (); pService->createChannel (…);

  13. API Changes -Lifetime and Reference Counting • Reference - used by the event queue to track references to 3rd 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 < const Catalog > refCatalog; { Ptr < const Catalog > pCatalog = createCatalog (); refCatalog = pCatalog; } Ptr < const Catalog > pCatalog = ref.release ();

  14. API Changes -Lifetime and Reference Counting • RefMgr < T > - implemented by the library • Maintains, contains • The reference count • A pointer to Handle < T > interface • One-to-one relation with instance of T • Handle < T > interface • Implemented by author of T • One-to-one relation with instance of T template < class T > class Handle { public: virtual Ptr < T > createPtr ( const Guard & ) = 0; virtual void release ( Guard & ) = 0; };

  15. API Changes, Client directly Invokes Service • 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

  16. Programming Interfaces -Channel Access • Service – called by client Ptr < Type > createType ( Ptr < const Catalog > & ); Ptr < Channel > createChannel ( Ptr < const Catalog > & );

  17. Programming Interfaces -Channel Access • Channel – called by client Ptr < Request > = pChannel->createRequest ( Ident & method, Ptr <Type > & reqParmsType, Ptr < Type > & resParmsType );

  18. Programming Interfaces -Channel Access • Request – called by client pRequest->initiate ( Ptr < Responder > & responder, // callback interface Ptr < Catalog > & reqParms ); // request parameters

  19. Programming Interfaces -Channel Access • Responder • Callback interface – called by service Ptr < Catalog > pCatalog ( guard, refMgr, myCatalogImpl ); pResponder->successNotify ( pCatalog ); pResponder->failNotify ( pCatalog );

  20. Status, MAGVIZ, my Full Time Project Last Year + 2 Months Before • MagViz distinguishes potential-threat liquids from harmless shampoos and sodas screened at airport baggage checkpoints

  21. Status, This Project • 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

  22. Benefits for LANSCE • 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

  23. Benefits for EPICS Community • 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

More Related