bluesky / bluesky-enhancement-proposals

0 stars 4 forks source link

Pass each Msg to each Suspender to ask permission to proceed #1

Open danielballan opened 7 years ago

danielballan commented 7 years ago

This proposes a major rethink of Suspenders that makes them more flexible. It allows them to trip only if the user tries to do particular things. If the user is changing the temperature while the beam is dumped, that should be allowed. If the user is trying to trigger a CCD, that should cause suspension.

The interface between RunEngine and suspenders changes to something like:

class RunEngine:
    def _run(plan):
        for msg in plan:
            for sus in self.suspenders:
                status = sus.check(msg):
                if status is not None:
                    # Suspend! This status object will complete when it's safe to continue.
            # We're good to go. Process the message.
danielballan commented 7 years ago

This is marked for "bluesky release N+1" but I would like to suggest that we try to get it into 0.11 (not 0.10 though!). Two NSLS-II beamlines are bumping against limitations in our current model for suspenders, and this would address them as well as massively simplify the RunEngine internals. I think I have it all in my head. We'll see what devils lurk in the details....

tacaswell commented 7 years ago

https://github.com/NSLS-II/bluesky/pull/541 also takes a stab at this. The main idea there is that while processing the pre/post plans of suspender (A) you should not ask any other suspenders if thy would like to suspend things or you get weirdly collated results where the pre and post plan of the second suspender to trip run in the middle of the pre plan of the first

if plans (A, B) and (C, D) for (pre, post) for two suspenders you will see ``` A1 A2 C1 C2 C3 wait(suspender 2) D1 D2 D3 A3 wait(suspender 1) B1 B2 B3 ```

The attempt in #541 was to refactor the _run co-routine to run the pre/post plans in their own, un-suspendable, contexts.

I suspect the proposed design will make addressing this intercolation issue much simpler (just don't ask!)

danielballan commented 7 years ago

Yes, I think that is true.

danielballan commented 5 years ago

When approaching this, we should make sure to provide a path for this use case.

prjemian commented 5 years ago

What happened with this issue?

danielballan commented 5 years ago

I still think this is a good idea. Once #1125 is in (and it's close, just two tests left I think) it will be easier.

danielballan commented 5 years ago

The design of this probably needs a Bluesky Enhancement Proposal to sort out.