Wednesday, July 11th
Preliminaries. Getting wired up, scribe hit list, making the projector work etc.
9.30 Status. Timeline planning and firm commitments.
1. Charter and status. Briefly go over our charter success criteria and deliverables.
Get status on all of the work that has been done relative to the charter.
9.45 Required Charter Exit Functionalities (*Greg*, 45 mins)
Proposal for how to present the deliverables at charter end in September/the next EPICS meeting:
A list of small use cases and functionalities should be shown, and how you would do those with EPICS V4.
10.30 Status of Core PV* modules, Java and C++, with respect to the charter.
Objective is to be definitive about charter exit objectives *for each Deliverable individually*, and
timeline to charter exit. That is, what must be in late BETA by September, as a finer level of detail
than the Charter deliverables list.
3.1 *Marty* status report, 15 mins.
pvDataJava, pvIOCJava, pvDataC++, pvIOCC++.
In particular, pvIOC C++ on embedded IOC, for mediating V3 I/O ("Dirk's Use Case")
What will this take, is it possible by September? Should it form basis for next year?
easyPVA. Will this include RPC and PVStructure?
3.2 *Matej*, status report, 15 mins.
eget - will this include channelRPC? Confirm only waiting on Normative Types?
3.3 *David*, status of unsigned and report on the status of RPC in both Java and C++ support, 20 mins.
3.4 Ralph (although won't be there)
Will the Charter DS deliverables be met?
1.30 Data Services, Programming Clients, and High Level Data Types
* Status and demos of applications and services.
PSI orbit acquisition, (*Timo* 10 mins)
PSI modelling (*Greg*, 30 mins)
EasyPVA review (*Greg*, 30 mins)
First review, what's still required, plus lessons for architecture of EPICS V4 w.r.t. the Directory
Service and its relation to services and clients from writing a practical orbit correction application
in matlab using EPICS V4.
BNL physics status and demos (*Guobao*, 20 mins)
3.30 pm Normative Types.
Return to the matter of self identification of Normative Types, and their programming interface
(*Greg*, 60 mins)
Present: DH, Mark Heron (MH) subject to availability), BD, GS, MK, Philip Taylor (PT), Michael Abbot (MA), JR, TK, Daniel Meyer (DM), Markus Janousch (MJ), MS, Daron Chabot (DC)
Scribes: DH, BD, GS
NEW TOPIC: Status. Timeline planning and firm commitments.
GW: Review charter deliverables with 3 months to go.
1. pvAccess spec - in hand..
2. normative doc pvData protocol.
3. Norrmative doc EV4 IOC processing pipeline. IOC overview document will do for this. Java and C++ v versions different. No record processing in C++.
4-.6 Mostly done. Using this.
7. Normative types at draft stage. Waiting on input from Michael Davidsaver. Various people (BNL) want this.
8. Directory service. Ralph hopes to have this done. Full implentation dependent on fully async RPC.
9. Services API.
GW:Part of pvacess/pvdata done.
MK: Does Services API depend on normative types?
GW: No. They're independent. Possible to do services without NT
MJ: Can [the list of] normative types be added to?
GW: No (unless you're the WG). NTs are well defined and stable data types defined in terms of PVStructures, for common physics operations. Of course, individual users or labs can define their own PVStructures for their own applications.]
MJ: If get widely used new type can it be added.
GW/BD: Yes, by the working group.
10. V3/V4 Interop doc. Not really started. Only requires a rreport. Nice if actually works.
11. Performance report. Report not done but services exist. Have to retest everything [following the changes made for beta 2].
AI on MS by <not defined>: write performance report. Required date is subject to when a stable release can be measured.
12. Getting startarted doc done. Can add to it when new features donone.
14. eget. 60% done. Framework done. not linked to interoperable types. Technical issue service api to be utnderstood by eget
15-16. RL working on this. When he gets going on this "it will be don real quick"
NEW TOPIC: Required Charter Exit Functionalities
<GW: Goes through eget interface and output. - see end of these minutes.>
ISSUE: If add accessing V3 PVs through eget this is dependent on determing provider.
Usual discussion on alternatives (one at a time, broadcast on both, what if two respond, use directory service, dependent on service knowing PV names.)
Discussion on "Dirk requirement." GW: Just requires embededded gather. "Just go to pv and get values and put in vector".
Just has to handle V3 types (scalar, waveform).
BD: Shouldn't return Multichannel array [since that NT is for a homogenous set of PVs, not for a mixed bag of PVs as is the Dirk Requirement].
GW: 2 types of multichannel arrays. The new kind is for the Dirk Requirement
BD: Can you confirm want you want Dirk to do.
(GW adds to his doc.)
GW: Should be able for BD to standup at net next EPICS meeting at demo everything in doc.
NEW TOPIC: Marty reports on status of pvData, pvIOC java and C++.
-no documentation has been changed to reflect the changes most recently made.
Documentation is to be started in August and completed by the end of August. This is a revision of the overview documents to reflect the changes.
Unsigned conversion is the only test that did not pass. David will fix this issue.
caV3 is up to Matej to inform Marty on this connection.
pvAccess is not connecting propoerly. Requires working with Matej
On rpc and gather code should remain
AI GS by ????: to remove the remaining application packages out of pvService repository, so that pvService
contains only RPC and gather.
pvData - ready for testing with pvAccessXCPP and pvIOCCPP
Needs more tests on array types such as image
example Service RPC is working. - except the exit is throwing an exception.
PVGet to get data is crashing.
V3 channel access does not support unsigned - but the records do support it.
The V4 service to the V3 records is capable of handling the unsigned values.....
Only supports of client side of gather.
Will support unsigned from the V3 database through the V4 service.
PVAccess - unsigned, structure provides the name of a field - not the field.
Test server is not up, as the server is not up.
C++ - compiles, works, but it needs more testing. It is not codek(sp) based.
Specification is not aligned with the implementation. These will be slowly added, but not included in the release.
What is needed for completion of pvCore beta 2:
AI GW: provide headers for copyright
AI MK: V3 Channel needs unsigned support, (PVAccess C++)
AI MK: and MS Remote PV Access is failing
AI MS: make changes to PVAccess to make the tests compatible with Marty's changes.
AI MK: and MS - make documentation at the beginning
AI MK: and MS - internal use of Beta 2 ready July 31st.
NEW TOPIC: status of unsigned and report on the status of RPC in both Java and C++ support (David)
AI on DH by July 31: Finish implementation & bug fixed unsigned types in Java.
Complete Unsigned request on both Server and Client sides in Java
Create helper header in Java for channel archiver rpc server [??]
AI on DH by July 31: implement C++ interface of pvService RPC client, symmentric with Java client side interface As Much As Possible
ChannelRPC in java is in pvServiceJava client
Channel RPC presently is implemented as a pvIOC. channelRPC and should be decoupled from record proocessing,
since record processing is not implemented in CPP. In this way, channelRPC can be implemented symmetrically
and completely on server side in both java and CPP.
AI on MS by July 31: decouple rpc server side from java ioc record processing, and put it into pvAccess. Move channel RPC from pvIOCCPP to pvAccessCPP.
ISSUE: Multi-threading will not be implemented in CPP for now
GW: where is C++ implementation?
MK: current, at pvIOCCPP, can be moved into pvAccessCPP
MS: interface implementation will not be symmentric
BD: Does James have time to look at server side in C++?
JS: need a good design first.
BD: may be next cycle. Sometime Oct. 1
BD says DS by Ralph will be done by July 31.
GW: RH said he needs mullti-threading
NEW TOPIC: Demo of PSI model system (greg)
status = modelrun(ARAMIS, DONT_INCLUDE_GUN, DESIGN_MODELTYPE, OPTICS_NOMINAL, Q_NOMINAL, P0_NOMINAL);
status = modelrun(0, 0, 1, [48.09 0.36 48.08 .36], 2.0e-10, 274.28);
status = modelrun(ATHOS, DONT_INCLUDE_GUN, DESIGN_MODELTYPE, OPTICS_NOMINAL, Q_NOMINAL, P0_NOMINAL);
status = modelupload('Aramis with nominal initial conditions');
status = modelupload_given(ARAMIS,DONT_INCLUDE_GUN,DESIGN_MODELTYPE,...
OPTICS_NOMINAL, Q_NOMINAL, P0_NOMINAL, Lastmodelrun_lattice, ...
'Aramis with nominal initial conditions, 2nd upload to BD database');
modelsetgold_given(11) - sets runid 12 to gold.
Get model data from rdbService:
Start a EPICS V4 server:
Get model data:
NEW TOPIC: orbit service: TK
TK: Aims to create synchronous BPM orbit service using gather and PSI/SLAC synchronous acq pattern.
Add to easyPVA unsign to document through giving helper method Java implementation (a hint how to do it)
AI on MS by middle of AUG(???): add support for structure to eazyPVA & add RPC to eazyPVA Java
DH will go through previous AI to support RPC in pvService C++
API should be symmetric
MS to create eazy channel RPC binding
List of Technical Issues and Requirements outstanding for Charter exit:
The following list was added to intermittently through the meeting:
1. Add the following to EasyPVA
a. request for PVStructure
b. arguments as part of request for data (that is support for channelRPC).
2. Module on V3 IOC to aggregate V3 IOC data and return v4 structure (Dirk Request).
1. Complete changes for introspection and unsigned + tests (beta 2)
2. Add pvStructure and RPC to EasyPVA Java implementation
3. Add NTs to CSS
4. Add async to channelRPC
5. Add support for NTs to eget
6. Performance report
Also MS will be figuring out technical issues for switching ca/pvAccess provider. Note that this may be complicated when a V3 PV is accessible through either CA or pvAccess.
EPICS V4 CHARTER EXIT FUNCTIONALITIES USE CASE OBJECTIVES PROPOSAL
This is a proposal for the objectives of the EPICS V4 charter exit (what should be finished
at the end of our charter period). The list is expressed as a list of examples, from
the perspective of a command line user.
Basic Get and Put
* Get the value of an V3 PV
> eget QUAD:34:ELECTRICCURRENT
* Get the value of an UNSIGNED V3 record
- Get the values of all the V3 CA standard fields (-r is pvAccess request string)
- > eget QUAD:34:FIELD -r 'field()'
[Can't think of a sensible large number, but can think of many that would only be +ve]
> eget BEAM:RATE
* Get the value of a V4 scalar pv
> eget XCOR:LI:34:IACT
* Get the value of a V4 array pv to the command line
> eget QAUD:LI:18:POLYOMIALS
* Put the value of a V4 scalar pv
> eput -v 34.4 XCOR:LI:34:IDES
* Put the value of a V4 array PV
> eput -v 34.4 19.6 29.3 XCOR:LI:34:IDES
* Put the value of a V3 waveform
> eput -v 34.4 19.6 29.3 QUAD:34:POLY
* Monitor the value of a simple type PV
> emon BPMS:LI34:X
* Get a NTMarix and print as a matrix
$ eget -a TYPE=DESIGN -a POS=MID -a RUN=LATEST QUAD:LI21:271/R
0.23 0.1234 0.0 0.0 0.067562 0.001167
-0.34520 0.0923 0.0 0.0 0.046981 0.001514
0.0 0.0 1.881007 4.857304 0.0 0.0
0.0 0.0 -1.50064 -3.862346 0.0 0.0
-0.00132 -0.001129 0.0 0.0 0.224701 0.003894
0.162595 0.10285 0.0 0.0 -19.603 -0.233109
* Get a NTTable and print as a table
$ eget -a start="3 minutes ago" -a end="now" -a p=12 QUAD34_Bfield
TimePastEpoch(s) Value Date Alarm
496169397.856321000 7.355487346649e-02 Wed Jun 21 17:49:57 2012 NO ALARM
496169401.996447000 1.682446300983e-01 Wed Jun 21 17:50:01 2012 NO ALARM
496169410.052636000 2.558367252350e-01 Wed Jun 21 17:50:10 2012 NO ALARM
496169420.109690000 3.173123300076e-01 Wed Jun 21 17:50:20 2012 NO ALARM
* Get values according to arguments in a consistent way from any RPC service
See examples eget -a above.
Use Cases of Directory Service
* Get the names of a number of PVs, where their names match a string, using the Directory Service. Ideally, sort by a tag or option. E.g.:
> eget -s DirectoryService -a pattern 'XCOR:*:BDES' -a options "sortbyz"
Extra credit: ideally not just * but regular expression.
Eg. Print the value of BDES from all correctors whose PV name matches the pattern XCOR:LI:*:BDES
> eget -s DirectoryService -a pattern=XCOR:*:BDES -a options="sortbyz" -a beampath=0 | eget -t
* Get the value of a number of PVs, where the names match the conjunction (AND) of Directory Service tags
E.g.: Print the value of the desired B field (BDES) from all correctors in the (SwissFEL) section SINBC01
> eget -s DirectoryService -a property='section=SINBC01' -a property='type=COR' tag='BDES' -options="sortbyz" | eget -t
Use Cases of gather service
* Use of an ad hoc Gather to get the field value (V3 PVs) of many magnets or BPMs.
Show use of gather service to simply give LATEST gathered values from a Gather record defined by the client:
So this is something probably done in Matlab
Use gather API to watch and gather data from named magnets:
TODO, show pseudocode
<include python example from BNL>
* Get synchronous BPM orbit data from a BPM service, that is using the gather service in combination with a SLAC/PSI
like BPM synchronous data system. Data form is NTTable.
> eget -a Npulses=3 SwissFELTI:sync:bpmorbit
pulse_Id bpm_name X Y TMIT Status
31330 sinlh01.diag01.bpm 0.331939 -0.20821595 9.2273582E9 OK
31690 sinlh01.diag01.bpm 0.343939 -0.21321534 9.3973582E9 OK
32056 sinlh01.diag01.bpm 0.343939 -0.21321534 9.3973582E9 OK
31330 sinlh02.diag01.bpm 0.430091 -0.19211863 9.4554767E9 OK
31690 sinlh02.diag01.bpm 0.429820 -0.18054654 9.3577114E9 OK
32056 sinlh02.diag01.bpm 0.476549 -0.23452345 9.3245235E9 OK
... snipped many more
Total number of rows printed would be M bpms in the gather record named SwissFELTI:sync:bpmorbit, times
* Get the values of a number of V3 PVs from one V3 IOC, through a V4 record on V3 IOC PVA
[ie, "The Dirk Requirement" ].
Ideally a heterogenous structure of V3 scalar and waveforms.
E.g. Get a summary of the PVs relating to a QUAD from an IOC. In this example the V4 PV
is QUAD:35:SUMMARY, showing that one might use the "physics" name for such summary
PVs, and their values might be composed of a structure of V3 PVs named with engineering names and their values:
> eget QUAD:35:SUMMARY
QUAD:SECT02:13:POLY.VAL 23234.2342 5435.34 753.3 4.34234 5.32E-23
EasyPVA from Matlab.
* Example of orbit correction from Matlab, done using easyPVA
Illustrates requirements for:
1. EasyPVA understanding request for PVStructure
2. EasyPVA understanding arguments as part of request for data
3. EasyPVA understanding that an argument TO a service may be an array
(in the example a table of magnet names and B field values)
Also assumes the Directory Service requirement articulated above to get Corrector and BPM names
% SwissFEL orbit correction in 1/2 page of matlab
easyPVA = EasyPVAFactory.get();
% Get the names of all the Correctors and BPMs from the Directory Service
corrNamesChan = easyPVA.createChannel('DS:SwissFEL:GUN_to_ARAMIS');
corrNames = corrNamesChan.createGet().getStringArray();
bpmNamesChan = easyPVA.createChannel('DS:SwissFEL:GUN_to_ARAMIS');
bpmNames = bpmNamesChan.createGet().getStringArray();
Ncor = length(corrNames);
Mbpm = length(bpmNames);
% Get BPM x orbit from the BPM service.
b = easyPVA.createChannel(...
% Form the Ax-b problem getting Rmats from the Model Service
modelmatrixChan = easyPVA.createChannel('model:aramis:gold:extant:R');
for bpmi = 1:Mbpm;
for corj = 1:Ncor;
rmatAtoB_pvStruct = modelmatrixChan.createGet().getPVStructure();
RmatCorToBpm = toMatrix(rmatAtoB_pvStruct);
A(bpmi, corj) = RmatCorToBpm(1,2);
% 2 lines of actual physics
x = inv(A)*b; % Solve Ax-b
newBDESes = -KtoB(x); % new B field values from K to B
% Deploy the new magnet settings.
magSetChan = easyPVA.createChannel('MAGNETSET');
* EasyPVA to "put" a PVStructure to a service or PV