<b>Functional Description</b>



next up previous contents
Next: Loops being implemented Up: Fast Feedback Users Guide Previous: Description of the

Functional Description

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.

  1. 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.

  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Measurements from beam pulses which are vetoed by the klystron veto system are not used by feedback.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. The structure of the program allows for a clean way to implement ``special cases" such as the following.
    1. 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.
    2. 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.
    3. 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.)
  19. 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.
  20. Ring buffer data can be saved to disk in a form that MATLAB can read.
  21. 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.
  22. 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.
  23. 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.
  24. 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).
  25. 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.
  26. 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.
  27. 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.
  28. 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.
  29. 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 up previous contents
Next: Loops being implemented Up: Fast Feedback Users Guide Previous: Description of the



SLAC Controls Software
Fri Nov 4 11:34:56 PST 1994