Add new status to FrameType

[decarlof]

Currently PV: ioc_prefix + cam1:FrameType stores:

\exchange\data \exchange\data_dark \exchange\data_white

I think setting this to None at the end of the bluesky data collection can be useful to notify the streaming subscribers that the data stream has completed as data set collection. This way the continuous data collection used for example for sample alignment will not be interpreted as data stream to reconstruct.

[tekinbicer]

We discussed an alternative way to accomplish this at yesterday's MONA meeting.

Nicholas proposed we can use a seperate flag/PV (e.g. ProcessingState?) to reset the data analysis workflow (instead of using FrameType PV), so that other beamlines/imaging techniques can also use it. @prjemian : Does this make sense?

A question: Is it always the case that the first image/data that comes from the detector is the last acquired image/data from the last experiment? Is this true for all beamlines/experiments?

[decarlof]

@prjemian we are ready to implement the streaming in production mode at 2-BM. I think all components are in place except the PV to flag the processing state so when a new sample starts to be measured the streaming restarts. For more technical details please reach @tekinbicer

[prjemian]

We can create a separate PV (mbbo record type) for this purpose. Is it a property of the detector, the instrument, or some other? By using (hijacking) the FrameType PV, we assume it is a property of the detector.

To be backwards compatible with what we have been using, I propose we add this new setting to the next available mbbo position, mbbo position 3. These might be the new values. The string text (None) for the new value was taken from the original issue statement above. The bluesky code will operate with the numerical value.

mbbo position	number	text
0	0	\exchange\data
1	1	\exchange\data_dark
2	2	\exchange\data_white
3	-1	None

The HDF5 file writer will use the text from this PV as an HDF5 address to which the current image data will be written within the HDF5 file. We'll need to test what happens for the new case and make sure it does not cause troubles with any acquired data.

@tekinbicer : Can we look at this tomorrow (Thursday, 11/29)?

[prjemian]

EPICS database content (here, ~$(P)` is the PV prefix to be used, we'll figure that out based on discussion from my previous comment):

record (mbbo, "$(P)ProcessingState") {
    field(DESC, "data analysis workflow: HDF5 address or 'None'")
    field(ZRST, "\exchange\data")
    field(ONST, "\exchange\data_dark")
    field(TWST, "\exchange\data_white")
    field(THST, "None")
    field(THVL, -1)
}

[tekinbicer]

@tekinbicer : Can we look at this tomorrow (Thursday, 11/29)?

@prjemian Sorry for the late comment, I just saw this. Can we talk about it this Thursday or Friday? I have couple of questions on how to use this.

[prjemian]

today's discussion:

We decided we want a different PV and will leave the FrameType PV unchanged. The new PV (ExperimentState) will describe the current state of the experiment. It needs a few different values:

• idle (no activity)
• initializing (starting the experiment, could produce empty frames, can get frame size and other metadata, also means to clear the computational pipeline)
• frame_other (dark, white, bright, furry, ...)
• frame_image (the data that we want to process)
• acq_done (acquisition complete)

[prjemian]

mbbo position	number	text
0	0	idle
1	1	initializing
2	2	frame_other
3	3	frame_image
4	4	acq_done

The PV will be defined in the 2bmbmona softIoc using this definition:

record (mbbo, "$(P)ExperimentState") {
    field(DESC, "state of experiment")
    field(ZRST, "idle")
    field(ONST, "initializing")
    field(TWST, "frame_other")
    field(THST, "frame_image")
    field(FRST, "acq_done")
}

[prjemian]

example

(base) user2bmb@lyra ~/ioc/2bmbmona $ caget 2bmbmona:ExperimentState
2bmbmona:ExperimentState       idle