Agenda for Day
9:00am Application of V4 architecture in High Level Applications Bob Dalesio
9:15 am interoperaboility V3 V4 Marty Kraimer
10:00 am Use of V3Channel for Gas Analyser at Diamond, David Hickin
10:30 am Beam line requirements for scanning, data acquisition, and analysis, Daron Chabot.
11:00 am synApps, record types and data. Tim Mooney.
11:30 am Use of areaDetector and synApps for biological data analysis. John Skinner
12:00 noon Scan system for experiments at SNS. Kay Kasemir
snuck in talk: PXdb, John
1:30-3:00 pm Version 4 IOC planning to support beamline controls. Discussion. Bob Dalesio.
3:30 – 4;00 break
4:00 – 4:30pm Normative Types review. *Greg*
* EPICS URI. Review of use of the EPICS URL. *Greg*
4:30pm – 5:00 Proposal for "editing down" and implementation of N-types *Michael*
NEW TOPIC: Application of V4 architecture in High Level Applications, Bob Dalesio
Talk presentation Powerpoint at: http://epics-pvdata.sourceforge.net/talks/2012/V4EPICSKorea20121023.ppt
Gave a summary of how EPICSV4 is adding facilities for building data services. Showed for beamline
experimenters, where in their experimental control system EPICS V4 service would fit and what they
NEW TOPIC: interoperaboility V3 V4, Marty Kraimer
See sections Overview of iocCore, pvAccess and pvIOC at:
CAV3/V3Record <==> pvIOC/pvAccess :
NEW TOPIC: Using V3Channel at Diamond, David Hickin
Showed how you change a V3 IOC boot script, dbd file, and its makefile to add v3channel.
Then he used an example of using pvput (with pvaccess on the wire), to write to
a V4 scalar, attached to a V3 channel on the IOC.
He then showed monitoring (pvget -m) a V4 array, which in the IOC is attached to
a V3 waveform.
NEW TOPIC: Beam line requirements for scanning, data acquisition, and analysis, Daron Chabot.
See talk at: http://epics-pvdata.sourceforge.net/talks/2012/bnl_10_18_12.pdf
Next generation detectors are of order 1-4 Mpix@s-24 kHz. == 40 Gbps. Another example: LBNL FastCCD 2 Mpix @ 2.2 kHz = 6.4 Gbps.
For X-ray Photon Correlation Spectroscopy (a common technique) people are looking to
analyze 40-60,000 frames per second and making correlations between frames.
So, presently it takes only 1 or 2 sconds to take the data.
Then presently the pre processing of the images (which detemines whether there was anything interesting in the data) takes about 15-60 mins. They want to get that down to seconds.
Things V3 is missing for beamlines
* A way of managing data that is represented in Reciprocal Space (a coordinate transform of the data), which is common for beamline physics. A system which maps coordinate space to reciprocal space.
* "Asynchronous timestamps" - where the time at which data was taken is attached to the data after the fact. That is, event reconstruction. This functionality is common in particle physics, but isn't native to EPICS or have a well known pattern.
* A native data manager. Something like pvManager operating server side as a service. "Decoupling the rate of events on the network from the rate of refresh needed by the client".
* A framework for "fly scanning" (scanning a number of dependent variables against time - the independent variable needs no settle time).
GW: Are you talking about a client side program like a "correlation Plots"?
DC: Yes, that would be great.
* New detectors pose a challenge
* SW must permit interactive "exploration" for data acquisition and analysis. Too allow experimenters to
interactively try different frame rates, triggering times etc. Need a flexible tool that allows one
to configure an experminetal setup and change it ad hoc.
* No single person can meet the challenges, collaboration is requried.
NEW TOPIC: synApps, Epics Software for beamline controls, Tim Mooney
SynApps is a collection of EPICS modules for synchrotron beamlines.
Oriented to beamline control, not experiment control
areaDetector: CCD detector support. Supports 2-d detectors. areaDetector includes a plugin mech. for
grabbing the detector device data, and assemble a data file + eg the conditions under which data was taken.
Importantly it takes images of the disk, and puts them into EPICS Pvs.
It operates in the range of up to 100Hz.
Records the latest values of selected EPICS Pvs; restores those values when the IOC restarts.
Allows Ca clients, and asyn threads, to complete put_callback operations.
Eg, SNL prog driven by EPICS PVs.
Scan sw in synapps is absolutely reliant on thsi module, because without it it wouldn't know when to execute the callback.
Evaluates expressions entered at runtime. Hence sequence of operations.
When doing a scan that involves a motor and scanners, the calc module is what is controlling the sequence.
Important for acquiring spectra
UC is focusing down to a small point, and then raster scanning.
Is central to method for storing spectra for each pixel
Streams to disk for fly scans.
Used for step scans (as opposed to fly scans)
For controlling the "manual" move of a motor - which is out of scope for the motor record.
For instance, if you want N (<8 or so) motors to each be at a given position at a given time.
Uses motor record.
stepper and servo motors
pre/post move commands
Trajectory support built in for some motors.
Supports slits and mirrors, and monochromaters
Aslo low E monochrometers
Supports optics table
Support for 4-input electrometers
Support for end-user programmable glue electronics
Simple glue electronics problems, where otherwise you may have had to use a breadboard.
Implement smart oscilloscope trigger for eg diagnostics
Drives EPICS record processing from hardware input
Works with microline off the shelf FPGAs
Allows for expression and acquisition of 1-d correlation experiments.
The issue for it, is that storing previously configured scan records for later retrieval and
reuse, has no well established pattern or user level support.
SynApps in Context
It is suff. for many types of experminent
There are too many expermient types to develop a custom client for each.
So, need generic tools from which to build experiment controls.
Ideally "do for experiments what EPICS does for beamlines."
SynApps is used with "spec". Spec is the standard progrm used by materials scientists for controlling experiments. It does not do analsysis. So, the common UC would be control eg a crystallography experiment with spec, and use the synApps sscan record to read results.
TM wants to give experimenters what EPICS did for beamline.
Not clear what that means
python wrapper for the client seems the only obvious thing.
session ends 12:40
NEW TOPIC: Scan system for experiments at SNS. Kay Kaswemir
KK described a CSS client and server side suport, for scanning.
Scans are confirgured in the GUI, or by hand in XML. Once the scan is configured,
it is submitted (by java RMI) to the scan server which executes it and returns results.
The scan server does not wrap sscan record, it implements its own scan engine.
The architectural premise is that one beamline experminent would use one scan server.
One scan server presently only (deliberately) executes one scan request at a time.
So, it's oriented toward helping beamline scientists graphically set up their experimanent
in CSS, then run it remotely in the experminetal beamline, possibly lasting a long time (hrs or days)
[gw: It's not so much oriented toward accelerator physics, where one might well set 100s of
dependent variables, but acquiring relatively slowly, and one doen't have want to or need to
write a script to make the scan.
Since it's java, an acquisition script can be written in matlab!
GW: very cool for beamline experminents. Probably not so pertinent for accel. phyics.
TM: How do I get this system and deploy it?
KK: It's packaged as a CSS [ie an eclipse] plugin. You build your scanner as an Eclipse "product"
using the CSS Scan "feature".
NEW TOPIC: PXdb, Rick Buono
Is a Protien Crystalography Database.
PXdb is used by visiting scientists, to
manage groups, projects, crystals
Review details of all tehir data collections
Generate summary reports
Utilized by BNL staff to
Administer BNL hosted and remote experiment scheduling and execution.
NEW TOPIC: CBASS experimental data setup
CBASS is a beamline experiment platform by BNL.
It uses EPICS, on RTEMS, EPICS SoftIOCs
It's essentially 3-layer model, where the servers are implemented.
It's python on server side. The GUI is tkl/TK
NEW TOPIC: Formulating the Remit of the EPICS V4 Working Group for the next year.
Discussion led by BD.
BD comments that there were 2 levels of participation in the first WG:
- Participant - at least 20-30% of your time
- Observer. Makes comments on the work of the group.
We'd love Tim and others to be at least observer.
BD starts listing service we might work on:
Potential Projects of Next Working Group Charter:
* pvIOC should understand multi-core processors, and matrix manipulation, recording the time sequence from hardware.
* NDArray support - areaDetector. Normalizing areaDetector using Normative Types
* Image Library - tools for manipulating images and packaging as NTImage
* Diamond had the following specific requirements:
DH (on behalf of JR):
Want monitors suitable for data acquisition. Must guarantee in-order delivery and configurable queue size and replacement policy on overflow (drop newest or drop oldest etc). May already exist, want to develop test app (ethercat or areadetector)
DH (on behalf of Tom Cobb):
Want to be able to run an areaDetector driver on one machine, and an areaDetector plugin on another machine, and transfer the NDArrays between the two using EPICS V4 monitors
DH (on behalf of Tom Cobb):
Want to have an existing areaDetector driver (like simDetector) be connected to a V4 record layer so that it dynamically created fields according to the underlying parameter library, and to do it with only header file changes to the driver.
* Client Applications. Replacement for (m)edm
* Scan service
* Experimental data environment logging
* Coordinate space conversion library
* Analysis library
GW: The above projects and requirements do not seem perculiar to beamline physics, they're really applicable also to accelerator physics.
GW: Also, many of them are still quite etherial, not closely defined. But to be a goal of a collaboration, a goal must be very concrete.
So, suggest not explicitly orienting the next WG toward beamline physics, but rather taking only those requirements above
which are conrete, and doing those within the existing context of the WG.
Conclusion: the next charter of the WG will be oriented towards accelerator and bealine physics support jointly. We won't specifically orient one WG to beamline physics, and another to accelerator phyics.
Meeting ends, 17:00