EPICS V4/areaDetector Integration
Dave Hickin
Diamond Light Source
areaDetector WG Meeting
Diamond 27/10/2014
Overview
•
•
•
•
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
•
•
•
•
Booleans
Signed and unsigned integers (8-, 16-, 32-, 64-bit)
Floats and doubles
Strings
pvDataCPP basics
• Extensive use of boost shared pointers
• Array types use reference counted shared
vector
• 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
arrays
• Care needs to be taken with unions and arrays
of complex data types
• Const is not implemented – but could be
added
• Sharing currently problematic
• References can be hung onto
pvAccess basics
• Create/destroy pvAccess channel
• Channel services
•
•
•
•
•
•
Introspection
Get, Put, PutGet
Monitor
Process
RPC
Channel array
NTNDArray
• V4 Structure encoding NDArray
•
•
•
•
•
•
•
Array data uses unions of scalar arrays
Attributes use variant unions (anys)
Dimension and attribute use structure arrays
Timestamps
UniqueId
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
NDArrays
• 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
bandwidth)
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
monitor
• 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