Flyscanning Tutorial #22
Conversation
| @@ -0,0 +1,29 @@ | |||
| class JSONWriter: | |||
There was a problem hiding this comment.
For this purpose we sometimes use jsonlines because it is stream-able. Consider whether that would be a good fit here.
The main selling points are:
- You can stream the file into processors, like with a generator, without parsing the whole thing up front.
- You can parse a partially-written file during a scan.
There was a problem hiding this comment.
Thans, Dan! I think jsonlines is actually what was there initially (I am using the piece of code you have written during one of my first days here when you were explaining Bluesky to me). As far as I remember, I had some difficulties with opening jsonl with VS code or maybe it didn't format it correctly (probably I just needed to install another extension), but it worked with json. I like the selling points though!
On this note, do you think it would make sense to add these callbacks to Bluesky directly?
There was a problem hiding this comment.
Definitely! A bluesky.callbacks.jsonl module would be great to have.
We actually ship this functionality as a "suitcase", suitcase-jsonl but the amount of framework here is overkill for this use case. Better to ship a simple JSONLWriter in bluesky. Perhaps in the docs we can recommend a suitable VSCode plugin?
| await motx.velocity.set(2.0) | ||
| await moty.velocity.set(1.0) | ||
|
|
||
| RE = RunEngine({}, during_task = SampleSimulator(det, motx, moty)) |
There was a problem hiding this comment.
Interesting! This hook is meant to run things like plotting event loops. I'm not sure how I feel about using it to run a simulator like this. Maybe? Is there precedent elsewhere?
There was a problem hiding this comment.
No, I don't think there's a precedent, or at least I haven't seen one.
Yes, understand that the hook was meant for plotting, but this was the best I could think of after many attempts to connect a simulated motor to a simulated detector. The detector has positional attributes, x and y, that determine the produced signal; as I understood, they are meant to represent the position of the motor, but this connection should be realized outside and independent of the bluesky plan (i.e. to simulated an actual physical sample). Perhaps, there's a better way, but we'll likely need to expand the simulated detector and/or motor classes.
There was a problem hiding this comment.
This is an important general question. Sometimes we have run simulations like this as separate processes, sometimes as IOCs. Sometimes we have used threads, as a couple objects in ophyd.sim do. For the cookbook in general, we should think through the trade-offs and perhaps document a recommended way to drive simulations external to the Bluesky plan.
There was a problem hiding this comment.
As part of the ophyd-async 1.0 release I'll make something that looks very much like this in ophyd_async.sim
| # plot_raster_path(spiral_plan, 'motor1', 'motor2', probe_size=.01) | ||
| ``` | ||
|
|
||
| ```{code-cell} ipython3 |
There was a problem hiding this comment.
Nitpick: There are many empty cells in this file. But of course we can fix this up right before merging.
There was a problem hiding this comment.
sure! will clean it up, when it's ready.
| ```{code-cell} ipython3 | ||
| --- | ||
| jupyter: | ||
| outputs_hidden: true |
There was a problem hiding this comment.
What's the purpose in hiding the output?
This PR adds an example notebook to showcase the plotting of streamed data in flyscanning experiments.
Options for tutorials:
Position-compare Block ("position-based")
Position-compare Block for initial position with timed pulses thereafter ("time-based")
or:
Position-based gate with position-based trigger
Position-based gate with time-based triggers
Setpoint gate with time-based triggers -- demand setpoint
Update the tutorials notebook with the recent Stream Plotting code
Simulate step scanning experiments
Simulate flyscanning experiments (see options above)
Expand the description