With the aim of making a beamline ec repository document the capabilities and state of a beamline.
A Beamline is composed of multiple levels:
Physical components (motors, detectors, other hardware): how well do these map to Resource entities? With potential dependency chains to explain device interactions (e.g. temperature controller A requires pump B, or stage C is a dependency of detector D that is mounted to it?). Resources only allow one string of spec.type, does this allow a useful level of device granularity when defining beamline capabilities?
Can a device be suitably defined by some agreed upon standardised fields, something like this?
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: stage-y
namespace: p45 # Prevents name having to be globally unique
description: Make, model
tags: # Some useful common definition of hardware capabilities? Or as labels, or as annotations?
- axis_physical
- axis_vertical
- axis_limited # Provides axis_max, axis_min labels?
labels: # Labels are
axis_max: xxx
axis_min: xxx
axis_precision: xxx
annotations: # How Panda TTLOUT are wired to device external triggers?
input.p45.panda1.ttlout: 1
input.p45.panda2.ttlout: 1
spec:
type: axis
dependsOn:
- resource:p45/stage-x # mounted on top?
owner: p45 # Is owner p45 or controls engineer or?
# system: # Define a Controls system for the hardware, IOCS?
IOCs that control the physical components- are these Components, with dependencies on the physical components (if those are Resources, these can be Components fairly simply)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: stage-y
namespace: p45
description: IOC controlling stage-y Resource
spec:
type: IOC
lifecycle: production
owner: user:JoeBloggs # Controls engineer for p45?
# system: Controls # Define a Controls system for the hardware, IOCS?
dependsOn:
- resource:p45/stage-y
providesApis:
- EPICS-CA # Define how to talk to the device?
- # Can we generate an API from pvinfo/PVI/cainfo?
Central or Beamline services (from acquisition, analysis or controls): Components, which may also contribute to a System, such as the Athena system.
Does a Beamline consist of a System, or only the components that belong to the system that are enabled for it?
A Component can only be part of one System, so cannot readily have a Beamline defined as a System (components exist on multiple beamlines, and may already be a part of a System).
Suggested schema for Beamline-level object
apiVersion: # Diamond apiVersion string
kind: Beamline
metadata:
name: p45
namespace: p45 # may have multiple beamlines in same namespace if share resources
description: P45 Test rig, configured with x, y, theta stage, det, diff cameras, white light and monochromatic laser.......
spec:
lifecycle: production
owner: user:JoeBloggs # Multiple responsible persons?
services:
- p45-specific-service
- stage-y # ioc
centralServices:
- central-service-being-made-use-of
DiamondJoseph
commented
3 months ago
With the aim of making a beamline ec repository document the capabilities and state of a beamline.
A Beamline is composed of multiple levels:
Physical components (motors, detectors, other hardware): how well do these map to Resource entities? With potential dependency chains to explain device interactions (e.g. temperature controller A requires pump B, or stage C is a dependency of detector D that is mounted to it?). Resources only allow one string of
spec.type, does this allow a useful level of device granularity when defining beamline capabilities?Can a device be suitably defined by some agreed upon standardised fields, something like this?
IOCs that control the physical components- are these Components, with dependencies on the physical components (if those are Resources, these can be Components fairly simply)
Central or Beamline services (from acquisition, analysis or controls): Components, which may also contribute to a System, such as the Athena system.
Does a Beamline consist of a System, or only the components that belong to the system that are enabled for it? A Component can only be part of one System, so cannot readily have a Beamline defined as a System (components exist on multiple beamlines, and may already be a part of a System).
Suggested schema for Beamline-level object