-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
range in data_keys
#229
Comments
I think the concept of |
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: |
Channel Access fills them in like: |
Ophyd.v2 can do the same |
Thanks as always for your careful response @coretl! |
One possibility: standardize on a key like {
...,
"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] yaq-project/yeps#15
The text was updated successfully, but these errors were encountered: