1. Features of v4.4 cont'd.
Lets continue our discussion of what can be contributed to features of
Short reports on expected contributions to 4.4: Ralph, Dave, Nikolay and
2. Clarification of planned support for aggregate data gets in 4.4.
dbGrp Can this be designed so that it can be added to a 3.14 IOC,
though less functional, than a 3.15 IOC w.r.t. locking.
Gather. Confirm this is functionally different to dbGrp, and if it
is, can it be moved to pvDatabase.
Present: AJ, MK, NM, TK, GW, RL, GS
1. Features of v 4.4 to be demoed at BNL meeting (cont’d).
NM: As you know, NM has a client-server interface using pvData, connected with CS, using V4 RPC (instead of XML RPC). Doesn’t use normative type yet, as presently defined. So replaced XML-RPC with V4 RPC. Now working on a new archiver service using mongo-db and replaced indexing scheme. Client side in CS and python will remain unchanged. It’s the communication between V4 server and mongo-db that’s now using V4 RPC.
Archive client (in CS) → [V4 RPC] → V4 Archive service → [V4 RPC] → Mongo-db.
Summary: NM will present EPICS V4 based archiver service.
GS. Masar was tested with the 4.3 version using the Gather library of the Masar repository
GW: it would be nice to distribute the Gather library together with V4
RL: Intended scope of Multi-value was changed when it was moved to dbGroup in the pvaSrv application. Source is currently unchanged, but is not currently built in pvaSrv.
MK: We need both (V3 IOC for getting multiple records atomically), but also the remote access capability, should be in pvDatabaseCPP.
GW: Exactly, need both.
RL: Normative type?
MK: Uses NTTable
GW: Should be upgraded multi-channel array type.
GW Clone multi-gather code from pvaSrv, insert into...
GS: 5K PVs is probably limit for the Gather library
GW: do we need 5K PVs ?
MK: we need NTMultiChannelArray to a Union array, so it can handle scalars and waveforms.
NM: asks; the gather library inside MASAR only handles v3, is that right?
GW: The plan then will be to take the multi-value now in pvaSrv, which does handle
both PVA and CA PVs, and base the new Gather system on that. That new system will
return a (redefined) NTMultiChannelArray, which will be adapted so each channel can
be a scalar or array (based on union) - so it can handle single values or waveforms, or
GW: we need a redefined NTMultiChannelArray and a new Gather library based on V4.
Summary: MK will (after the “proposedChanges” re-writes) turn to creating the new Gather system, in pvDatabase, which returns the new NTMultiChannelArray.
Important implication is that pvDatabase is part of v 4.4.
GS: is there any time frame for v4.4.
MK: Yes, it’s the fall EPICS meeting in Paris.
GS: it would be great to present the status of the Python interface in July
GW: it can be presented via hangout by Sinisa
Summary: AJ or SV (via hangout) will present the python interface.
TK: Unfortunately will not be able to join us. Presently not enough people to work on V4.
Suzanne and some people are working on DISCS.
DH: (from email)
1. For 4.4 I'll obviously contribute exampleCPP, updated if necessary for RCPClient changes.
I'm currently looking at adding what I've done for NTNDArray to normativeTypesCPP. If the latter forms part of the release then the former is I guess a feature to be contributed.
Afterwards I will look at const in pvData, but that's not going to make 4.4 as I understand the release timetable.
2. I plan to be developing area detector transport against 126.96.36.199 and we'll be using this version at Diamond for some time, so it's very important that V4 builds against this even if 3.15 is needed for some features like dbGrp.
Meeting ends 9:00 am PST.