EPICS V4 Telecon of 14/Jan/14

Agenda

======

0. Preliminaries (5 mins)

1. Brief status reports (all)

2. pvMS [2]. (Matej)
  Status, plan for pvMS, anticipated use cases.

3. pvAccess Status. See December's thread [3]
  How shall we proceed to firm up the specification of the status of
  server-client communications? For instance, communications of status of individual parts of a

   communication (like parts of a dbGroup, or parts of a complex operation of a service where
  some parts succeeded and some failed, eg set large number of magnets to set of values) aren't
  specified completely enough for dbGroup to proceed.

4. pvRequest. [4]
  How to proceed with addressing missing specifications on collections
  (like dbGroup) and other matters. Probably by email discussion.


Cheers
Greg, for Andrew and Greg

[1]
 http://epics-pvdata.sourceforge.net/home.html#usefulinfo
[2] pvMS thread,
 http://tinyurl.com/mzho7k8
[3] pvAccess Status thread
 http://tinyurl.com/krex788
[4]
 http://epics-pvdata.sourceforge.net/informative/pvRequest.html

=======================================================

Minutes

Present: DH, GW, MK, MS, SV, AJ, GS, GC, TK

Chair: GW

Scribe: AJ+GW

1. Brief status reports (all)

https://docs.google.com/spreadsheet/pub?key=0AiY7lwlw4Y4XdDNBVzRUN0FOMGw1Ty1pZk9MeGtPVnc&output=html

AJ: Working on Jenkins build working for areaDetector “2.0”. There is a mailing list for the areaDetector work.

DH: Working on NTNDArray, will publish a public doc shortly with proposal for definition of NTNDArray. Next Tighten use of const in pvDataCPP. Archive service now using MD’s API.

Longer term: Make  prototype areaDetector image transport  PVA Client and Server more robust and release it. Then integrate the image transport code into areaDetector.

GC: Coordinating V4 and CSS, and making CSS dashboard.

Matej:

MS: 2 things on CSS: 1. RPC plugin - so you can connect a BOY screen - enter parameters - and then execute on an RPC service. Prototype just completed. Seems some things may be missing in NTURI; it seems that there is no standard way to define case of many possible operations with the same RPC PV.

2. pvAccess plugin - added support for v-types, 2 more N-Types supported.  Would like to add NTNDArray- depends obviously on plugin and type definition.

GC: did you take out conversion from pvManager into a sep lib?

MS: It’s still all bundled.

GC: Re NDarray, I added extension to get array information.

MS: cool!

MS:  Adding multicast library.

Also just working on stability.

MS: On the Windows port - everything compiles, but it breaks. We need continuous build; will be set up at CosyLab (under PSi contract).

AJ: Also will be setting up Windows Jenkins Build, but only for C++.

Guobao:

GS: No V4 work being done now.

Marty:

MK: Working on some AIs mostly coming up to speed on AreaDetector.

Working on Documentation for  pre-requisites of areaDetector.

Next: think about what V4 can offer areaDetector.

MK: w.r.t. how RPC may be patterned: now that union is implemented, the way we implemented RPC should be redefined in terms of ChannelPutGet. This is because now we have a variant union, what can be returned can vary call-to-call.

MS: True, but RPC’s API is very easy to use, and reimplementation in terms of ChannelPutGet may be hard.

SV: However RPC is done, the top level API must remain very easy.

AI on MK: Write email describing how RPC functionality may be implemented by channelPutGet.

SV: Put Python code into repos (“pvaPy” package). Made build system. Added implementation for monitors! Next: documentation.

GW: Better & more explicit error messages in status string. Reviewing AIs, created list. Next: Normative Types. Using Model Service to suggest what’s needed: Errors, and Units.

AI on GW: Share access to dashboard spreadsheet.

2. pvMS [2]. (Matej)

MS: Simple UDP multicast protocol, FPGA-possible. Unreliable, so missed packet = lost data, no resend.

DH: When monitoring you only send changed fields, problem.

MS: When multicasting we send everything to avoid that. No server as such, stateless protocol. If subscriber starts before publisher there is no problem, no connection management needed.

GW: Is DH intending to use Multicast for AreaDetector?

DH: Worried about losing data/frame.

MS: If you need send-on-change you would need reliable multicast; possible but not fast, this is not a magical solution.

GW: Matej, could you give us a short getting-started example, explain which use cases are appropriate?

MS: Can write a document. Examples and implementation all in current pvAccessJava code.

AI on MS: Write short document on getting started with pvMS.

AI on GW: Review pvMS for logging.

3. pvAccess Status.

4. pvRequest.

[Combined topic]

GW: Will ask Ralph to review pvRequest and also think about the pvStatus for returning status from dbGroup objects.

Close, GW will ask people to update the status spreadsheet.

Meeting ends, 9:29 PDT.