V4 Telecon/Hangout 2013-12-10


1. Summary of the areaDetector meeting 20 mins, *Bob*, *Marty*, *David*
  Work we've been signed up for.
  How will areaDetector work affect EPICS V4 priorities?

2. Short demo of real world examples of use of a model service, and some
  uses of relational database and name service too (Greg, 35 mins).
   I'll just use command line examples (though most are embedded
  in applications code) to show applicability of normative types and arguments
  to physics services. This is also by way of showing requirements for
  some further work on the nature of a RPC channel.

Attendees: GW, MK, GS, MS, SV, AJ, GC, DH

Scribe: AJ

Chair: GW


1. Summary of the areaDetector meeting

MK: Very successful mtg. Mark Rivers was managing AD as monolithic module. Has now been moved to github and split into parts, core plus each camera as separate module. MK has checked out code and got it to run. Active members: Ulrik from Diamond, David Hickin getting his AD/V4 plugins solid & robust and merged. Looking to get V4 working well with AD.

GW: What is your role goi to be? Is this orthogonal to V4? Should we continue to use SF?

MK: No problem with using both DVCS at once, no reason to change. AD just references the V4 modules and build against. This should be the killer app for V4.

GW: Agree, the field that AD addresses will be most heavily developed.

MK: Simon Ebner - involved with FEL at PSI Looking to stream detector data in parallel, looking at 0MQ and push-pull, Matej will try to implement in pvAccess.

GW: Relationship between 0MQ and PVA?

MK: Additional?

MS: Some things 0MQ can’t do; layer above TCP, enthusiastic users and simple examples but details don’t always work like that in real life.

SV: I looked at 0MQ, highly performant but uses proprietary stuff, not open protocol so wary

MS: Messages encapsulated in header, forces you to use their stuff

MK: Real PSI requirement is push-pull.

MS: Have a task to do, push that. Clients pull, do work then push the results. 0MQ takes care of software details

SV: Many software packages do the same thing, 0MQ’s proprietary protocols are disadvantage

MS: Advantage is performance. SV+1

GW: Sounds a bit like Multicast?

MK: Want to guarantee client gets every part.

MS: Sounds like multicast, but isn’t. Does provide reliable multicast. Want more control.

SV: Have to think about other things - language bindings for instance, other tools have Python, Java bindings etc.

GW: MS, what’s your goal in the short term?

MS: Many things already implemented, we wouldn’t have to reimplement it.

MS: Looking to use 0MQ to transport pvData. Talked to Bob to get use cases.

GW: Looking for Use Cases documents

MS: Don’t want any surprises when the code is done

AJ: Would like it to be clearer how 0MQ will “integrate” into pva?

MS: Simon gave a proposal for that. Sent it to BD, who said it implemented his requirements.

MK: Sees issue as can we [pvaccess] provide push-pull?

MS: So, we need to see

SV: Doesn’t think we need to implement stuff, just convert your data to the other protocol [amqp/0mq - pvaccess and vice versa]. SV gave a talk on that at EPICS meeting. [to add ref] and to this group beforehand.

MS: PUSH/PULL = Parallel Transport.

SV: Have to talk 0MQ protocol to use their software, so talking about converting data?

MS: Can wrap pva packet inside 0MQ.

SV: This is similar/identical to what I talked about using AMQP, have already done.

GW: Can Sinisa look at the NTImage/replacement definition looks like, see if your experience helps?

SV: Sure, point me at the documents and I’ll comment on them.

DH: We discussed the type at some length, carry on with something similar to what we have, efficiently only send attributes that change (currently using UnionArray). Dropped Bob’s NDArray proposal, rename NTImage to NTNDArray, use that to wrap images.

SV: Exactly what I used, wrapped NDArrays.

MK: This 0MQ: David can already saturate a 10Gb link using pvAccess. Let Matej look at either reimplementing push-pull in pvAccess or make use of 0MQ to do that.

GW: Need to move on, come back to these in January.

AI on MS: Formulate how to get the functionality of messaging service’s (eg 0mq’s) “push-pull” function, into a pvAccess network. Possibly done by a special pvAccess channel provider.

2. Short demo of real world examples of use of a model service, and some uses of relational database and name service too

GW: Demo given to physics group. [Will send out stuff later, not minuted]

[Long discussion with GW, GC & MS about how to be able to easily extract part of a data structure, NTTable or NTMap don’t do what GW wants]

GC: CSS doesn’t know how to handle the relevant non-normative type

MS: Best effort might be to convert to NTTable?

GW: Need a way to indicate a structure is not an NT.

MS: We have the id.

GW: Message output from eget is wrong, shouldn’t say “unsupported normative type” at all. Can we have different levels of loquaciousness from eget?

AI on MS: Remove the above message.

GW: Eget can’t currently read PV names or options from stdin

Lots of positive feedback on EPICS V4 from physics guys, this is nice way to look at data.

Liked meaningful error messages from stack.

GC: Any interest in CSS supporting this stuff?

GW: Very much so.

GC: No users currently asking for pvAccess features in CSS, so it’s not developing.

GW: Want physics group to start using CSS. Demoing in command-line, but most uses will be in Matlab or Python code. If SLAC adopts CSS group has to decide how to develop apps based on that.

GC: Want to figure out if/how pvManager could be used from Matlab. 2 aspects, rebroadcast pvManager output using pvAccess, or using web sockets. No users asking for this stuff yet.

GW: SLAC & PSI both want 1 line of matlab to return orbit data.

New Topic:

DH: Did we discuss developer meeting, March 12-15?

GW: No, probably discuss through email.

DH: Probably means 12-14, typo from Bob

12-14 March, proposed dates of developer meeting at CosyLAB.

Meeting would include


AreaDetector WG



GC: CSS talked about date previous to that, travel organization problems.