Log entry time 20:39:57 on September 6,2009

Entry number 288327

Followups:

• 288398 09/07/09 09:48 rsholmes BPM12 again

We have had a lot of trouble with fastfeedback in the hall today and yesterday. 
 There are two problems:
1) Fast feedback not working.  
2) Fast feedback killing bpm12x, which we need for energy monitor.

More on 1):  turning on FFB has led to ion chamber trips (mostly ep).  This is 
probably due to the self-calibration.  We had better luck running in "relative" 
mode (compared to "absolute" mode) on FFB, so if this happens again, it is one 
thing to ask the ops about.  Incidentally, that is entirely snake oil, I don't 
think there is any reasonable expectation that relative ought to be less 
troublesome then absolute.  But it was tonight.

2) we have lost a lot of data tonight with bpm12x 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.  What to do?  Keep an 
eye on bpm12x wires, and make sure that they are around 40k channels, not 60k 
channels.  If they are saturating, call mcc and request that a "gain search" on 
ffb.  If that doesn't clear the problem, ask them to turn FFB off, and then 
back on.  Tonight, we also benefited 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").

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.