1 / 20

Server-Side Plugins

Server-Side Plugins. Andrew Johnson, Ralph Lange EPICS Fall Collaboration Meeting, October 2010 BNL. Motivation. Things get faster Not all clients want all updates Wide use of timing/event systems Clients want to get updates only during “interesting” system states. Current Limitations.

amelie
Download Presentation

Server-Side Plugins

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. Server-Side Plugins Andrew Johnson, Ralph Lange EPICS Fall Collaboration Meeting, October 2010 BNL

  2. Motivation • Things get fasterNot all clients want all updates • Wide use of timing/event systemsClients want to get updates only during “interesting” system states

  3. Current Limitations • Update rate / deadband are configured in the databaseOne setup for all clients • Existing timing/event system driver and support • May cause records to process on event • May set time stamps from hardware No filtering of updates for unrelated records

  4. Design Considerations • Channel Access protocol compatibilityChanges create a lot of trouble • ModularitySmall systems need small footprint • API CompatibilityDon’t break existing “3rd party” code

  5. Server-Side Plugins Channel Access Client 1 Channel Access Client 2 Client Event Task 1 Event Task 2 • Stackable modules Inserted below or above the event queue between database and Channel Access server • Configuration and Instantiation Client uses JSON modifiers in PV name Plug-in framework parses configuration and calls filter function Ethernet IOC Channel Access Server Post-Event-Queue Filters EventQueue EventQueue EventQueue ring buffer ring buffer ring buffer One set of event queues per client Event Subscriptionfield 2flags Event Subscriptionfield 1flags Event Subscriptionfield 1flags Event Subscriptionfield 3flags Record processing or field changes cause event updates Pre-Event-Queue Filters Record MLISfield 1 field 2field 3…

  6. Plugin Integration • Plugin registers its interface (at boot-up): • Name and interface (jump table) • Filter function (and private pointer argument) to be inserted into the pre- or post-event-queue chain • Description of the configuration options and config value locations • Framework • Creates the plugin instance • Parses the configuration and stores results • Calls the registered filter function when appropriate

  7. Plugins May • Manipulate the data • Manipulate the meta data (alarm, timestamp) • Change the type of data • Change the size of arrays • Drop updates • Insert updates

  8. ts – Timestamp “Now” myPv.A{”ts”:{}} • Pre-event-queue: Sets the timestamp of the data update to “now” • Works around the issue that updates to fields which do not cause record processing create data updates that always show the (older) record timestamp, leading to e.g. the archiver creating wrong entries

  9. dbnd – Deadband Throttling myPv.RVAL{”dbnd”{”m”:”rel”,”d”:7.5}} • Pre-event-queue: Deadband throttling similar to analog records • Client specifies absolute or relative (%) delta • Works for any field, not just .VAL

  10. arr – Array Subset myArray.VAL{”arr”:{”s”:-5,”i”:2}} myArray.VAL[-5:2:] • Post-event-queue: Creates a sub-array with given start, increment, stop • Shorthand notation for commodity

  11. sync – Sync with Timing System myPv.VAL{”sync”:{”m”:”while”,”s”:”red”}} • Pre-event-queue: Synchronizes updates with timing system by pushing the update only under certain conditions • Refers to IOC globally configured named states that are defined by timing system events

  12. sync Options Client subscribes to my.VAL Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  13. sync Options: before Client subscribes to my.VAL{”sync”:{”m”:”before”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  14. sync Options: first Client subscribes to my.VAL{”sync”:{”m”:”first”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  15. sync Options: last Client subscribes to my.VAL{”sync”:{”m”:”last”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  16. sync Options: after Client subscribes to my.VAL{”sync”:{”m”:”after”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  17. sync Options: while Client subscribes to my.VAL{”sync”:{”m”:”while”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  18. sync Options: unless Client subscribes to my.VAL{”sync”:{”m”:”unless”,”s”:”red”}} Client gets Record my processing State “red” Timing events #17 #42 #17 #42

  19. Status • Framework in place, interfaces stabilizing • ts, dbnd, arrplugins: implemented • Unit tests for framework and plugins exist • sync plugin: in progress • Next: rate based throttling • Planned: atomic put/get, array stats,default configuration values through info tags

  20. Status • Unclear: access security integration • Code is available (please give feedback):lp:~ralph-lange/epics-base/server-side-plugins • Acknowledgements: • Michael Davidsaver • Supported by Helmholtz-Zentrum Berlin / BESSY II

More Related