Functional Description
Next: Loops being implemented
Up: Fast Feedback Users Guide
Previous: Description of the
In this section a bit more detail is given about what feedback does
and how it does it. The emphasis is on the control methods.
Information about the displays and user interface are best obtained
from the online help.
-
The basic action of fast feedback is to read sensors (e.g. BPMs),
calculate states (e.g. , , , , ) and then calculate and
implement new actuator (e.g. corrector) settings to try to stabilize
the states at desired setpoints. The basic feedback algorithms assume
everything is linear (e.g. the reading of a BPM will change linearly as
a function of corrector setting).
There are many details though, which actually turn out to be most of
the work.
-
Feedback can make use of the present hardware (e.g. BPMs and
correctors) and is integrated into the present control system. Old
fast feedback required all of the control hardware to be duplicated.
-
When a feedback loop is on, the actuators it uses are flagged. They
will show up white (like no-control magnets) and be labelled FDBK CTRL
on the magnet displays.
Also, the magnet job will not allow them to be trimmed etc.
-
New loops which are similar to old ones can be added
without adding new code. This can be done because fast feedback is
database driven.
-
An actuator can be any magnet-like device except for movers
such as an XCOR, YCOR, LGPS,
AMPL, and PHAS. In V3 timing devices (to allow adjustment of the PSK
time for the positron energy loop) will also be controlled.
-
A sensor can be any BPM-like device such as a BPMS, DUGADC, ARRY, or TORO. In
V3 the read out of profile monitor and wire scanner data will be
available.
-
Feedback can use multiplexed BPMs. This allows us to
use fast feedback in many places without having to install new BPMP's.
Note that the LINAC BPMs are effectively multiplexed between ,
, and the scavenger bunch. Where high speed is essential, we can
of course still demultiplex signals.
-
The typical launch (controls beam position, angle and sometimes
energy) loop will
have two to three times as many BPMs as needed
to determine the states. This provides some redundancy. The loop
continues to work with some number of the signals missing. The
maximum allowable number is set in the database.
-
In the Linac we have many (eight) loops in a row all looking at the
same beam. If there is a disturbance coming out of the damping ring,
all the loops see the effect of it. Without special care, they would
all change their correctors to try to fix the problem. This would
result in an overshoot as seen at the end of the Linac. Really, only
the first loop should fix the problem, the others should do nothing.
In fact, each loop should only fix those beam perturbations which
happen downstream of the previous loop. The implementation of this
feature is known as CASCADE. Each Linac loop sends a vector of its
states (known as the CASCADE vector) to the next downstream loop. That
loop then uses a beam transfer matrix to transport the beam positions
and angles from the location of the upstream loop to that of the
downstream loop. It then only tries to fix the difference between its
measured positions and angles and those of the transported upstream
loop.
-
In CASCADE one needs to know the beam transfer matrix from one loop to
the next. The Linac energy profile varies enough in an unknow fashion
that these transfer matrices change with time and cannot be accurately
calculated from the model. The adaptive ADAPTIVE CASCADE feature uses the
natural jitter of the beam to gradually learn the transfer matrix.
This is used in the cascade algorithm and is also available as a
diagnostic of accelerator changes.
-
Measurements from beam pulses which are vetoed by the klystron veto
system are not used by feedback.
-
Saturation of an actuator (e.g. a corrector is at its maximum value and
the controller wants it to go higher) is gracefully handled. In
particular, the operator is notified if the condition persists
for more than 10 seconds and feedback still properly controls
those actuators which are not saturated.
-
GOLD ORBIT CONFIGURATIONs can be saved. This works much
like it does in slow feedback. That is the present readings of all the
relevant measurements (e.g. BPM readings) are saved to
a configuration disk file. Old versions of this file can be used to
restore the loop to a previous state.
-
When a loop is controlling two beams (e.g. most of the linac loops
control both the electrons and positrons) and
only one of the two beams is present, feedback will still control the beam
that is present, leaving the other one alone. An allowed exception
to this is when an actuator is saturated. In this case feedback may
change the unmeasured beam in order to correct the measured beam.
-
Most of the control mechanisms (filtering, transfer matrices, gains, etc.)
are
set up offline by filling in matrices used by the controller. Just
in case that setup isn't perfect, a single gain constant per
loop is available for change from the SCP. This determines
the fraction of the calculated actuator change which will actually be
applied.
-
A loop will continue to work properly (without operator intervention)
as the beam rate varies from 1 Hz to 120 Hz. Obviously its bandwidth
will be less at the lower beam rate but it should remain stable and
not need to have its gain changed.
-
The system can do a . This involves varying
each actuator one at a time and noting how the sensor measurements
change. This data is
then used to determine some of the control matrices.
-
The structure of the program allows for a clean way to implement
``special cases" such as the following.
-
The scavenger energy loop changes the phases of two sectors of the linac
in order to change the energy. The calculation of these phases is
nonlinear and hence will require a special purpose routine. In
addition some special initialization is needed, namely the total
energy gain of each of the two sectors.
-
The interaction point loop tries to keep the beams colliding by
measuring the deflection angle. The conversion from measured
deflection angle to beam separation involves a division by the beam
intensity. This is nonlinear and hence a special case.
-
Separate control of the linac positron and electron energies involves
changing the PSK time for all the klystrons in the linac. The relation
between the PSK time and the energies is nonlinear and hence is
presumably a special case. (This is not done yet. This control will
probably remain under slow feedback for quite some time.)
-
The micros accumulate ring buffers of relevant data such
as BPM readings, actuator settings,
and state variables (, , ). The ring buffer
contains the value of that variable for the last N beam pulses.
The value of N and which variables should be accumulated are
changeable with a DBEDIT.
The VAX can
request and display these buffers. The ring buffer data is
synchronized (Exact synchronization is not done yet).
That is the point shown in a sensor reading plot will
be the number that was used to calculate the point in a state
ring buffer plot. These ring buffers can be used for debugging and
diagnostic purposes. They are available even while a calibration
is in progress.
-
Ring buffer data can be saved to disk in a form that MATLAB
can read.
-
When a micro is IPLed, the necessary data is automatically
down-loaded to it, and if its feedback is on it is automatically
started up.
-
When a BPM is turned on or offline from the BPM diagnostic panel
feedback will be automatically informed and will start or stop using
that BPM.
-
We can add a limited number of states, actuators, or
sensors to an existing loop with less hassle than involved in a DBGEN.
This is done by leaving spare units in the database
which can be turned on with a DBEDIT. Then the controller micro is
IPLed and a COLD START is done for the loop to all
the micros to
re-read their part of the database and re-initialize their structures.
Note that turning a loop off and on again does not completely
re-initialize a loop; the COLD START button can be used for this.
-
The micros make periodic (every 60 seconds or so) asynchronous
database updates of the loop status, measurements,
states, actuator settings and so
on. This is done using the standard asynchronous database tools
(that is instigated by the micro, not the VAX).
The data is used by the history buffer program and SDS display (not
done yet).
-
Most of the feedback loops assume that correctors within their range of
BPMs are not changed. If they are changed, one will need to save a new
GOLD ORBIT. For a few loops this will be too inconvenient (NFF and SFF
have correctors used for the CCS eta correction bump in the range of
BPMs used by the feedback loop). For these cases, feedback can be set
up to get the field strengths (as read by the regular magnet job) and
use them in the calculation of the states (e.g. , , ). This is
done in a
manner similar to slow feedback.
-
The loop setpoints (for states) can be set from a touch panel. For example
this allows one to request that a loop maintain the beam energy 50 MeV
higher than it was when the gold orbit was saved.
-
The setpoints can be assigned to a knob and adjusted. This
may be useful in minimizing backgrounds or tuning some other
parameters not directly controlled by a feedback loop.
-
The necessary subroutines to interface to correlation plots have been
written.
This includes the ability to change a setpoint, ``one shot" a loop
(let it run for long enough to converge), and attain the value of a
state averaged over several pulses. The modification to the correlation
plots user interface to take advantage of these routines is not done yet.
-
Interface routines are provided to allow other SCP software to attain the
present HSTA (ON, OFF, Sample Only) of a loop and to change the HSTA.
This interface looks
very much like the existing interface routine used for slow feedback
and V0 fast feedback.
Next: Loops being implemented
Up: Fast Feedback Users Guide
Previous: Description of the
SLAC Controls Software
Fri Nov 4 11:34:56 PST 1994