One of our beamlines utilizes NDPluginStats for collecting 4 time series ROIs during flyscans and I’ve noticed that every now and then the readout of those arrays will be partially blank. At some point in the array the values will change
from valid data to 0s for the remainder of the array and it will do so for each of the 4 stats plugins that I have enabled for that Pilatus. The read out occurs during post-scan upon acquisition completion and the :TSAcquiring PV is “Done”. This issue used
to occur more frequently until I added a few seconds long sleep sequence after telling TSAcquire to stop. Recently the beamline starting doing flymesh scans and this increased the occurrence of the erroneous readout.
I did some digging into one of the recent problematic 61x61 flymesh scans and recorded that it had 4 scans that failed the TS readout partially:
- Scan#36 failed the last 13 points
- #38 failed the last 9 points
- #46 failed the last 5 points
- #52 failed the last 17 points
Each sweep was framing at 2 Hz for 30 sec, so not exactly what I would consider a taxing flyscan. I checked the TIFFs directory and there are images for sweeps where the Stats data got dropped, except for 52, which is missing the last image
of the sweep. It seems coincidental but there are three other sweeps (44, 48, 56) where there are only 60/61 images. Since it was a flymesh, the time between scans was significantly shorter than our typical single pass flyscan setup, which I sense may have
contributed to the problem.
Here’s a visual from the flymesh data where the series of 0s are in dark blue lines at the end of the rows:

In case it’s useful, it’s using driver 2.9.0 and ADCore 3.9.0. Is there a different record I should be polling to verify that that data array is appropriately populated? Do the timing of :TSAcquiring and :TSRead differ when :TSAcquiring
is “Done”? Any insight would be appreciated!
Keith Surrena
Research Support Specialist
Cornell High Energy Synchrotron
Source