1) first topic is pvAccess gateway. Ralph to lead discussion.
2) Marty will give brief demo of pvaAsyn accessing simDetector from
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.
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?
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.
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.
New topic: V4 integration
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.
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?