As far as I can see, we're currently using QSRV for our PVAccess support:
|
WITH_PVA=YES |
|
WITH_QSRV=YES |
I was wondering whether (or perhaps when) it would be a good idea to switch to using PVXS as our backend, at least for QSRV2 (ref.: https://github.com/areaDetector/ADCore/blob/6c53844e72d467b86a03fe712ea1f69210e2cae0/ADApp/commonDriverMakefile#L40). The documentation on PVXS seems to say that it is already a full replacement (ref.: https://epics-base.github.io/pvxs/ioc.html#qsrv-2).
My main interest here is to use the thing that the community seems to be moving towards, as far as my limited knowledge can see, and also to possibly improve compatibility with the p4p python package, which is currently the only supported integration with PyDM (though I should clarify I did no tests whatsoever on whether something would actually change in case the change was made).
Furthermore, it seems that the upstream areaDetector example config file already suggests this change (ref.: https://github.com/areaDetector/areaDetector/blob/b01d3d5536920362aff4e534556193a3e664ddd3/configure/EXAMPLE_CONFIG_SITE.local#L40), so it should be fine.
Maybe the change was already intended in this commit, though I can't say for sure.
As far as I can see, we're currently using QSRV for our PVAccess support:
epics-in-docker/base/install_area_detector.sh
Lines 57 to 58 in 7769af5
I was wondering whether (or perhaps when) it would be a good idea to switch to using PVXS as our backend, at least for QSRV2 (ref.: https://github.com/areaDetector/ADCore/blob/6c53844e72d467b86a03fe712ea1f69210e2cae0/ADApp/commonDriverMakefile#L40). The documentation on PVXS seems to say that it is already a full replacement (ref.: https://epics-base.github.io/pvxs/ioc.html#qsrv-2).
My main interest here is to use the thing that the community seems to be moving towards, as far as my limited knowledge can see, and also to possibly improve compatibility with the p4p python package, which is currently the only supported integration with PyDM (though I should clarify I did no tests whatsoever on whether something would actually change in case the change was made).
Furthermore, it seems that the upstream areaDetector example config file already suggests this change (ref.: https://github.com/areaDetector/areaDetector/blob/b01d3d5536920362aff4e534556193a3e664ddd3/configure/EXAMPLE_CONFIG_SITE.local#L40), so it should be fine.
Maybe the change was already intended in this commit, though I can't say for sure.