search

bluesky / bluesky-enhancement-proposals

0 stars 4 forks source link

Implement an overall progress bar for an entire plan. #2

Open danielballan opened 7 years ago

danielballan commented 7 years ago

Notes on a conversation with @awalter-bnl:

It would be useful to display a progress bar that estimates how long until plan execution will be complete. The progress bar feature just added addresses an orthogonal need: it works on one 'wait' message at a time, tracking one or more motors as they move or detectors as they trigger. This is useful for checking what the holdup is if a plan seems to be hung. And, of course, this can be used to estimate how long the overall plan will take. But an overall progress would still be a nice thing to provide.

And on a conversation with @tacaswell:

To support such as progress bar, plans would need to provide more information about what they are going to do in advance. In order to support adaptive plans, the RunEngine intentionally knows little or nothing about what the plan will do in the future. Plans could announce their intentions in advance through a new message type like Msg('progress', itinerary=...) and provide occasional updates like Msg('progress', status=...). This gets tricky when plans nest. A plan composed of many shorter plans would have to have a way of explaining its composition to the RunEngine.

danielballan commented 7 years ago

Stray thought: a simple way to do this now and be right 90% of the time would involve RemoteDispatcher, tqdm, and total=start.get('num_points').

awalter-bnl commented 7 years ago

So just a quick pint from my end. This does not need to be perfectly accurate. In fact I think that for adaptive scans it will always be somewhat less reliable.

So I would just use the process Dan has mentioned which is close most of the time and gets more accurate the further into the scan you get. This is enough to let the user know a rough eta for the end of the scan which is all that is needed.

Cheers Andrew

Sent from my iPhone

On 20 Aug 2017, at 12:56 pm, Dan Allan notifications@github.com<mailto:notifications@github.com> wrote:

Stray thought: a simple way to do this now and be right 90% of the time would involve RemoteDispatcher, tqdm, and total=start.get('num_points').

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NSLS-II/bluesky/issues/776#issuecomment-323597491, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYlCpYAll0vv3d457AuLGx0appAwbY8jks5saGVDgaJpZM4O8W4Z.

danielballan commented 7 years ago

Thanks, @awalter-bnl. We'll take this idea for a spin at ESM when we visit to upgrade the software.

awalter-bnl commented 6 years ago

Any update on this?

danielballan commented 6 years ago

This can be done using existing tools -- no changes to bluesky needed. I will write up an example tomorrow.

awalter-bnl commented 6 years ago

I had forgotten that @danielballan had already a base idea to use for this, once he is back I will discuss with him. For plans with multiple 'yields' inside them we could probably couple with #713 (time for scan compelte) to get an eta (without progress bar) at the end of each 'yield'.

thoughts?