EPICS V4 areaDetector integration

EPICS V4/areaDetector Integration
Dave Hickin
Diamond Light Source
areaDetector WG Meeting
Diamond 27/10/2014
EPICS V4 basics
ADPvAccess plugin and driver
Embed ADPvAccess driver
V4 areaDetector
EPICS V4 Basics
• V4 adds structured data to EPICS
• V4 modules
pvData – structured data
pvAccess – network protocol
pvaSrv – pvAccess server on V3 IOC
pvDatabase – V4 records/database and pvAccess
• pvaSrv and pvDatabase are C++-only
pvData basics
• Basic types
• scalar, structure, tagged union, variant union
• arrays of these
• Scalar types
Signed and unsigned integers (8-, 16-, 32-, 64-bit)
Floats and doubles
pvDataCPP basics
• Extensive use of boost shared pointers
• Array types use reference counted shared
• Copy-on-write semantics
• Arrays of complex types use shared vectors of
shared pointers
• Unions have shared pointer to top-level field
pvDataCPP basics
• Data can be shared or shallow or deep-copied
• Shallow-copy easy and avoids copying large
• Care needs to be taken with unions and arrays
of complex data types
• Const is not implemented – but could be
• Sharing currently problematic
• References can be hung onto
pvAccess basics
• Create/destroy pvAccess channel
• Channel services
Get, Put, PutGet
Channel array
• V4 Structure encoding NDArray
Array data uses unions of scalar arrays
Attributes use variant unions (anys)
Dimension and attribute use structure arrays
Data sizes
Codec for compression encoding
• Normative type (replaces NTImage)
Issues to think about
• Monitors do shallow copy
• Structures could be shared (const would help)
or shallow-copied
• References can be held onto
• How to do free-lists
• Monitors have overflow bit but no dropped
frame count
ADPvAccess Plugin/Driver
• V4 sever-side plugin and client-side driver
• Plugin puts NDArray data in V4 structure and
publishes it via pvAccess
• Client monitors and converts V4 structures to
• Allows local and remote transfer of NDArrays
• Compression (through Blosc/LZ4)
Performance on 10 Gig Ethernet
• Uncompressed
• 120-122 frames per second (97-99+% bandwidth)
• Compressed
• With compression image reduced to 36% of original size
using lz4 and 38% by Blosc
• Single threaded compression reduces performance
• Blosc-based compression (multithreaded) increases rate
• Blosc + lz4 best. Up to ~230 frames per second (190% of
Current and near future work
• Complete move to NTNDArray from NTImage
• Move to GitHub Module - ADPvAccess
• Package and release
• Integration with other EPICS developments
especially CS-Studio
• Windows build
• Deploy on beamline (I12 is candidate)
Embed ADPvAccess driver
• Local plugins (in same process) connect to
NDArray driver as usual
• If NDArray driver not present, first plugin
creates V4 monitor client driver monitors “PV”
and plugin connects to this
• Subsequent plugins connect to this local driver
• Avoids having to explicitly create client driver
• Monitor stops when all plugins disabled
V4 areaDetector drivers
Put frame data direct into NTNDArray
V4 client plugins consume NTNDArrays
Can publish frame easily as “PV”
Avoids conversion from NDArray and V4
server plugin
• Straight-forward to re-write drivers
• V4 SimDetector prototyped
• Existing NDArray-plugins can be run though
ADPvAccess client
V4 client plugins
• areaDetector plugins can be rewritten to
process NTNDArrays – straight-forward
• New V4 plugins can consume NTNDArray
• V4 client plugins can work with old drivers
through ADPvAccess server plugin
• Various options for passing frames to plugins
Option 1 - Clients use pva monitors
Clients create monitor to NTNDArray
Monitor queues can be used to queue frames
Only required fields need be monitored
Local (same process) monitors perform
shallow copy
• Multiple remote monitors transfer data
multiple times
Option 2 - Plugins use single
• First plugin registers with “PV”. Creates
monitor. S/W layer/object to manage this.
Plugin registers with monitor
• Plugin gets a call-back. Passed an NTNDArray (const) shared or shallow copy
• Subsequent plugins register, but no new
monitor created
• Each plugin can have own queue and
processing thread
Option 3 - Plugins use single
monitor remotely, multiple locally
• For first plugin creates monitor. S/W
layer/object to manage this. Republishes
local-only PV. Client monitors this
• Additional plugins monitor local PV
• Plugins can use monitor queues
Option 4 - PVManager
• Handles queue/buffering/aggregation and
background data processing
• Java only. No C++ implementation yet
• Abstract types (Vtypes). One for NTNDArray
• Used in CSS
• Single channel/monitor to “PV”
• Could it be used for plugins?
• Limited vtypes