Ophyd

Ophyd represents hardware in Python as hierarchical objects grouping together related values from the underlying control system. This structure allows ophyd to provide

• A consistent high-level interface across a wide-range of devices ( which is used by bluesky).
• Direct low-level access to the underlying controls system for debugging and development.

By presenting a uniform interface experimental plans can be agnostic to the details of the underlying hardware which simplifies writing experimental plans. For example, every device has a read method which, somewhat tautologically, reads the device. It is up to the object to have an understanding of which of its signals are interesting and should be included in the reading, to reach out and fetch those values, and then to format them into a consistent format. Similarly, if a device can be ‘moved’ (in the most general sense) then it must provide a set method which is responsible for knowing how to translate the user input into values that the control system understands, setting those values, and then returning to the caller an object which will signal when the requested move is complete. This provides a direct way to implement software pseudo motors.

ophyd contains a number of pre-built devices for common hardware (and IOCs) as well as the tools to build custom devices.

Currently ophyd only support EPICS via pyepics (because it is what we use at NSLS-II), however the library is designed to be control-system agnostic and we are looking for a partner to port it to other control systems.

Standard Devices

• Ready-to-Use Devices
  • EpicsMotor
  • EpicsScaler
  • EpicsMCA and EpicsDXP
  • MotorBundle

Signals and Devices

• Architecture
• Device and Component
• Positioners
• Signals
• Status Objects
• Area Detectors
• Debugging and Logging

Developer notes

• Release History
• Ophyd Enhancement Proposals
• Docker setup

API

• API