Bluesky provides a progress bar add-on. For example, two motors moving simulateously make a display like this:
mtr1 9%|███▊ | 0.09/1.0 [00:00<00:01, 1.21s/deg] mtr2100%|████████████████████████████████████████████| 1.0/1.0 [00:01<00:00, 1.12s/deg]
This display includes:
the name of the device (motor, temperature controller, etc.)
the distance (or degrees, etc.) traveled so far
the total distance to be covered
the time elapsed
the estimated time remaining
the rate (determined empirically)
The progress bar relies on the device to report its progress. If a device does not provide comprehensive information, a simpler progress bar will be shown, listing the names of devices being waited on and reporting which have completed.
mtr1 [No progress bar available.] mtr2 [Complete.]
Any time the RunEngine waits on hardware the progress bar is notified. This includes, for example, waiting for a motor to move or waiting for a detector to trigger. (In bluesky jargon, the progress bar is notified any time the RunEngine processes a ‘wait’ command).
The progress bar is not set up by default. It must be attached to a RunEngine. This need only be done once (say, in a startup file).
from bluesky.utils import ProgressBarManager RE.waiting_hook = ProgressBarManager()
Some motions are very quick and not worth displaying a progress bar for. By
default, a progress bar is only drawn after 0.2 seconds. If an action completes
before then, the progress bar is never shown. To choose a shorter or longer
delay—say 5 seconds—use the parameter
For more technical detail about communication between the device, the
RunEngine, and the ProgressBarManager, read about the
watch method in the
Status object and
waiting_hook in the RunEngine API Documentation.
The implementation of the progress bar itself makes use of tqdm, a lovely Python package for making a progress bar out of any iterable.