request: new Kind value for "monitoring"

[wakonig]

Hello!

While there is a separation between signals that are important for the measurement ("normal", and "hinted"), configuration signals ("config") and those who should not be read out ("omitted"), it would be great to have another type: "monitor".

Especially for large detectors, it is sometimes required to provide a monitoring data stream, e.g. 2d frames at a reduced frequency. However, these signals should not be considered as relevant data for the file writer (normal / hinted), nor configuration data.

Therefore, I would propose to add a new type to Kind:

class Kind(IFBase):
    """
    This is used in the .kind attribute of all OphydObj (Signals, Devices).

    A Device examines its components' .kind atttribute to decide whether to
    traverse it in read(), read_configuration(), or neither. Additionally, if
    decides whether to include its name in `hints['fields']`.
    """

    omitted = 0b000
    normal = 0b001
    config = 0b010
    hinted = 0b101  # Notice that bool(hinted & normal) is True.
    monitor = 0b110

Would you be open for these changes? If so, I could prepare a PR.

[tacaswell]

This seems reasonable on first consideration, but we should think about if there is a better name. monitor collides a bit with the bluesky message Msg('monitor',....) and I worry that there could be assumptions that if you flag a signal as kind monitor it will be automatically monitored (and produce an additional data stream in the run).

This is something that down-stream tools can use to identify things they may want to set up subscriptions too (and possibly reduced rates)? Would this also be used for something like motor temperature or queue-size on an AD plugin? I could see wanted to flag those as "things to watch but you really don't want to write this down verbatim in the data stream".

Are there signals that may need to be both normal and monitor? I could see the case for that for most position-like values ("I want to write down what the temperature is / where the motor is in every event but also show the user a wiggly line of it moving in between measurements").

maybe "live_status" or "preview" might be better names?

[wakonig]

hmm, I never thought about using it for temperatures, I only had reduced data rates in mind. But you are right, calling it "live_status" could open it up to more use cases.

Regarding your use case for normal and (let's call it) live_status: I think if you can handle the entire data stream of a signal, you could simply add a subscription to it and plot the readback value, no? On every read event, you would still get a reading from both temperature and motor and in between you would see the live updates. However, I can see that a combination could make it more flexible and allow users to poll themselves instead of receiving data through callbacks.

[mguijarr]

maybe "live_status" or "preview" might be better names?

I prefer the new kind to be called "preview" - it indicates it is not meant for measuring, only for preview.

The implementation of the signal reading will have to deal with this kind - maybe it comes from EPICS auto-monitor, or maybe it comes from a zmq stream or whatever... I would not mix 2 different use cases in one signal.

Examples:

• for a 2D detector we could have an image signal with kind preview, it would give last frame (best effort) upon reading
• for a MCA, there would be a live_spectrum signal with kind preview, to show the accumulation while measuring
  • it would be different compared to spectrum with kind normal, for reading acquisition result

The name preview would clearly indicate it is for display or to follow progress, not to be used for processing or for saving.