Base Classes

pcdsdevices.Device looks for a keyword db_info upon instantiation. This captures keyword information that come from the happi databae and saves it underneath the db attribute as HappiData.

class pcdsdevices.device.HappiData(db_info)

Class to hold arbitrary happi data

The information is stored as attribute with the name corresponding to the key given in the input dictionary. Dictionary-like access is still possible by using db_info

Loading from happi

There are a few helper functions in pcdsdevices that facilitate loading from happi

pcdsdevices.happireader.read_happi(client=None)

Connect to the happi database and return a list of all devices.

Parameters:client (happi.Client, optional) – Instance of Client to use for the read. Included as a parameter to be substituted with the mock client for testing. If not provided, we’ll use the default client.
Returns:devices
Return type:list of happi.Device
pcdsdevices.happireader.construct_device(happi_object, device_class=None, info_map=None, **kwargs)

Create a functional device from the information stored in a happi device.

Parameters:
  • happi_object (happi.Device) –
  • device_class (class, optional) – Class to instantiate with given happi information. If no class is given one will be selected using the pick_class() function
  • info_map (dict, optional) – Rename happi information to match Device keywords. Conversion from info name to keyword should be entered as happi info name -> device kwarg name pairs
  • kwargs – Additional keywords are passed into the device constructor
Returns:

device
Return type:

ophyd.Device

MPS Information

Devices that are integrated with the MPS system communicate with ACR via a single bit summary. The results of these are published over EPICS and interpreted by MPS.

class pcdsdevices.epics.MPS(prefix, *, name=None, veto=False, read_attrs=None, **kwargs)

Class to interpret MPS information

The intention of this class is to be used as a sub-component of a device. There are three major attributes of each MPS bit that are relevant to operations; faulted , bypassed and veto_capable. The first is the most obvious, when the device is faulted it reports as such to the MPS system. However, how this is actually interpreted by the MPS is determined by whether the bit is bypassed, and if there is a veto device upstream such that the fault can be safely ignored. The bypassed state is reported through EPICS as well but unfortunately whether a device is considered capable of “veto-ing” or is vetoed by another device is not broadcast by EPICS so this is held within this device and the lighpath module

Parameters:
  • prefix (str) –
  • name (str, optional) –
  • veto (bool, optional) – Whether or not the
  • read_attrs (list, optional) –
bypass

Component attribute

Component(EpicsSignal, '_BYPS')
fault

Component attribute

Component(EpicsSignalRO, '_MPSC')