Minutes of EPICS V4 Telecon, 19-Nov-2013

Agenda

Please find below the agenda for our regularly scheduled telecon [1].

0. Preliminaries (5 mins)

1. python pvAccess, Sinisa (30 mins),

2. Status review continued (25 mins). Please check out the list below [2] of line item
  activities and jobs of the WG. We did Clients and APIs last week. Tomorrow start
  with Efficient handling of big data, and go on from there.

Minutes

Attendees:  AJ, GW, DH, MK, MS, NM, SV, GS, GC (MD for item 2)

Scribe: DH

Chair: GW

1. python pvAccess, Sinisa (30 mins)

SV: (PowerPoint slides available describing details). Aim to make Python simple to build and use, python look and feel - dictionaries, lists etc. Use boost Python to wrap existing C++ libraries. One problem: not well defined high-level C++ API. Build uses EPICS base. Nothing special needs doing.Need 4 things: base, V4, boost (python) and python. Build/use steps.

1. Build.

2. Add pvAccessCPP to python paths

3. Run setup (source setup.sh)

4. Python.

5. from pvAccess import *

And you're away. Create PVs, get, put - intuitive/easy to use API.[SV demos creating, getting, putting] Structure initialised using key-value pairs. PVs convertible to dictionary.

PVObject class. Base class for all pvAccess objects.

Channel class. Create channel, get, put. [SV demos creating channel]

Also exist RPC servers and client classes. [SV demos using RPC client to connect to test service (sum) in pvAccess and creates simple RPC service in Python and queries with Python client].

Exceptions: Currently generate UserWarning. Hierarchy planned.

GW: Looks promising. Well done.

MK: Can you make repository.

SV: Don’t have repo access

DH: Looks nice.

GW: Next: Monitors. ID.

Meeting consensus was Sinisa’s python wrapper was great work, and we’re looking forward to

access to in through an SF repo in epicspv-data. A few outstanding important things (monitors not yet implemented) but nearly usable now.

2. Status review continued (25 mins)

GW: Let’s get update for efficient conversion, data pipelining.

MD: THese items mine. No progress last couple of weeks due to commissioning.

1) VxWorks 5.5 - next thing when have time.

2) Handling variant arrays.

3) Type conversion - almost done.

MK: Clarify what conversion means.

GW. Convert api.

MD: Changes for convert and shared vector now merged.

AH: Do we need to discuss float to string conversion: precision etc.

GW: Can you take that on.

AH: Not time at moment

GW. Needs to be work item.

.MD:

4) batched field access

MD: BFA is paused at working out what to do if the DTYP field is changed at the same time a link is retargeted at runtime.

GW: Estimate when can return to V4.

MD: Things progressing quickly on NSLS II commissioning. Have beam in 2-3 weeks. Working heavily on non V4.

DH: Now shared vector is in, can we now use them? Are there efficiencies we can exploit?

MD: Like to see them used in serialization

MS: I need to look at that.

AI on MS: review shared vector implementation with a view to deployment in serialization.

* Data Processing Support
 + Decide in definition of the standard image types; implement in Normative Types doc.

DH: Working on his version - a flattening of the areaDetector image. Dh utilized the

new union in flattened areaDetector N-type candidate definition.

DH: Bob also has a definition of a type

Well will look at using that type too, see whether Bob’s type work with Area detector application and give Bob something to test with.

DH: Suspects network not serialization will be the bottleneck in performance

MD: Is there anything that stops you implementing in shared_vector?

DH: I have tried works when create buffer and swap in. Looking at creating buffer around area detector array to avoid copy. Tried briefly but didn’t work. DH learning the rules

for “ownership” of the buffer in area detector and integrating with V4.

MD: Did you check out how background subtraction is done?

MK: I think the rule is you must copy - not enforced by code but only be convention.

Multicast:

MS: Am working on it, and expect a Java prototype in a couple of weeks. Presently implemented as a distinct library, but don’t yet know how to integrate into pvAccess.

MD: How is allocation of allocation of multicast IP addresses handled?

GW: If [MD] has a specific worry about that, please write it in email to MS so he

sees it explicitly and has a reference.

AI on MD, write email re concern about allocation of multicast IP addresses.

Meeting ends 9.34 PDT.