FFB troubleshooting

From PREX Wiki
Jump to: navigation, search


Trouble with fastfeedback can take the form of:

  • 1) Fast feedback not working.
  • 2) Fast feebback steering the beam wildly
  • 3) Fast feedback killing bpm12x, which we need for energy monitor.

If FFB is not working

  • Call spokesperson Kent
  • OPS can troubleshoot for 1hour. Then request they call an expert and call the RC (or Caryn). Unless very clear path forward, revert to planB below.
  • If have tried for a long time to fix (like a couple hours): Plan B is: tell OPS to turn off FFB, put iocse9 in "NormalOPS" mode, and to monitor (and have OPS monitor) "HALLA:dpp" on a stripchart and keep it to within -1x10-4 using the SL-20 energy vernier. OPS can be told to make manual corrections to SL-20 Energy vernier if HALLA:dpp drifts by more that 1x10-4 from usual setting.
  • Things to suggest to OPS
    • Plan B (fix HALLA:dpp energy manually) with FFB off.
    • FFB can be run with Feedforward off (which can help if FF is broken as it has been recently). Request OPS set FFDAC off and FF off.
  • If OPS says FFB is 'steering the beam a lot/tripping ion chambers'
    • move targets from Ca48 to a safer target like Ca40 or Carbon1% while they attempt to fix it.
    • Tell them to allow the target lock to attempt to get themselves in the right BPM position with FFB on, then switch targets back to Ca48.

Interactions with BeamModulation

  • If FF is off (FFDAC=off), then for beam mod to work, we must use the version of beam mod that turns RF off during beam mod cycle, as well as pausing FFB
  • If FF is on (FFDAC=on FF=on), then we must use the older generic version of beam-mod that only pauses FFB during a beam-mod cycle and leaves RF on.

If bpm12x is saturating -

  • This happens when FFB gains that crate incorrectly. It can be good enough for FFB (and ops gets no errors) but we are still hosed due to bpm saturation.
  • Keep an eye on bpm12x wires (panguin), and make sure that they are around 30-37k channels, not 50k-60k channels, 40k is pushing it. Alarm handler will go off if bpm12 saturates.
  • If they are saturating, call mcc and request that a "gain search" on ffb.
  • Note: BPM 11 , 12 and 16 are located in IOCSE 9 crate and make sure that we instruct MCC to gain search the correct BPMs. Disaster like beam mis-steering happened when gain search was wrongly done in target lock BPMs
  • If gain searches fail, check with OPS that
    • WS gain tolerance factor is 20% (FFB screen->debug->Gain Controls) [not 40%]
    • If current is 150uA, check that RF gain is set to low.
    • If current is 5uA,10uA, check that RF gain is set to high.
    • Check Gain Control Mode is Manual (not automatic. FFB screen->debug->GainControls)
    • Check FFB Mode is "Absolute" (not relative) and Abs Lock To: "Zero" (not Gold)


  • Might also benefit from running in "manual gain" mode of FFB, rather than the FFB "auto gain" mode on the bpms. (The control for this is found under the debug tab, on the FFB control screen, under the title "BPM gain control").

If turning on FFB leads to ion chamber trips -

  • this is probably due to the self-calibration.
  • Possibly running in "relative" mode (compared to "absolute" mode) on FFB may help, so it is one thing to ask the ops about.

To quote some wisdom - "Remember: bpm12x is absolutely critical. Data is useless without it. Running when bpm12x is saturating is the same as not having beam. If you aren't watching 12x and it saturates, this is comparable to forgetting to put the target in, or forgetting to put HV on the detector PMTS... get the point? Its crucial. Also, the time that BPM12x is saturating is not ABU."

New Documentation

https://logbooks.jlab.org/entry/3696221

PREXI documentation: