Closed prjemian closed 1 year ago
This example is very rough. I hope to develop better code in the near future but for now, this is the example to use. This code uses pvapy's pvaccess
module to receive an image PV named on line 19. The pva_to_image()
gets the image frame. The get_pva_ndattributes()
gets the metadata, packaged as NDAttributes (from an attributes.xml
file) by the area detector IOC. At line 79, the image is sent to an analysis function (centroid and width). The results are printed to stdout where another process parses the printout and passes the results back to the EPICS IOC.
https://github.com/BCDA-APS/bdp_controls/blob/main/qserver/game_client/qs_pva_client.py
PV updates are received by pvmonitor (like camonitor but for PVA), setup on line 148. After you look at this a bit, it starts to make some sense. The example was purposely kept small so it might not be too difficult to see how to adapt to another purpose.
This is only a client. It does not write its results into PVA. That is code for the future.
But, "within Bluesky" is something that does not exist per se. There is no official PVA interface with ophyd at this time. Diamond Light Source is working on the next version of ophyd, which will include a backend for PVA. Currently, ophyd uses a control layer selector to pick either PyEpics or caproto for CA support. The new code will add a similar selector layer. At this point of development, DLS has only worked with p4p. Once it is released, I expect to take on the task of adding pvapy as an additional choice.
Until then, we just call pvapy routines from ophyd directly. If we want to run longer processes, we must be conscientious and run them in a thread so as not to delay the bluesky RunEngine
from its routine work.
Make a new directory for examples we can share.
APS beam line scientist asks for a simple Python demo showing how to receive streaming PVA data: