Open untzag opened 1 year ago
I think the concept of display
, warning
, alarm
seem fairly well conserved.
When trying to expose in GraphQL in such a way that it worked for both EPICS protocols (Channel Access and PVAccess) I came up with this: https://github.com/dls-controls/coniql/blob/master/src/coniql/schema.gql#L179-L221
Channel Access fills them in like: https://github.com/dls-controls/coniql/blob/master/src/coniql/caplugin.py#L98-L113
Ophyd.v2 can do the same
Thanks as always for your careful response @coretl!
One possibility: standardize on a key like limits
or range
and then, within that have open-ended sub-keys, as in:
{
...,
"limits": {
"warning": [-5, 5],
"alarm": [-6, 6],
},
}
There might be general interest in adding "limit" or "range" information to
data_keys
in the event descriptor [1]. The primary goal is to have more intelligent defaults for live-plots and autogenerated post-processing.Ophyd v1 already does this [2] with their own special keys
lower_ctrl_limit
andupper_ctrl_limit
.data_keys
object in the schema supports arbitrary additional properties (items) I guess this is a JSON schema default.See @ddkohler's issue against YEPS [3]. The Wright Group has a long-standing concept of data being "signed". Seems like this behavior could be captured by special cases of range for their purposes.
signed
range
False
(-inf, +inf)
True
(0, +inf)
We could have multiple range types perhaps. Display range, alarm range, warning range, control range. What do existing systems do?
lower_ctrl_limit
upper_ctrl_limit
get_max_value
get_min_value
is_min_warning
is_max_warning
is_min_alarm
is_max_alarm
get_limits
[1] https://github.com/bluesky/event-model/blob/master/event_model/schemas/event_descriptor.json [2] https://github.com/bluesky/ophyd/blob/master/ophyd/signal.py#L1469-L1470 [3] https://github.com/yaq-project/yeps/issues/15