AJ on Goal #1: I feel the goal is a little bit too much, since it might break backward compatibility.
BD: It’s not necessary that the new code will live in the database.
BD on Goal #2: The goal should include unreliable multicast/broadcast support for transferring images (or other data).
BD on Goal #5: Directory service (ChannelFinder) is complete.
GW: I this it still needs some documentation I think. Let’s not get into that now.
BD: pvManager “server” (as a library) in C++ would be nice to have. C++ allows Python binding.
AJ: Suggest to implement it directly in Python.
MA: cothreads already handle connection management.
MK: James and I spent some time to integrate pvData/pvAccess to cothreads. But we did have time to finish it.
MA: How would cothreads know to what protocol to use.
GW: We have a plan (AI on MS) to solve this.
MA: gives an example of API we wants to have in python
im = get(“imagepv”)
im.value -> numpy.array
im.height -> 320
im.alarm.severity -> minor
MA: on monitor caching (already implemented)
camonitor(“pv”, callback, merge_updates=true)
BD: I want this functionality for pvAccess.
MA/GW/MS: Limit monitor updates on the server side.
BD: We agreed to have a pvManager on the C++ server side.
Discussion on local/middle layer (kind of gateway) pvManager.
BD: 2 phases:
- 1. phase: middle layer pvManager in Java (end of this year?). Replaces gather.
- 2. phase: C++ pvManager as a library (that lives in the IOC)
We are not ready for the users. Make EPICS v4 easier for new code developers.
New topic: Interop with EPICS V3
Michael Davidsaver Requirement to retroactively timeStamp value.
Not clear. Must find out what Michael means.
Asynchronous timeStamp requirement. Must also find out what is meant.
AI DV will find out details.
Interop with V3 IOCs.
DZ must specific details about platforms.
Discussion: what versions of vxWorks?
What to document as goal?
Can we say vxWorks 5.5 or 6 or what?
Matej and Andrew will see that pvData, pvAccess, and pvaSrv will build on 5.5 and 6.
Dirk will test on vxWorks 5.5.
Discussion about meaning of channel, process variable, etc.
AI: BD will start glossary.
What to do about code and existing documentation? Future discussion.
Goals for detector/image data handling (David Hickin, Dave's document)
Suitability of monitors for data acquisition
Is it possible to use V4 as the data transport between AD plugins?
Ulrik: how about replacing AD plugins with V4
AJ: plugins could be replaced by local V4 "services" that publish a new
V4 "record" and process the data
MK: it is possible to implement this. However, memory usage is an issue, and
releasing the memory.
High-performance (parallelization) discussion. How much is this in the scope of the working group.
NR: Diamond has an interest in going to the direction
GW: please describe how to use an IOC in a high-performance context.
GW. are you willing to write that?
Area Detector is using 20% on many cores, but no output. Maybe a locking problem in AD
Ulrik: we are instantiating a LOT of plugins
BD: has anybody used AD on GPUs
UP: like proof-of-principle but not really exercised. There are OpenCV plugins existing.(couple of years)
People are using it for sample positioning (rather than analysis)
DH: what is the goal for the next year? What should I be doing?
AJ,GW: what already exists is potentially useful for other sites
Charter objects largely done.
Future work: optimize the speed to match the goal.
Make a module (plugin) of what has already been done
MK: do configuration (too) with V4 mechanisms. At the moment only the image data is using pvAccess
GW: write a configuration front-end?
AJ, etc: usefulness is not obvious
GW: Image archiving?
Next steps for David:
clean up the implementation. Use Marty's record processing code to implement a production
quality service. Present code is proof-of-principle.
Windows implementation: at the moment nothing of V4 runs on Windows. There should be an implementation
of at least the essential parts running on Windows. PVA server on Windows is a requirement.
AI on Matej: implement pvCommon, pvData, pvAccess pvaServ port for Windows. (Win7)
Clarify the split between image (NTImage) and NTNDArray (scientific detector data structure)
GW: possibly three NT types for image-type data
-leave NTImage (AD-derived)
-Nikolay proposes a new type for generic image data
-a third type to contain scientific image data. Ulrik writes. Streaming to HDF5 as a goal. Contains
only data, no information about how to render the data image for display
Nikolay would like to add this type into the image archiver.
Look at adding metadata to the above type required for rendering
NTNDImage shall keep its present definition
One more normative type for multidimensional binned data sets.
NTImage needs to be defined (new type, not the AD-based one)
Meeting ends 17:10.