1 / 18

Malcolm Middleware at Diamond

Malcolm Middleware is a layered approach to data acquisition control at Diamond. It replaces specific scripts with reusable components shared across beamlines, allowing for distributed objects and inter-process communication. This text discusses the current state of Malcolm, its middleware layers, Blocks, Attributes, Methods, and Messages, as well as the ongoing development of the EPICS V4 framework for Malcolm.

robinrodriguez
Download Presentation

Malcolm Middleware at Diamond

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. Malcolm Middleware at Diamond Dave Hickin EPICS V4 Collaboration Meeting, SNS 21/09/2016

  2. Why is it called Malcolm?

  3. Named after “Malcolm in the Middle”

  4. Current Data Acquisition • Currently data acquisition at Diamond done through GDA: • Clients talk CORBA to GDA server • GDA Server controls devices using CA • Large collection of scripts/code (Java/Jython), mostly specific to one beamline

  5. Malcolm middleware project • Replace some of this with Malcolm middlelayer • Layered approach • Reusable components shared across beamlines • Distributed objects • Objects in same process call each others functions • Proxy objects used for inter-process communication • pvAccess for remote comms • Implementing in Python

  6. Malcolm Middleware Layers

  7. Manager State Machine

  8. Malcolm Process • Process: • Malcolm instance containing a number of Blocks • modules to communicate with other Malcolm instances • Blocks: • Exist in one or more processes with same API • One server process contains logic • Synchronized between processes via remote comms

  9. Blocks • Blocks: • Consist of a number of Attributes and Methods. • Small and self contained • Complex logic through nesting Blocks: • Examples: • Lower-level: Detector driver, HDF writer blocks • Higher-level: Detector Block co-ordinates the low-level blocks.

  10. Attributes • Attribute: • Holds value of fixed type: • Float, String, Integer Array. Enum. Table • Get and subscribe to changes in all attributes, and put to writable attributes • Client blocks mirror values in server block • Examples: • State of a block • Current step of a scan

  11. Methods • Methods: • Expose a function call • Call with map of arguments and are returned a map of return values • In server block local function is called • In a client block, the call will be forwarded to the server block, and the return value returned to the caller • For example, configure() and run() would be methods of a blocks used in a mapping scan

  12. Messages Passing messages between blocks: • Same Process: passing Python dictionaries to each other’s input queues • Different processes: serialization + transport protocol is needed • JSON serialization over websockets /ZeroMQ • pvData/pvAccess

  13. Messages • Client messages: • Get, Put • Post (method call) • Subscribe/Unsubscribe • Server messages: • Return • Error • Update/Delta

  14. pvAccess Comms If block doesn’t exist in process: • Do pvAccess channel find and create channel • Use introspection to find methods and attributes • Use monitors to synchronize state • Use puts to write attributes • Use RPC to call methods

  15. pymalcolm Python implementation of Malcolm • Basic infrastructure developed • Process, Block, Attributes, Method • Remote comms in development: • Gets, Puts and RPC • Development of coordination and device layers planned over next couple of months

  16. EPICS V4 Development for Malcolm • Channel provider (very alpha) • pvaPy: Added local channel connecting to Python objects using boost Python • pvLocalCPP: Local channel framework C++ • Channel find, create and destroy • Channel Get and Put (first cut) and RPC • Working on Put and Monitor • Added RPC to pvDatabase

  17. EPICS V4 Development for Malcolm • Enhanced RPC client libraries • Support multiple services on single channel • C++/Java/Python • Added examples to C++ and Java modules • Marty Kraimer added RPC to pvaClient • Added type IDs to pvaPy

  18. pymalcolm Team • Malcolm architecture: Tom Cobb, Matt Gerring • Malcolm infrastructure: Tom Cobb, Charles Mita • Remote comms: Alan Greer (Observatory Sciences) • pvAccess infrastructure: Dave Hickin • GDA Clients: Matt Taylor, Matt Gerring

More Related