EPICS V4 Developer Meeting at APS

Agenda, Thursday 19th November 2015

9:00        Roadmap & charter (Greg, Bob)

Combining V3 with V4 — discussion (Andrew)

Development plans & priorities for 4.6


Present: MD, KV, MP, KK, GW, BD, AJ, MK, RL, DH, TK, GS, SV

Online: SH, AA

Chair: GW

Scribe: KK

NEW TOPIC: Combining V3 with V4 — discussion (Andrew)

AJ Slides: See part of ANJ-Slides.pdf

AJ: [Merging V4 into base presentation]

Pro - One stop download. Remove pvaSrv duplication for 3.14/3.15.

Con - Tying release of base and V4

KK: That’s the point. Should be “one EPICS”

AJ: What if some site wants to use pvAccess server in R3.14 IOC?

RL: Why introduce strong coupling when not needed?

TK: “V4” naming misleads many people. At least change the name?

KK: Technically, they can remain separate, but bundling would increase adoptance

AJ: Bundling should remain a separate operation. Like MD does for Debian

Con - Boost now required

AJ: Download size grows

KK: Need to control what goes into IOC binary (which device support; pvaSrv yes/now), but source download size not a practical concern

MD: Do not underestimate the effort of bundling, handling patches

MK: Compare areadetector

AJ: Asyn, .. are still separate downloads

MD: It’s complicated, using a top-level repository, and different, because not everybody needs AD. EPICS base _is_ required by everybody

TK: I think we all agree that the base/V4 merge should happen one day

GW: Assume we don’t merge, then we do need to maintain a compatibility matrix of what version of base goes with which V4 release anyway?

MD: It’s a list of version ranges, not 1-1 matrix

KK: Aren’t the same people working on V4 and base, so combined source makes their life easier?

MD: Not really.. Takes more time to create nicely integrated base & V4

SV: [tango VM download]

AJ: Removing boost is big task. Implement shared_ptr, micro-bench. Support or disable V4 on Cygwin, RTEMS, ..

KK: Do these need to be fixed anyway, or are they reasons to never merge?

AJ: Need to be fixed. All reasons we can’t merge right now.

AJ: pvaSrv cleanup of startup messages

[DH, RL, KK]: pvaSrv certainly needs review/cleanup

BD: Who is doing the work listed as prereq. for merging?

DH: Would be willing to continue work on pvaSrv.

MK: Can work on documentation

KK: SNS likely able to work on pvaSrv

RL: Bundling is very important to simplify initial installation. Merging bad idea because right now that means you get 3.16 + V4, but you don’t want to use 3.16 in production

GW: Bundling for now is the way to go

TK: In the long term, will the model always be based on bundling, or is end goal still a merge?

[discussion on need to support iOS, solaris, ..]

SH: Download of bundle on EPICS web site would be ideal.

RL: Bundle snapshot of EPICS base into V4, so there’ll be a V4 download that includes base.


A V4 tar file shall be produced which includes EPICS base plus what’s-now-called-V4. It will be made available on the EPICS web site (at least, possibly also the V4 web site).

AI on RL: Change the C++ bundling to add creation of a tarfile that includes Base 3.15.x

V4 developers and users will also be able to download source and v4 tar (only) from the v4 web site.

GS: Many links still point to source forge

RL, AJ: Yes, SF still best for web content, mailing list.

[Tried google ‘EPICS V4’, ‘Download’ points to DF *.tar, but “code” link ends on github. github-repo link on EPICS V4 is also correct]

AI on GW: Update “Source Forge Project” link with github link.

AI on RL:  Delete/hide mercurial repo on sourceforge because it might be mistaken for the current repo, except “port driver” and some more which have not been ported

NEW TOPIC: Roadmap

Major points

Additional Minor and Proposals

Topic: Review and solidify pvaSrv.

KK suggests that ORNL might undertake pvaSrv solidification

SH: What needs to be done for pvaSrv?

DH: Structurally, it needs to be redone. Current implementation bad, multiple outstanding issues. R3.14/R3.15 support also resulted in duplication.

RL: Uses switch statements to handle the various types, where templates might be a better design.

BD: Could make better use of NT types, like create image types from areadetector records. Vision is to serve NTNDArray out of areadetector, instead of having many separate records.

GW: Is this pvaSrv, or a new pvDatabase?

KK: Is idea that future area detector should include a pvAccess server that provides image with N properties, instead of just N separate records?

BD: Yes

Several: .. but that’s separate from pvaSrv, which is just for the existing records.

BD: Records need to update. For example, records should provide new NT time which includes user time tag. Will require updated records, because existing V3 IOC only has sec+nano, no user tag. Similarly, “pvaSrv” for areadetector image record should not just serve a waveform but somehow provide NTImage.

MD: Ultimately, tighter integration of records/pvaSrv/pvDatabase, I/O links between them. Exact path unclear.

AA: [?? Experimenter/scientist/analysis view of data vs. engineering pieces of data]

Conclusion then: in reimplementation of pvaSrv, add also a “usertag” to record’s time stamp, whose contents is configurable. Eg to serve complex timestamp data along with record values.

Step 1: Stabilize serving basic records, fields, data types (enum, meta data). Fix outstanding issues.DH list issues and fix by March.

Step 2: Served NT timestamp’s userTag becomes configurable. Replace CA.

Step N: Areadetector’s image served as image, not just waveform

TOPIC: Solidify pvRequest, syntax and semantics

GW: Goes with pvaSrv

AJ: Lacking definition

MD: Need to document requests handled by pvaSrv

MK: Example: process, server-side filtering

DH: Access to sub-fields, process, block, queue size are already documented

BD: dbGroup access to get multi channel array is defined

[discussion on which data type to use for dbGroup.

One type is natural for reading, only updating the changes.

On write, may need different type to always write everything, even if no change in value, because act of writing triggers processing


GW: Example from AIDA - If impossible to write all elements, then don’t write at all, or write elements that do have write access? Planned to not-write-at-all, but write-what’s-possible was most practical in the end.

SH: If no need to write atomically, then simply write one by one

GW: For atomic write, need flag to “ignore errors”

TOPIC: pipelining

MK: ChannelProvider is limited to monitor. Proof of concept.

MD: That’s sufficient for BNL use case.

MD: Watermarking needs to be added. Can be added as issue. Matej good candidate to handle it.

TOPIC: multicast

BD: Matej working on this. Expected to be far along.

TK, MK: Should have status update in bi-weekly phone meeting

RL: Should reduce length of phone meetings, but have more frequent direct developer interactions

RESOLUTION: Weekly phone meetings should stop after 30 minutes.

TOPIC: Documentation

MK: Working on developer’s guide

AJ: There is info on website. Everybody welcome to comment/help/improve

SH: ICALEPCS side meeting comment was request for use cases, info on how V4 helps there

AI on GW: Simplify Literature page and home page to help users find novice oriented documentation.

TOPIC: Diversify

GW: will try to recruit women to WG.

BD: Should be that any particular lab should be prepared to contribute at least 40% of an FTE for participant level, though that 40% FTE may be distributed among a number of people.

TOPIC: Additional Minor and Proposals

ISSUE: DH points out that Java array handling API should be rewritten, probably in compliance with C++ array API.

Meeting ended 12:30ish.