This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Meeting no.3 : Friday 09-03-2001 - reported by Thijs Wijnands & Mike Lamont
Present : M. Jonker, A. Butterworth, T. Wijnands, P. Ribeiro, M. Lamont, O. Berrig, J.J. Gras.
There were comments on the minutes from J. Wenninger, JJ Gras and from H. Schmickler.
Joerg asked whether it was possible to calculate an orbit correction in 10 ms. Is that REALLY realistic ? We have 2 rings to correct at the same time, have to deal with the coupling of the rings (i.e. very large matrices) and will need some matrix conditioning to avoid singularities (at least with MICADO). On the other hand, it is feasible (and actually very common) to use only a subset of the monitors and correctors (at well selected positions in the ring) for global correction. Since you are interested in removing global orbit structures, you don't need all the details (and get much smaller matrices...). If you then use an SVD algorithm (with a pre-prepared solution), you can probably make it very fast !
Jean-Jacques made a comment on the 10 ms for the acquisition. This is the time when the data are available in the Digital Acquisition Board, not in the CPU memory. If we have a DSP in the DAB (which I would like to avoid if possible), fine. But if not, you should add some ms (let say 10 as a first guess to check with P. Ribeiro) to retrieve through the VME and apply the corrections due to the transfer function of the BPM and the electronic to the 224*3 measures (H, V plus status) of each BPM in the crate (16) before averaging for the orbit (most of the time will be taken by the VME transfer of these 16 DMA calls of 700 integers). It would be nice, if the other members are confident on their numbers, to give us an estimation of the maximum time available for us to provide this data. JJ remarked that they expect now something like 70 front ends, each of these equipped with at least 3 DSP boards.
Hermann Schmickler commented that he recognised the need for real-time control, but that a hard real-time network like ATM would probably not be necessary. This fits the conclusions reached early in these meetings.
MJ gave his long awaited talk on logical architecture (ppt slides here). Michel also presented some ideas for the transformation of the logical architecture into a physical architecture, in particular, the use of real-time knobs (ppt slides here). This triggered some discussion. How to intercorporate changes in the optics? Distributed or centralised control ? The power converters will only have ONE rt trim input and summing or multiplication of RT corrections is not foreseen.Why do need to download the ramping tables to the pc beforehand instead of using the rt capacity.
OB remarked that it is needed since the controller is using the present and the next value in the table. RT corrections to the PC are slow and small and will not influence the pc performance. In contrast, sending down the whole ramping table corrected with RT trims might do.
ML gave his view on the logical architecture and recalled the design of the high level LEP control system.. Then there was some discussion as to how to approach this problem in general. He emphasised a generic approach to provide standard facilities to trim at various levels and drive all hardware. This approach had solved what was essentially a severe data management problem.
TW said that we need a coherent formalism from control theory to attack our feedback problems. Probably only OB has done this in the past for the LEP tune loop.
OB remarked that his section is planning to install the hardware for a number of local feedback loops at 100 Hz which came as a surprise to all present.
JJG suggested that we establish a working group so that we at least have centralised information as to who does what on the beam with feedback.
Next meeting will discuss local feedbacks by OB and lessons to learn from SLC/PEP-II.