Control dark frames / white fields in Message API

[danielballan]

Dark frames and white fields could be taken adaptively: if the beam current changes too much, take a new white field.

[tacaswell]

This requires possible breaking upstream changes to @stuwilkin ad code to pull the dark frame logic out of ophyd subscriptions and into explicit methods on the ad objects.

[danielballan]

Current proposal for a more flexible area detector, as hashed out in scattered, separate conversations with @tacaswell, @ericdill, @stuwilkins.

Remove dark frame logic from base class. The basic AreaDetectorFileStore or whatever doesn't need to know anything about dark frames. Its trigger method simply takes a frame. It does not manipulate a shutter. This aims to cater to users who (1) have no need for dark frames or (2) prefer to think of the shutter separately, not wanting their objects to get too smart. :- )

A dark-frame-aware subclass would inherit from this. It would hold a reference to a Shutter (which joins Readable and Movable as a defined interface in bluesky) -- an ophyd obj with open and close methods proposed elsewhere by @tacaswell.

As now, it would have a trigger method that always takes a light frame and sometimes takes a fresh dark frame. Here's the difference: an attribute (say, darkframe_is_stale) would control whether the next trigger takes a new darkframe. This is more flexible than darkframe_interval. As now, the read method would always returns a new light frame and most recent dark frame. In summary, it still has brains, but the procedure for how to intersperse dark frames is not baked in.

A further subclass could implement darkframe_interval that touches darkframe_is_stale.

If all the darkframe logic is implemented as a mixin class, it can be kept separate from hardware details. That is, you can have Eiger and EigerDarkFrame and EigerDarkFrameThatKnowsAboutIntervals without repeated code.

[danielballan]

@dchabot

[tacaswell]

attn bluesky/ophyd#165