1. EPICS V4/areaDetector Integration
Dave Hickin
Diamond Light Source
areaDetector WG Meeting
Diamond 27/10/2014

2. Overview EPICS V4 basics ADPvAccess plugin and driver
Embed ADPvAccess driver
V4 areaDetector

3. 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

4. pvData basics Basic types Scalar 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

5. 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

6. 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

7. pvAccess basics Create/destroy pvAccess channel Channel services
Introspection
Get, Put, PutGet
Monitor
Process
RPC
Channel array

8. 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)

9. 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

10. 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)

12. Performance on 10 Gig Ethernet
Uncompressed
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)

13. 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)

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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