Open tacaswell opened 5 years ago
The main use case I have had described to me is a check that the plan has no errors, performs the expected steps and will run.
The last one here is the tricky one, but something along the lines of “print_summary” and “check_limits” in one is a good start.
But to be honest I think this will be a constantly moving target, as users will always find more “error conditions “ they will want to check against.
I agree with this. Check limits is important to include HKL as this is often the only way to check.
The other question to think about is how will relative scans work? Right now, someone that doesn't know better will see the output from plan_summary() and think that they have done something wrong so the alter the parameters until satisfied with print_summary() output and then RE() that plan to see if fail or do something really crazy.
Aside from this, are input files if that is something you want to support for future applications? More for future proofing and not an immediate requirement.
It is probably also good to make counting times explorable for the various detectors and to include information about the monitor stream. Users are accustomed to spec so they do not realize that they should alter counting times for the detector used for normalization.
The primary plan previewer currently being used (to my understanding is
print_summary
) which is pretty verbose (every move and trigger/read). Aside from time estimation (which is it's own thing), what do people want to see in a 'plan previewer'? What are the use-cases?Text
list(plan)
[ts_msg_hook(m) for m in plan()];
len([m for m in plan() if m.command == 'start'])
GUI
We have had a draft of a GUI plan explorer floating around for a while: https://github.com/bluesky/bluesky/pull/626