| SciCo | DAQ Ace | Monitoring Ace | CO | (Operations Manager) |
| Stephan Lammel | Ian Vollrath | Chris Marino | Diego Cauz | Mary Convery |
Start of Shift Notes:  Tevatron turnon in progress
Tue Mar 2 16:42:45
Run 179550
ACTIVATE: XTRP - 2TT - test for firmware to not send short tracks to L2 -- wpipee_98x12.mcs,
wpipeo_98x12.mcs, and simtracks_short.dat - Christopher x2080
what time is it? we don't know - got some "fatal clock errors". talked to some L2 to guys to see if it was related to what they are doing - they don't know. cleared errors on the advice of bill badgett. will keep watch as we go into shot setup.- ian
I borrow the SVT crates to test the data readout with SVDD readout since this is needed to read out split real data for new GB firmware test. It looks OK. We can directly compare the split two data output. We wait for the real data coming.- Taka
icicle crashed (2nd time in last hour or so). restarted it.- ian
brief (~3s) cot systems alarm and gas alarm. called cyro, they are working. ignore until further notice. VOLUME FROM SYSTEMS ALARMS IS QUITE LOW. HOW DO WE TURN IT UP?- ian
jj to the rescue! just the standard volume control on a windows pc.
I have finished working on debugging the cable testing program using the CCAL_## and LEVEL#_CAL_## crates. They are in their original configuration again. Have given them back to DAQ Ace to run tests.- W.Badgett :: (run 179557)
There is something seriously wrong with the ADMEM in crate b0ccal05, slot 20: (MLE) b0ccal05:Messenger:8:27:59 PM->VISIONread/write failed in slot 20 MLE) b0ccal05:Messenger:8:28:09 PM->Runtime Error 1, Event 1: Bunch counter mismatch, mismatch count = 1 (MLE) b0ccal05:Messenger:8:28:10 PM->Event 2: Bunchcounters in slot 17 (BC=90) and slot 20 (BC=255) disagree (L2B=0) L2B 17: 90 3 55 9 L2B 20: 255 255 255 255 The VME readout registers simply aren't responding. (However, the IDPRom does seem to work.) NEed to contact ADMEM experts.- W.Badgett :: (run 179558)
Larry Nodulman (general cal SPL pager) called back. He suggests to call people at home: - Vivek Tiwari no answer office x2032 and home x4760 - Mark Mattson no answer office x3596 no listed home number - Robin Erbacher no answer office 3442 and home (left message) Larry also suggested Rick Tesarek, who we reach at home Mark Mattson (CCAL pager) calles in after about an hour. Bill is working with Rick on the phone.
Have marked ADMEM in slot 20, crate b0ccal05 as offline, so readout of the rest of the crate can continue. ADMEM experts should investigate; is a power-cycle warranted in this case?- W.Badgett :: (run 179561)
| silicon will only go on by expert permission (SPL and/or pager carrier) after the stability of the trigger rates have been demonstrated in a run w/o silicon beforehand. that's what you might have implied. please refrain from direct instruction of shift crews to switch on silicon for non-standard data taking. in these circumstances this is always done by experts. |
Note that to make sure the calibration constants are aligned across the calorimeter, and that ccal05 in particular has new quiet-time constants, Rick requests that a full QIE Calibration be done during the next downtime, with an accompanying CALIB_LOAD supervised by ADMEM experts.
- W.Badgett
-- Tue Mar 2 21:57:41 comment by...Stephan -- Thanks go to Rick Tesarek who worked with Bill 30 min on the phone (covering for the CCAL team).
-- Wed Mar 3 07:38:05 comment by...R.J. Tesarek --
ADMEM problems:
The problem observed with the ADMEM is consistent with
the Trigger/Readout FPGA becoming corrupt. We've had 4-5
instances of this type of problem in the last couple of months.
No instances of this problem prior to summer 2003.
The solution is to reload the FPGA program and recovery
seems to be complete. Bill reloaded the entire crate of ADMEMs
(not just the offending module). He then took a QIE calibration
with just ccal05 and loaded the constants/FRAMS to ensure that
everything was ok. The pedestal problems noted below are consistent with beam in the machine.
While this specific problem is fixed, this type of problem
seems to be recurrant and does not bode well for the future. Something has corrupted the program in the FPGA. I am suspicious
of the software in the crate rather than an external effect
(eg, radiation, power, etc).
One more note on the beam-on calibration: Did a QIE calibration in crate b0ccal05 under the orders of Rick Tesarek. There were three channels/caps with too big RMS, as listed below. Rick is confident that these are due to beam in the Tevatron and should not cause problems. This can be corrected by taking another QIE Calibration during the next quiet-time period. Please contact ADMEM expert (Rick, Mark, or Vivek) when this is possible. ******************* Start of FAILURE messages ************** VALUE CAP RANGE** * ADMEM=17 Chan=14 Failure 6: Raw pedestal RMS TOO big ( 21.5842) ( 0) ( 0) * * ADMEM=19 Chan= 0 Failure 6: Raw pedestal RMS TOO big ( 15.3082) ( 2) ( 0) * * ADMEM=19 Chan=15 Failure 6: Raw pedestal RMS TOO big ( 16.2651) ( 2) ( 0) *- W.Badgett :: (run 179565)
| Date | Time | BLM | Dose | |
|---|---|---|---|---|
| 2004.03.02 | 23:39:45 | W Inner BLM | 1.98 | RADS |
| 2004.03.02 | 23:39:45 | W Outer BLM | 1.29 | RADS |
| 2004.03.02 | 23:39:45 | E Inner BLM | 17.46 | RADS |
| 2004.03.02 | 23:39:45 | E Outer BLM | 713.01 | RADS |
| Run Number | Data Type | Physics Table | Begin Time | End Time | Live Time | L1 Accepts | L2 Accepts | L3 Accepts | Live Lumi, nb-1 | GR | SC | RC |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Totals | 23:55:02 | :: |
Store 3271 in preparation - final protons are loaded - final antiprotons being loaded Plan is to take data with JET_ST3_DECOUPLED[1,433,403] with Silicon - test TEST_MET15_DECOUPLED[1,434,403]
|
CDF Run II
Runs Delivered Luminosity 0 Acquired Luminosity 0 Efficiency 100 |