EPICS V4 Working Group Meeting

Lund, Sweden, Sunday 22 & Monday 23 May 2016

Earlier        Later

Where: 22nd May Clarion Collection Hotel Planetstaden.
Dalbyvägen 38, 224 60 Lund
Telephone: +46 46-280 01 00

23 May ESS.

Time: Meeting convenes 9:00 am for the usual plugging in, checking for audio feedback, and realizing you forgot a compatible power supply, setting up hangout, minutes, coffee etc. Real start at 9:30 latest.

Roughly speaking the first day will be tactical matters and the second day strategy.

Agenda

Tactics and Technical Matters

* Release status and plans

                       See https://sourceforge.net/p/epics-pvdata/mailman/message/34937405/

* pvaSrv (with Marty’s presence)

* Licensing and Open Source-ness (revisited for Diamond). Again with the licensing.

* NTComplexTable

   Implementation as "any" or union (MS, DH, GW).

* End-users’ experiences, feedback

Strategy

Other items:

* Status of AIs from APS working group meeting.

* Towards merging v3 and v4 releases.

So far our story (decided in last f2f) is that v4 will be released with one or a set of compatible bases. Review pros-cons. We'll inevitably get this question again a the EPICS meeting. Want us on the same page, with a clear and solid answer. Preferably with a deadline. [1]

* Towards closer integration of IOC base and pvAccess.

 Device support or new link type [2]

 Towards full replacement of RSRV. "Writing a new database routine for each record to support PVAccess." (BD, need more info)

* Charter and Roadmap items


[1] Merging V4 into EPICS Base, pp8-10,

http://epics-pvdata.sourceforge.net/files/talks/2015/ANJ-F2F-201511.pdf

[2] PVAccess Links for the IOC Database, pp 11-13,

http://epics-pvdata.sourceforge.net/files/talks/2015/ANJ-F2F-201511.pdf

Sunday Minutes

Present: DH, RL, TK, HJ, AJ, KK, KS, KV, GW, MD, SH, (MS,MK hangout)

Chair: GW, AJ

Scribe: KK

4.5.0.2 Patch Release

DH: 4.5.0.2 only involves C++ changes, no Java. Changes for 4.5.0.2 C++:†

pvDataCPP (5.0.4)

Fixed bitset serialization (issue #24)

Fixed truncation in BitSet::or_and (issue #27)

pvAccessCPP (4.1.3)

Monitor fix: element no longer queued when overrun in progress.

pvaSrv (0.11.3)

Fixed pvaSrv does not always get first monitor (issue #1)

Fixed Maximum number of free monitor elements is 2, regardless of queue size (issue #23)

Fix No updates after restarting monitors (issue #24)
pvaSrv (0.11.4)

Fix more issues: #38, #41, #44, #46, #48 (fields, structures, enums)

Add support for Cygwin and MinGW

Fix issues #34, #35 (weak pointers and locking)

DH: 4.5.0.2 tarball on SF site. In VM and training bundle. Not announced. Release notes missing the pvaSrv 0.11.3->0.11.4 changes.

DH: Can I quickly respin the tarball?

GW: OK.

DH: pvaSrv changes were cherry-picked from master to keep the API.Master includes more updates, but those would change the API.

pvaSrv how provides same data as CA except for details on timestamps and unsigned data types (promoting e.g. ulong -> double, which weren’t handled by CA).

GW: Can you get list of PVs via pvlist?

DH: Yes. Thought there would be issue on 3.15 because of server-side filtering, but worked when tried.

RL: .. because list would have infinite size. List only record names?

KK: Why not list just record names?
RL: Would be inconsistent with CA’s list.

MS: List only “static” records, not alias/dynamically created PV names.

AJ: Still list all record & field combinations?

AJ: Include server-side filter information into the pvAccess request string?

MS: pvlist calls channelRPC on server. “Info” command returns list of records. Could add more commands to get additional information.

GW: Create short proposal of suggested commands? 1) List records 2) List field names 3) .. filtering ..?

AI: Create proposed list of command arguments for the channelRPC info server. Consider ‘glob’ pattern for names. What about long lists, return in pages? (MS)

4.6 Release

DH: Will include

DH: I depend on each module owner doing their release notes.

AJ: Require module owners to update release notes when merging each individual change. Means that release notes need to be located within each module.

RL: No replacement for proper release planning.

GW: Will 4.6 include pipelining, windowing?

MS: Windowing was there but not configurable using percentage of total queue size. Can configure when creating channel in 4.6.

GW: Are we still dependent on boost?

Yes:

Sub-topic: Boot dependence

MD/AJ - discuss issue of boost, and whether problem should be solved by build system

AJ: Boost is large and incompatible with version used by AreaDetector or the one included by Linux distro.

MD: Boost primarily used for shared pointers. vxWorks, maybe RTEMS lag in C++ version.

KV: Strip just shared pointers off boost?

AJ: Did that in V4 pvCommon/include.

MD: Can even increase compatibility issues because you get unpredictable mix of boost includes.

SH: Make Boost an optional download only for targets that don’t already provide it?

GW: Can this be done for 4.6? Being independent from Boost was a 4.6 goal.

MD: V4 has a shared-pointer include which detects either Boost, TR-1 or C++11. Problem is that ‘host’ build might be able to use C++11 while ‘target’ build for vxWorks might need something else, yet current build system can only pick one for all.

AJ: May have build system solution. Need to merge git changes. Won’t help with Base merges, which need Boost removed.

DH: DLS keeps vxWorks at 5.5. Unclear how to add V4.

AJ: vxWorks 6.x is required for V4.

MD: RTEMS 4.10 is required for V4.

SH: SNS uses vxWorks 5.5 and 6.7

MK: C++11 has been standard for a while

GW: Which features do we require?

MD: Shared pointers. Would like to use regular expressions.

Decision: Step 1 (4.6) install into OS-dependent directories to allow separate host, target setup. Step 2 (4.?): Remove Boost to allow eventual merge into Base.

DH: Recent tests no longer show Windows crashes on master. (Not present on 4.5.0.x).

MS: Merging the gateway code added introspection which created the Windows crashes.

GW: Do we need Java 6 compatibility?

MS: Java 6 misses Multicasting support (join MC group).

GW: SLAC, Berkeley use Matlab which still stayed on Java 6 for the production version. Newer Matlab does support Java 7 but would require $$ for license.

HJ: Compiled Matlab code can run without runtime license.

GW: Need to update code, and no performance gain from compiled code -> Not using compiled code. Will update Matlab in ~year and OK to move to Java 7.

MD: While you limp along with Java 6, do you miss significant pvAccess features? Fix for bitset serialization bug?

GW: For now almost exclusively using RPC. Might add pvaSrv to existing IOCs and thus use more than just RPC. Directory service returns CA as well as pva channels, so need to support pva servers.

MD: Directory service needs to indicate if result is CA or pva.

GW: SLAC users have channel name and don’t want to bother whether to type ‘caget’ or ‘pvget’.

MS: Same channel name may be served by both protocols...

Decision: No longer bound by Java 6.

AJ: Packaging Makefile will try to build all modules in parallel and fail with ‘make -j’. Can work with DH to update that Makefile. Create separate git repo for packaging Makefile, scripts.

Sub-topic:

RL: Java building & bundling based on ‘release versions’ file, https://github.com/epics-base/pvDataWWW/blob/master/scripts/RELEASE_VERSIONS . Java has a Jenkins job, based on Maven, to bundle what’s listed in the release versions file without running any tests. Idea: Use git submodules to compile, run tests, then bundle. .. But this would ignore what’s listed in the release versions file.

AJ: Can build process check versions listed in master pom.xml against versions listed in release versions file?

MK: Can that master pom.xml replace the version info which is currently duplicated in many submodule pom.xml?

RL: Yes. bundle java repo has that master pom.xml. Switching branches of the bundle java repo then selects different versions. Remaining issue with git submodules: Still need to manually update each submodule, which creates uncommitted changes in top-level module.

AJ: Once this works with Java, do the same with C++, replacing the release versions file with the master pom.xml-equivalent for the C++ build.

GW: Short-term, would there be another way to execute the Java tests at the end of building?

RL: Not easily. Maven puts the test phase before the bundling phase.

KK: Create the release file for humans at the end?

GW: Release versions file contains git tags.

RL: OK to move from one release versions file to separate top-level files for Java (top-level pom.xml for version plus maybe file with git tags) and C++ (TBD)?

Decision: yes.

RL: OK to move from release versions file with full history to just listing the current versions?  

Decision: yes.

RL: What to check? Git hash, tag, maven version?

KS: When using released Maven bundle, tests have been run before bundle was released. Would only need to run integration tests.

Decision: Check if tag exists in each submodule for the Maven version number listed in the master pom.xml.

RL: Submodule poms need to include parent pom. Work on master or 4.6 release branch?

Decision: The new build system should start at (4.6) release branch

RL: Release to Maven central instead of custom repo?

Decision: Maven central. Will be reference in SF README to it.

pvaSrv

* pvaSrv (with Marty’s presence)

KK: SNS likely to keep accelerator on CA, but could move beamlines to pva, as long as there’s a read-access gateway to CA for accelerator data.

GW: Interested in using pvaSrv to embed pulse ID into data of existing IOCs. To get higher rate data, interested in reading V4 tables of time-stamped data instead of subscribing to high-rate CA channels.

DH: Compared CA provider, pvaSrv, request format. pvinfo for double shows about same info as DBR_CTRL_DOUBLE. pvget defaulted to only value, no alarm, control range etc. Updated to get uniform results. pvget -p ca -r “value, timeStamp” used to return complete structure from closest matching DBR type, which included alarm. Now returns just requested fields. Request for timeStamp{second, nano} returns structure with those 2 elements, not identified as “time_t” because it’s not complete. Request for all of the timeStamp elements will return time_t timeStamp.

AJ: Need library for normative types to check if data matches complete NT?

AJ: Is timeStamp.secondsPastEpoch based on 1970 or 1990 epoch?

All: Defined as 1970 in normative types document

RL: What about flag to identify GPS, TAI, Posix?

All: Not supported

DH: If you have structure with elements value, alarm, timeStamp, should that be served as “NTScalar”? Is a timeStamp with just seconds and nano but no userTag a time_t?

Decision: Clients cannot expect to get a type ID hint unless they request the complete structure.

Subtopic: pvaSrv vs “QSRV.”

MD: Started QSRV because pvaSrv lacked tests.

GW: pvaSrv has known issues, and now we have QSRV. How to continue?

RL: Let’s keep the [QSRV] functionality under the name pvaSrv.

DH: Adding tests is complicated by timestamps returned by server which keep changing. So testing basic does-not-crash behavior. Using random combinations of fields, comparing results from ca and pva provider.
MD: .. showed unit tests of QSRV which use local database, setting timestamp etc. and verifying data returned.
RL: Dave’s test use real IOC. Real gateway test needs to be integration test that starts IOC, gateway, then tests via for example pvaPy.

DH: Use dbEvent to replace caEvent. Post monitor when properties change.

MD: Remaining QSRV work to replace pvaSrv: Add put-callback, so that it waits for the record processing to complete. It also supports group operations, but that’s beyond pvaSrv functionality.

RL: Information for pvData alarm not available via database db_access API. Need to inspect fields of records.

AJ: .. and must not assume that ‘HIGH’ has high alarm limit (BO record)

DH: Continue pvaSrv work?

MD: Put-callback could be added to QSRV by fall 2016, pending funding. Requires base 3.15 because of test API, and change from db access to db channel. API for put notify (process notify) also changed from 3.14 to 3.15.

DH: Can QSRV include example setup with same PVs as pvaSrv test setup (“double01”, ..)? Basic records, no need for custom record types.

AI on RL: Create test database with some double, string, .. record

Decision: Path forward is “QSRV”, which will be named pvaSrv.  QSRV will require Base 3.15 or higher [3.14 support subject to future funding, ~2 months FTE, becoming available]. Dave tries to run his tests not only against pvaSrv but also QSRV.

Licensing

AJ: All modules have the MIT license, except for one case of EPICS license (pvaPy). The differences are just in the list of Copyright owners, which we agreed to unify.

DH: Matt Gerring assumes it’s MIT.

End-users’ experiences, feedback

KV: SNS depends on python pva client. Increased data rates (up to 50MB/second) exposed bottleneck in pva client for python: Stop receiving monitor updates, or get inconsistent data for elements of a structure.

DH: Fixed C++ problem where last queue element was modified.

KV: Our problems are all python specific. Cannot be reproduced with C++ client, so workaround is to handle data in C++ code before passing to python.

MD: Found race condition where monitor data was fetched and released before python code could read it, so data might change while python reads it.

KV: Recursive construction of python dict() from received data is slow. Can this be improved by using numpy type code in pva client for python?

MD: Saw the same types of errors: Updates end; inconsistent structure elements; crashes. Fixed inconsistent structure elements, #21. Still open: #18, #20 in github epics-base/pvaP. Overall, pvaPy code size could be reduced by simplifying the API, eliminating rarely used code. Rewrite would be a good option.

AJ: No local funding to update pvaPy. Pull requests to pvaPy are very welcome. Also no objections against replacement.

ISSUE: There are issues in pvaPy that probably should be addressed by reimplementation. SV probably won’t be funded to do it. MD could do it with funding.

DH: Diamond would like callbacks on monitors to call existing python objects.

MD: Extracting data not elegant in existing API. Need to use dict() and retrieve one level at a time when reading nested structure elements.

KV: pyEpics is 5x faster than pvaPy, indicating room for optimization.

SH: SNS could help with optimization, but probably not complete rewrite.

MD, KV: Part of the API is close to C++ code. Better would be an API better suited for python. Example: In C++, each method as fixed return type, resulting in getInt(), getString(), .. For python, just get() could return any type.

Decision: Contact SV for his input. KV to check for optimization.

HJ: Intend to use V4 on new machine. Good experience with Archive Appliance. Successfully tested pva2pva. Indent to acquire data into archive appliance. Use python to read data back out.

GW: What V4 features are most interesting?

HJ: NTndarray. Used archive appliance with pva, but only scalars, not NTndarray.

RL: At CODAC training, one EPICS training participant found the V4 examples and was able to compile & run them on his own. Found API easy to understand.

DH: Plan to deploy V4 image support (BNL plugin for area detector) on a beam line. Includes Windows computer. “Malcolm” is middleware to connect EPICS to GDA. Provides ‘device’ for scanning.

SH: Using V4 for raw neutron data. Expanding this to more beamlines by ~2018. Next would be use of V4 for area detector images.

Sunday meeting ended here…

Monday Minutes

Present: DH, RL, TK, HJ, AJ, KK, KS, KV, GW, MD, SH, HL, (MS,MK hangout)

Chair: GW, AJ

Scribe: KK

[x] Feedback check

HJ: Compiled pva2pva without problems. Start script defines client and server addresses. Used Archiver Appliance to read scalar and waveform from pva. Stopping the gateway proves that archiver indeed reads from GW and not IOC’s pva server. Waveform shows as “DBR_WAVEFORM_DOUBLE” in archive appliance.

KK: For CA, appliance creates multiple connections per PV name. How about pva?

HJ: (restarts demo w/ higher log level) Archive Appliance connects to x.NAME, x.ADEL, x.MDEL, x.RTYP, x.SCAN, ..

KS: BNL uses Archive Appliance with about 80k PVs (times maybe 5 for CA channels) at rates of 1 to 10 Hz.

New Topic: DELIVERABLES THAT EMERGED FROM APS F2F

0. Development process improvement.

  x AI on *GW*: Make his cheat sheet on release process public.

  X AI on *GW*: Change the process documentation wrt pull request process ***

  x AI on *GW*: Write Bob

  AI on *GW*: Write Mark to clarify process.

1. PV semantics: Integrate features of pub/sub and RPC, specifically so that a

  single PV may be used in either capacity (ie access 1 PV by any "method"

  including rpc.)

AI on DH

Status: completed.

2. Pipelining watermark: Add method to pvAccess pipelining that gives queue

  state indication (aka "watermark") to tell server side to throttle data [back].

  AI on MD or MS: Specify additions necessary to add watermark support to

  pvAccess. (2)

Status: completed

3. Monitor with refreshed 1st value: add an argument or some other supported API

  functionality change so that -m gets fresh data for the 1st point.

  ** Who? **

All: Issue is not new but can be demonstrated with camonitor: Initial monitor will be current value. Further updates are sent by record based on MDEL (or ADEL). As a result, rarely changing values can result in operator displays that show different data, depending on their start time.

AJ: Deadband is implemented in record, not per client. No knowledge of last value & timestamp sent.

RL: There’s also just one timestamp per record. Not one timestamp per field. Result can be ‘new’ data for a field with old timestamp when field changed but record didn’t process to get new timestamp.

MD: QSRV currently implemented the same way, no cache of last-value-sent-out in QSRV.

Conclusion: Defer until support for deadbands in pvAccess

4. Integrate 3.16 lock with pvDatabase. Integrate lock pattern and API being

  integrated into 3.16 with pvDatabase.

 [think this was for Marty]

MD: Multi-lock code could be added to pvDatabase.

-> Ask MK

5. Channel and record naming rules: Decide on record naming rules (field naming rules decided [4])

  -> Completed I think - well, subject to some testing

AJ: Dot ‘.’ used by IOC as record.field separator, so ‘.’ not permitted for record names. ‘{}’ not valid in IOC record names according to IOC App. Dev. Guide (but used at BNL).

DH: “001.HIHI” is a valid PV channel name for pv request.

KK: CS-Studio allows this:

pva://channel_name

pva://channel_name?request=field(some.structure.element)

pva://channel_name/some/structure.element

GW: eget is similar: pva://optional_server_name/..then-the-same

eget -s QUAD:LTU1:880:RMAT -a run=46696 -a pos=mid

eget pva:///QUAD:LTU1:880:RMAT?

eget pva://mccas0.slac.stanford.edu:39633/QUAD:LTU1:880:RMAT?type=design  

6. Add dblink from base IOC to pvAccess server channel [2: IOC Database Links].

  Two variants:

  i.  Impl as device support. dblink option 1 [5].

  ii. Configurable link. dblink option 2 [5]. Maybe deliverable of 2 year charter.

  ** Who? **

MD: (i.) Was demonstrated in recent hangout

AJ: (ii.) Adding support for JSON objects as field values:

  field(INPB, {db:[“$(IOC):exit.A”, NPP, MS]})

  field(INPD, {pva:[pv:“xx”, req:”x…”})

  field(INPF, [1, 2, 3, 4])

AJ: Chose array of strings [NPP, MS] over structure with flags { process_passive: true, max_sev: true } because it’s shorter, easier to type

AJ: This also allows custom link types, not just “db”, “ca”, “pva”.

GW: Would this allow pva RPC calls from links?

AJ: Not suitable for database links. Links must be non-blocking.

RL: Records can process asynchronously, but links must be immediate

AJ: Device support can be async.

MD: Could also have the link asynchronously reprocess the record.

7. Simplify user's experience of search for documentation [2: Proposal for

  publishing release documentation, Reference Documentation]

  AI on *RL*: Add Cloudbees script that generates documentation links to the bundle

  jobs, run this for previous releases

  AI AJ: Create a release links file (docbuild/<version>/index.html) for

  previous versions

  AI *GW*: Update names in table

  -> Completed

  AI *Module Owners*: On your module pages, Remove the current/previous links

  since they cannot be maintained. Replace “Working Draft” with version number

  of module, which has its own numbering scheme, like 5.0.2 for pvDataCPP. Eg

  “Version 5.0.2 18/Nov/2015”

Status: Completed.

8. Rationalize and correct licensing and copyright references. [2: License and Copyright]

  AI on *AJ*: Write the one license file (using the MIT license in most cases).

  AI on *everybody*: Every module owner: Update your module to include copy of that one

  LICENSE. Update your headers to contain the above text.

Status: Completed.

9. Develop test framework. Implement test server [2: Roadmap for testing (Ralph)]

  *RL* will develop as part of the ITER testing framework.

RL: Planned delivery mid 2017

10. Combining V3 and V4

    10.1 Initial work to just create a bundled download of what we now call V4 with base:

      AI on *RL*: Change the C++ bundling to add creation of a tarfile that

      includes Base 3.15.x

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

      -> completed

      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

    10.2 Begin development to (truely) merge v4 with base per AJs list of

    pre-requisites [5: Prerequisites for Merging].

    ** Who? **

11. Gateway

  AI on *MD*: MD: to give AJ his requirements doc for Gateway to be put in pvDataWWW.

Status: completed.

12. dbGroup

  -> Write a long-term requirements summary that includes cross-IOC composite PV

  and cross-IOC lock/message-sync, so at least this goal w.r.t. easy API for systemic

  phys apps is clear

 - serving CA records wrapped with pvA N-type structures to include the usertag

  timestamp. [Hm, we're using the term "usertag" when we mean timestamp a lot. Maybe it

  should be called "timestamp."

  - Improve integration of ioc records/pvaSrv and pvDatabase - but we don't know

  what that really implies yet.

Status: Requires funding.

13. pvRequest:

   - Improve areaDetector data interface, by reimplementing IOC records of AD plus

  V4 interface.

  *Who* - KK said ORNL might undertake.

Status: No progress

----

[0] http://epics-pvdata.sourceforge.net/home.html#usefulinfo

[1] hangout event https://plus.google.com/b/114828842338418222242/events/c7fodm5p72pdab1uk58qkqp89jc?gmbpt=true&pageId=114828842338418222242&_ga=1.88975323.1188286905.1445634293&authkey=CM-nrrj3icO2vAE

[2] Minutes, https://docs.google.com/document/d/1wPH_DvmU3gZeLCIgBLDSZ4wjkvJpTm4x8iLExY9ffCI/edit?usp=sharing

Topic: Demo of pva2pva vs. CA Gateway with AreaDetector

MD: Demo of IOC with AreaDetector and QSRV, read via both CA gateway and pva2pva into CS-Studio image widgets. The data pipeline via the CA gateway is missing updates, jerky image updates, while the data pipeline via pva2pva appears smooth.

MD: pva2pva implementation reduces data copying and uses “fair queueing”. Pva2pva will still drop frames at higher rates, but updates for scalar PV will suffer much less from slow updates of large waveform PVs. CA gateway uses one FIFO for all channels, and a single server thread. Fair queuing uses one queue per sender, and threads per client.

AJ: What features are missing from pva2pva?

MD: Quite some command line statistics, but currently no PVs. No access security for per-channel configuration, but there is a global read-only option. Monitors get combined, but individual client get requests still result in get requests to the IOC. Pipelining is not passed through. No multicast support, although that might be orthogonal to using a gateway anyway.

RL: For images, can imagine use case where ‘gateway’ uses TCP connection to IOC but then multicasts the image to clients.

AJ: Anybody using multicast? BNL uses it for TV-monitor type information. Tried to setup RSRV name lookup based on multicast, but ran into network issues.

RL: CODAC uses multicast for fast global control loops.

DH: RPC?

MD: RPC requests are passed through, except in read-only mode. Gateway would control which clients are allowed, once access control is implemented.

MD: Plan for access control is access control lists.

Topic: QSRV Group Support

MD: Demo sends ‘circle:x’ and ‘circle:y’ PVs as well as a ‘circle’ group, which is supposed to be atomic operation where sqrt(x^2 + y^2) == 1. IOC has separate records for ‘circle:x’ and ‘circle:y’, which pva serves individually as well as a ‘circle’ group structure with elements .x, .y.

MD: Groups configured via EPICS record info tags:

record(calc, “circle:y”)

{

  # Add this record’s VAL to the ‘circle’ group, place it in element .y

  info(pdbGroup, “circle|y=VAL”)

  # Update of circle:y.VAL triggers subscription update for ‘circle’

  field(pdbTrigger, “circle|y>*”)

MD: All PVs of a group need to be on same IOC, but may be in different lock sets. Group locking does require 3.16.

MD: Groups support get and monitor, but not put.

MK: Is there an ‘angle’ record, based on which the circle:x and circle:y are computed?

MD: Yes. circle:x FLNKs to circle:y, which then triggers the group monitor.

MD: Second IOC uses pva links to read “pva://circle.x CP” and “pva://circle.y”. Client subscribes to complete “circle” structure, and pva links then read “x” resp. “Y” element of that structure.

MK: Show complete “circle”

MD: pvget circle shows structure with elements “angle”, “x”, “y”. IOC will show group information on startup. Currently no IOC shell command to show groups.

MD: Demo proves atomic updates. CS-Studio formula for sqrt(circle.x^2 + circle.y^2), using the group structure, is always ==1. Formula for  sqrt(circle:x^2 + circle:y^2), using the separate channels, is not always == 1.

MK: Have you received feedback?

MD: Not, yet.

GW: Groups are based on records. Can I add description or unit fields?

MD: Units are translated into group, and stringin record can be added as field. Any dbChannel can be mapped into a group. Specific example?

GW: Assume one record for beam x position, one for beam y position, ... Group would take x, y, sum, pulse ID from different records. How to add .DESC?

MK: Why not use a pvDatabase pvRecord?

MD: Wanted to use an IOC with existing records. Maps dbChannels into NTScalar or NTArray. Does at this point not allow to create an NTndArray.

MD: Also supports extracting nanoseconds from timestamp into the userTag of the V4 timestamp, for sites that currently encode pulse ID in V4 timestamp’s nanosecs.

(break for lunch, will restart at 13:30 CEST)

3.16 Lock

Integrate 3.16 lock with pvDatabase. Integrate lock pattern and API being

  integrated into 3.16 with pvDatabase.

MK: Group locks in pvDatabase? No progress.

AJ: Are locks internal to record, or lock set of records?

MK: Within record.

pvRequest: General discussion

RL: field request definition is quite well defined. But specification of monitor - like how to handle monitoring of a field contributed by a dbGroup - is not defined. There is no definition of this behaviour.

MD: Unclear how to parse pvRequest when implementing QSRV

MK: See developer’s guide http://epics-pvdata.sourceforge.net/informative/developerGuide/developerGuide.html, 17. pvRequest and pvCopy:

“A request argument has the syntax:

record[option,...]field(fieldDef,...)putField(fieldDef,...)getField(fieldDef,...)
OR
fieldDef,...”

DH: If you re-order the fields, pvCopy will return structure in the requested order, not the original order.

AJ: Does order matter?

DH: Yes.

KK: But python client returns dict(), so no order

GW: Spec says order does not matter.

DH: Normative types are supposed to follow the order given in the spec.

GW: I thought order in NT spec was just an example.

MK: Order may match the order in which fields were listed in the request, not the order within the original structure.

DH: pvCopy results in order from the request. Other providers return the order of original structure. http://epics-pvdata.sourceforge.net/alpha/normativeTypes/normativeTypes.html states: “The order of fields matters. Although the Normative Types pvData binding allows for access through an introspection API, senders must encode the fields in the order described in this document.“

GW: NTtable was the original motivation for requiring a fixed order to match label[i] to the ith element of the value structure

    string[]   labels         // column labels
   structure  value
       {scalar_t[]  colname}0+ // 0 or more scalar array instances, the column values.
KS: Why not array for value?

MD: NTtable pre-dates ‘any’ data type. Otherwise could be any_t [] value.

GW: NTcomplexTable would allow value array where each ‘column’ has different type. Need Murali to discuss because of use for archive data retrieval. Murali is updating proposal with variant union.

AJ: pvaPy NTTable apparently uses a dictionary for value with keys “column0”, “column1”, ..

MD: Order fixed by server reduces the number of structure variations for different clients that only differ by order. Fixed order allows server to use bitmask for each client instead of having to keep structure for each client.

??: If result was in different order, shouldn’t the “NT..” type ID be stripped from result?

KK: pvaPy might internally use ordereddict(), which would preserve order

MD: .. we don’t know what it’s using internally at this time

AJ: Does pvCopy receive the target structure, or allocate it? How does it affect the order?

DH: pvCopy creates target structure based on a request. Then copies into that target structure

MK: .. using bitset of what had changed

Interim Conclusion: Order does matter, no change to spec.  pvaPy’s use of dictionary for structure definitions may be problematic, AJ is filing a Github issue to find out.

??: Get vs. put vs. RPC

MS: Server provides structure via introspection.

DH: Command-line usage gets request from what user entered without first introspecting the server’s structure.

MK: Server always needs to create introspection interface for each client.

MD: Server could only create bitmask because fields are in fixed order.

MS: For client, the need to create pvRequest is a bother. Predefined set of pvRequests ala V3 DBR_.. would be more convenient and get us fixed order.

MK: Need to support both cases, server-defined as well as client-requested order?

MS: Client library could have layer that preserves order.

MS: Clients reading NT types should always use a helper library. That lib constructs the proper requests with correct order.

MD: That would still allow clients to request in any order, so no way to simplify the server code. pvCopy helps with the copy, but need to copy instead of bitmap results in slower performance. Fixed order would allow memcpy or non-recursive unchecked copy.

MK: Does this mean client cannot pick elements of structure? It may receive more than it requested?

MD: Yes, may receive more than requested. Sender defines the structure.

DH: CA provider did this. Before my update last week, it returned more than requested.

MK: Change to specification?

GW, MD: pvRequest spec doesn’t say what will actually be returned. May return more than requested, may return in other order.

AJ: Nice NTNDArray server implementation ought to honor the request and not return the whole structure when only one small field was requested.

Conclusion: Sender (not necessarily server!) defines the structure: order as well as content.

pvaPy Discussion with Sinisa

KV: SNS has been using pvaPy for detector calibration/analysis tools. When used with multiple detectors, higher data rate (>50kB/sec), pvaPy doesn’t receive all the data. Fields in PV structure are missing, specifically fields which are arrays differ in length, when they should have the same length. Resolved a seg fault. Can the python way of turning PV structure into dict() be optimized?

SV: Difference between pvaClient-based pvaPy and earlier version?

KV: No

SV: Do you have test data server so I can reproduce?

KV: Not right now, but could create that. Could also help with bug fixes.

SV: I can incorporate changes that you provide, or try to look into it if you provide simulated data server. Otherwise no way to duplicate high data rates, nor time to create my own simulator.

MD: Recently tried pvaPy with ‘group’ development. Created github issues as result of high data rate scalar test.

SV: Have merged your pull requests.

MD: Have example for reproducing the issues that are still open.

SV: Happy to look at any examples for reproducing the bugs.

KV: In addition to bug fixes, we’ll also need it to be faster when handling structures.

SV: Note single-threaded nature of python, GIL.

MD: Use numpy instead of dictionaries.

MK: What are you actually doing in the python client?

KV: Receiving raw detector data. Processing it for display in python code. Processing currently faster than receiving data. For example, processing raw neutron events into physical location.

SV: Good. Need examples to proceed.

Technical things outstanding

Review roadmap email

GW: [showing email that listed V4 tasks: gateway, dbGroup, pipelining, multicast, pvAccess query language, developer’s guide]

MK: Working on developer’s guide. Also investigating memory leaks.

Wednesday “EPICS Development Roadmap” session

Plan: Marty online, and all who can in person. AJ to show JSON link proposal, MD to show pva2pva image demo.

Towards merging v3 and v4 releases.

So far our story (decided in last f2f) is that v4 will be released with one or a set of compatible bases. Review pros-cons. We'll inevitably get this question again at the EPICS meeting. Want us on the same page, with a clear and solid answer. Preferably with a deadline.

AJ: [slide of pros and cons, Merging V4 into EPICS Base, pp8-10,

http://epics-pvdata.sourceforge.net/files/talks/2015/ANJ-F2F-201511.pdf]

GW: Really about combined announcement email and single download.

TK: Need clear message “V4 is EPICS”.

MD: Many components of V4 are like synaps. Separate from Base but universally used.

AJ: EPICS “3.17” could become “4”.

MD: Technical issue or marketing?

GW: Marketing is important on this

RL: Will need two downloads: “EPICS V4” that combines latest Base & V4. “Baseless EPICS 4” that only has V4 code for do-it-yourself building with older Base.

MK: Just one where a RELEASE ‘BASE’ link can be set to an existing (older) version of base

RL: File structure is different when using external Base.

Conclusion: We intend for 3.16.x to be the last pure V3 release. After that we will provide an “EPICS V4” download that combines what’s now called ‘Base’ with what’s now called ‘V4’. There will also be an alternate download without ‘Base’ for building against specific supported releases of Base.

Bob's EPICS roadmap items.

0. Integration of pvaccess and the epics database. Eventual full replacement of RSRV.

MD: Not difficult to start IOC without RSRV. Already done in unit testing.

1. V4 will be bundled with a compatible base version.

Yes.

2. Support for v4 streaming will be added to cs-studio

KS: Beamlines would like to display data that’s streamed from services

GW: Goes with 4:

MD: Also goes with 3, or when fetching archived data

KK: What does it mean?

MD: When retrieving data from pvAccess, client library needs to acknowledge receipt of each monitor (when the application releases the monitor) to trigger pipelining of the next item.

SH: Useful for data acquisition (saving to disk), not display.

MD: There is new pvAccess API to configure window size and a “pipeline” option in the PV request. The ‘release’ call on a received monitor moves the pipeline window forward. Non-display clients may need to be updated to handle the received data before releasing the monitor. Offers performance gain because client doesn’t need to copy: Receive, handle without copy, release.

SH: For SNS type detector data, display client can be lossy but data acquisition client could benefit from pipelining.

MD: PV for pipeline buffer size to throttle neutron rate via e.g. slits?

GW: ChannelFinder client needs to receive all names, not dropping anything.

Conclusion: A pvAccess-based ChannelFinder client needs to set “pipeline: true” in its request.

3. Smarter integration of Archive Appliance to V4 n-types.

  + numeric data stored in aggregated form, and served using NTAggregate (ie statistical sample)

  + data stored with meta data (eg timing frame/ pulse-id). Search by meta-data

  + add image data store - as NTNDArray

  + store fault data

KK: Archive Appliance treats pva just like CA.

HJ: .. using policy file to read .RTYP, .SCAN, .HIGH, ..

MD: In principle, could use DBE_PROPERTY for CA or the structure support of pvAccess to only subscribe once.

MD: Extra pieces of information (HIHI, PREC, ..) are stored as name/value strings(!).

KK: What does ArchiveApp store for pva://some_structure? Written as blob?

MD: .. need to ask Murali

4. AreaDetector

  + Use v4 multicast for processing chain fanout. AD nodes operate directly on NTNDArrays.

  + add compression to utilize sparsity of areadetector data

  + Put AD processing right in the pvDatabase

MD: MS has been working on reliable multicasting, separate from pvAccess.

5. Motion control

  + Add fly-scan support to CS-studio

  + Add event based scan triggers [to motion control record]

  + Add inter-controller triggering support [to motion control record]

KK: Scan server can do this if speed of CA/pva is sufficient

Faster operations require hardware triggering.

AJ: Unclear what else is desired

6. Further develop the “meta data store”.

Add support and integration with a high performance filesystem for beamline experiment data.

GW: Meta data store holds data about the experiment with links to data, but separate from the actual data. Currently difficult to read both metadata and experimental data in combined request.

KS: Data broker does this, querying MDS + Archive + .. to return everything as HDF5.

GW: <at this point spills coffee, swears>

.. topic returns to pipeline ..

KK: Is this about reading a PV that looks like array, but each monitor is really a line of an image, so received monitors need to turn into an image?

MD: Monitor’s “finalized” state indicates end of one data set.

MD: For client, ‘pipelined’ monitors would in some cases append instead of replace with the new update.

Dave’s training

DH: Three practical sessions interspersed with slides.

  1. Run examples, cmd line tools.
  2. Extremely simple RPC Service. Worried about this taking longer than expected, even though template and solutions provided.
  3. NTNDArrayServer. Template, instructions on what to add.

DH: Mixed results from online ‘docbook’ style presentation setup. PPT might have been easier in the end.

TK: Started with 35 registered participants, now actually 25

AJ: Need help?

DH: I’m OK

TK: Training where we’re now. Wednesday in auditorium.

.. Meeting ends 17:50