Agenda

1) first topic is pvAccess gateway. Ralph to lead discussion.

2) Marty will give brief demo of pvaAsyn accessing simDetector from

areaDetector.

It will show CSS as OPI for controlling areaDetector.

And then pvget, pvput to access the pvaAsyn PVRecord that communicates

with  portDriver for simDetector.

It will use ImageJ to display images.

It will end with : It would be nice to have css get image via NTNDArray

plugin that David has developed.

3) David will describe NTNDArrray.

Minutes

Scribe: GS

topic: pvAccess gateway http://epics-pvdata.sourceforge.net/doc/pvGateway/requirements.html

RL: long list requirement. basic: any single gateway serve everything? Probably 2 things

RL: put CA PVA client part both end on server/client side. and configurable

RL: redundant gateway, stability, and traffic sharing

RL: service side binding interface

RL: data part support: pvData + NT

RL: image transfer

MK: gateway subscribe to everything

RL: does not scale well big data/ high rep rate/

RL: gateway does not which part of part is danger, do not see monitor band, update rate

BD: Both 3.15 and pva see rate on both side?

RL: yes

BD: then why not gateway?

RL: gateway should be transparent

BD: then make gateway configurable

MS: special gateway for special use case

RL: gateway should do autho/authn? or transport A/A thru?

BD: does not make any sense

RL: token based for example

BD: then are the A/A same?

RL: token for remote secure access, then gateway has to transfer token

GS, BD: use NX on top could be another choice

RL: does not fully satisfy all use cases

RL: not sure to catch token based thing

RL: cross database, data layer access there is no token based mechanism

RL: gateway has to have debug shell

RL: need 2: low level one does not understand data, + high level does packaging data, understanding data, caching, … put web service on top of high level one? Based on Java framework; low level one would be in C++, switching msg on low level, no API (pva+ca) allows client create msg on network, do raw data transfer over network

AJ: GC for high level, and MJ for low level since they both are here

GC: between BNL/FRIB, will have service transfer live data with pvManager thru JSON

        limit with pva is only thru pvData type

AJ: low level API need to get package and forward package

MJ: need add on to forward msg

MJ: is there a general tool existing?

AJ: there is one, just pass thru package, does not do aggregation, …

RL: low level one does not have to cache, se/deserialization data

AJ: might need sort of deserialization

MD: protocol specific, not general enough

AJ: split current doc into 2?

RL: make sense.

BD: what’s low level one?

RL, AJ, MD: connection aggregation

MJ: pvRequest package has to be identical for same connection

GS: how about channelRPC?

AJ: could not be shared

AJ: anything one?

RL: redundant one?

MK: put it low priority

BD: one die, and comes back later. How to handle reconnection?

RL: if both gateway have the same IP address, then …

RL: will ask tech-talk

BD: low level gateway has higher priority, multiplex incoming request…

BD: this has  higher priority than high level one

BD: who and when?

SE: PSI has one running (CA version)

GC: Windows is rapidly change .net, so does C#

BD: is everyone happy with current gateway?

RL: yes, except @PSI (this is why  the C# version)

BD: give the gateway to core team? How about iter?

RL: v4 is not relevant to iter before 2016(?)

BD: high level one, GC is working one. Is that really funded?

GC: we should think. No one works 100% on it.

RL: still question for low level, API to di thing

MD: not to written with existing API

MD: Difficult part: understand headering, and connection aggregation

RL: CA + PVA? Would be nice to get rid of GDD, CAS, etc. Can share patterns, connection handler etc, but probably can’t use just one app for both.

MD: Agree.

RL: Ok start with PVA, then look at feasibility of doing a CA version too.

MD: Can share development time & some code, but will run differently.

-- break --

Demo: MK on pvDatabase interface to AreaDetector.

MK: CSS from BNL, Images display using imageJ, want to motivate DH’s path for images. Runs AD with simDetector, IOC loads 2523 records (228 waveforms, 630 longin, 289 ais etc. Also running pvDatabase talking directly to the same AD ports. SimDetector has ~100 param’s, MK picked a sub-set for demonstration purposes. Can do a pvput to his pvDatabase records to change multiple SimDetector param’s at the same time. Want to upgrade to viewing NTNDArray via pvAccess instead of ImageJ through CA. MK’s interface to AD is using the same Asyn interface to AD that devEpics uses for the standard AD IOCs.

Demo: DK gives a demo of NTNDArray

NTNDArray normative type reviewed.

GC: NTNDArry is just a dump of areaDetector NDArray. And only areaDetector will be the only the only producer. It’s specific. CSS has generic widgets.

We all decided we do not need a separate V-type. Instead we implement arrayOf(), imageOf() and attributeOf() on our specific type. Then the user can decide to build up the app using generic widgets.

Demo: DK gives a Union demo.

(no comments)

New topic: V4 integration

AJ talking

Base 3.15 contains many features since 2008

ITER plan to use 3.15,1 in V5 of CODAC Core.

Beta release due sept.

Concern about late changes.

no locking

Andrew will give list of what goes into 3.15.1

How long will be supporting vxWorks 5.5?

Will V4 ever support vxWorks 5.5?