Use metadata from DB records to populate DataKeys

[DiamondJoseph]

No description provided.

[coretl]

A couple of minor things, please could you make a ticket for doing the same for the PVA side so we get this in PandA too?

[coretl]

@danielballan do we want all these to appear in the descriptor document?

[DiamondJoseph]

I'm happy to turn down to just units, precision. Currently for my downstream purposes I turn lower_ctrl_limit into soft_limit_min for NeXus, so if we can keep just one that's the one I want.

[danielballan]

Only units and precision are blessed in the schema, but IIRC the schema is open-ended (additional properties allowed) so you can add any that you need.

[danielballan]

Confirmed: https://github.com/bluesky/event-model/blob/9cbcaba7db476d6748e74283532dd86469e60908/event_model/schemas/event_descriptor.json#L30-L109

[DiamondJoseph]

So:

1. add everything and filter what is required downstream
2. just control_limits as is more meaningful than alarm/display/warning
3. no limits: isn't actually describing the data, but the device's limits and should be somewhere in device configuration?

I'm leaning towards 3: the DataKey is a Key to the Data. It requires a source, but otherwise does it really benefit from knowing the limits? They should be instead kicked up to the device and plan rather than data and documents

[coretl]

PVA also defines the same set of limits:

• display.limitLow and display.limitHight
• control.limitLow and control.limitHight
• valueAlarm.lowWarningLimit, valueAlarm.lowAlarmLimit, valueAlarm.highWarningLimit, valueAlarm.highAlarmLimit

The question here is what is useful downstream.

• If I am capturing a diode PV, do I want the display limits that would be used as axis ranges for plotting?
• If I am capturing a furnace setpoint PV, do I want the control limits that show I was close to the maximum temperature the device accepts?
• If I am capturing a thermocouple PV, do I want the warning or alarm limits to show that the sample was melting?

For that last point, we currently capture severity with each value, but we questioned the usefulness of that as maybe the scan should abort if the sample got too hot?

[DiamondJoseph]

CA	PVA
lower_alarm_limit	valueAlarm.lowAlarmLimit
upper_alarm_limit	valueAlarm.highAlarmLimit
lower_ctrl_limit	control.limitLow
upper_ctrl_limit	control.limitHigh
lower_disp_limit	display.limitLow
upper_disp_limit	display.limitHigh
lower_warning_limit	valueAlarm.lowWarningLimit
upper_warning_limit	valueAlarm.highWarningLimit

Presumably the correct equivalents?
Do we want to do some mapping to either/both to get something consistent?

[coretl]

Yes, I think we should map both to the same, then add them to event model as optional.
However I only think we should do this for the useful fields...
@danielballan which fields do you think are useful?

[coretl]

How about we have nested objects, so:

• limits.control.low and limits.control.high
• limits.display.low and limits.display.high
• limits.warning.low and limits.warning.high
• limits.alarm.low and limits.alarm.high

[DiamondJoseph]

[...] make a ticket for doing the same for the PVA side [...]

Captured as #146

[DiamondJoseph]

Replaced by #367