Hi Jörn,
> I
want to read the ArrayData from the NDStdArrayPlugin and the Centroid and
>
Profile information from the NDStatsPlugin at a rate of 10Hz.
In general I agree with Ralph, pvAccess is better because the image and the attributes are
part of the same structure. Here is how to set up the plugin chain:
camera -> NDPluginStats -> NDPluginPva
In NDPluginStats you create an attributes XML file that defines the Centroid as a PARAM attribute
to attach to the NDArray. That means it reads the attribute directly from the NDPluginStats plugin, not using Channel Access. There is an example of such a file here:
Then the Centroid will be an attribute that is part of the pvAccess NTNDArray structure.
However, there is a problem for your application, because you said you also want to read the
Profile information. The Profile is an array, and currently NDAttributes are limited to being scalar values and strings. That means you cannot pass the Profile data as an attribute in the NDArray.
If you use Channel Access do the following:
- Put
monitor callbacks on the ArrayData from the NDPluginStdArrays image data, the UniqueID from both plugins, and the Centroid and Profile values.
- In the monitor callback for that ArrayData capture the most recent callback values for the UniqueID, Centroid,
and Profile PVs.
- I think this is likely to give you synchronized data at 10 Hz, but of course it is not guaranteed.
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, August 17, 2022 7:58 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: areaDetector synchronization question
If I read the unique id from both plugins and make sure the are the same, how
big is the chance that the data does not match if I read them in two threads
(thread 1: the image, thread 2: the stats information)?
Would the situation improve if I can remove the gateway process?
The one thing that would remove the issue:
Use pvAccess, where the stats and the image are part of the same structure, and the client is guaranteed to get consistent updates.
If you are exporting into a different protocol anyway, the difference shouldn't be that much. In terms of being future-proof, it would be a big step forward.
Cheers,
~Ralph
|