rt-bs 30th March 2001

This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.

LHC-CP sub project on RT controls for the LHC

Meeting no.6 : Friday 30-03-2001 - reported by Mike Lamont/Thijs Wijnands

Present : M. Jonker, A. Butterworth, P. Ribeiro, M. Lamont, O. Berrig, O. Bruening, Q. King, T. Wijnands

Agenda :

RST and all that - Q.King
SLC/PEPII lessons - T. Wijnands

Minutes :

No comments on the minutes of the previous meeting

RST - Q.King

QK kicked off this meeting with a slide show on RST. RST stands for Regulation - Servo -Tracking and is a robust digital algorithm that will be used to control the current in the LHC magnets. Power Point slides can be found here. Quentin pointed out the usefulness at JET of being able to model the open loop response (for example) of the system using MATLAB before any attempt at implementation.

Just a few comments:

Warning events will be required for the power converters : every pc driving a main magnet will need a warning event before a trim can be send. Might think one could do away with this and just accept the delay. However, the delay varies between power converter types and differences could be significant for warm/cold corrector combinations i.e. solenoid compensation bumps and crossing angle adjustments.
MJ worried about the setup overhead. For little changes in current, the trimdac can be used, otherwise allow for some 100 ms overhead.
OB remarked that the overhead is probably not so important in this case, all we worry about is that a "miniramp" is done synchronically (i.e. all pc start executing the ramp at the same time in the same manner)

SL/PEPII - T.Wijnands

Before starting the presentation, the question arose as to whom or what will determine the reference current setting of the spool pieces in the LHC. From the previous meeting, it seems that real time reference signals could be generated in different places : in the server/dico for the power converters, in the control room (real time knobs, EIC writing a trim to the database) or it could be generated by a central real time control system. ML promised to clarify this issue during the LHC-CP workshop next week.

TW gave a short summary on the lessons learned from the SLC/PEP-II feedback systems. It is clearly impressive what have been achieved for PEP-II. By extending the fast feedback system from the SLC to PEP-II , the design luminosity was reached within 18 months. The system consists of a central VAX/VMS, a database and a number of micro's close to the ring which run a RT operating system and have point to point communication link. Algorithms are computed off line and loaded in the database. The micros execute control loops at 120 Hz or less. A single digital control theory is used for all loops (now 50) and the generic, database driven software makes the whole system very flexible. The concern is whether a linear theory would work well for the LHC which has a large dynamic range. Slides can be found here.

A few comments:

Digital control based on state space formalism does not improve the type of your system. That is, it doesn't eliminate tracking errors for example. However, it is easy to extend the controller such that is will do so.
OB : can we really linearise all our fast feedback control problems ? Maybe not, but it will definitely be the best approach - starting off with a nonlinear controller makes everything too complicated.

Where do we go from here ?

Prototyping:QK proposed that we get going, i.e. buy hardware and install a network. Everyone agreed that the orbit feedback is clearly the motor of this whole project. How about some prototyping work? There will be prototyping work in SM-18 concerned with the power converters. It is planned to measure transfer functions with the setup that is in place now. How about interfaces? Can we write down a definition of how to interface with this system ? MJ suggested to set up a framework of how to implement the loops (database?).
We could make use of a consultant in the field of control theory. In any case, we should first agree on the logical architecture (under development). This should be finalised and the process of translating it into a physical architecture addressed.
Some formal modeling of the plant transfer function/plant dynamics should be performed.