Wrap plans and plan stubs with dictionaries #1734
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1734 +/- ##
==========================================
+ Coverage 99.09% 99.11% +0.01%
==========================================
Files 276 277 +1
Lines 10151 10351 +200
==========================================
+ Hits 10059 10259 +200
Misses 92 92 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
EmsArnold
force-pushed
the
wrap_plans_and_plan_stubs_with_dicts
branch
from
1cc044e to
daeb4ec
Compare
|
whatt else does this need until it can not be a draft and be merged? |
|
@RJCD-Diamond, it should be good to go, but could likely use some input on plan names and and other changes. |
|
Why did you go with |
|
DominicOram
left a comment
DominicOram
left a comment
There was a problem hiding this comment.
until spec_scan is stable and supports start stop step rather than start stop num
Does this mean you intend for these to be removed when bluesky/scanspec#186 is done? If so I would put a comment in each plan you intend to retire saying that it will be replaced and pointing to that issue.
Concurrent trajectory scans (scan, etc.) and independent trajectory scans (grid_scan, etc.) are both accessed through the same plan and differentiated by number of parameters given for each movable - similar to current GDA-style scans.
Is this a hard requirement? I think I would rather we have them separate as:
- We can then just point people to https://blueskyproject.io/bluesky/main/plans.html as documentation
- They seem to actually be quite different things and lead to weirdness e.g.
snake_axesmeaning nothing in some contexts
On that note, having different behaviour based on whether we provide a num for each axis or not is also not intuitive. Again, I would just stick to the bluesky way of being more explicit about what you actually want to do
| x_axis: Motor, | ||
| x_args: list[float | int], | ||
| ): | ||
| run_engine(num_scan(detectors=[det], params={x_axis: x_args})) |
There was a problem hiding this comment.
Should: It would be good to assert something here e.g. that the motor is moved the expected number of times or that the detector is read the expected number of times. Otherwise this is just a smoke test. Similarly with other tests in this file.
| params: Annotated[ | ||
| dict[Movable | Motor, list[float | int]], | ||
| Field( | ||
| description="Dictionary of 'device: paramater' keys. For concurrent " |
There was a problem hiding this comment.
Nit:
| description="Dictionary of 'device: paramater' keys. For concurrent " | |
| description="Dictionary of 'device: parameter' keys. For concurrent " |
There was a problem hiding this comment.
(Also in the rest of the file)
|
@EmsArnold Been using this for commissioning purposes on i22 - and strongly suggest we make sure that all of these plans stubs wait for the plan to finish by default |
Closes #1498, and as an alternative to #1702. Scan syntax is more similar to both GDA and bluesky.
Wraps bluesky plans (
scan,rel_scan,grid_scan,rel_grid_scan) and plan stubs (rd,stop) for use in blueapi. Intended as a replacement for gda-style start stop step scans until spec_scan is stable and supports start stop step rather than start stop num. Start stop step scans are achieved through generating a list for use withlist_scan,rel_list_scan, ...Concurrent trajectory scans (
scan, etc.) and independent trajectory scans (grid_scan, etc.) are both accessed through the same plan and differentiated by number of parameters given for each movable - similar to current GDA-style scans.Instructions to reviewer on how to test:
Checks for reviewer