When Adam used xcefdmp on a bad run, he saw that each event had info
from both ROCs. But for one ROC, most of the data words were either
0xbaaaaaad or 0xfb000bad. CODA writes one of those if it gets FASTBUS
errors; our readout list writes the other. I don't think any of our
Root macros check for this in the data stream.
This morning I verified that I could get module IDs from the beam right
FASTBUS crate, but not the beam left. Last night we had convinced
ourselves that both SFIs and both ROCs were fine if you used them in the
beam right crate. So this morning Adrian, Tancredi and I swapped out
the beam left crate for a spare. Then I could read module IDs from both
crates. Note: Prestart reads all module IDs and writes them out to the
ROC serial port (and to a telnet session with the ROC), so you could
notice that there was garbage on the FASTBUS backplane.
I also found the beam left ADC gate cable was broken; this might have
happened while we were swapping the crate. Adrian and Peter verified
there were signals in all gates and starts yesterday, using a scope.
After swapping out the crate and verifying module IDs, I tested the
other SFIs I had tried last night. One of them, SN 96, is bad; I can't
read module IDs. SN96 may have been in a crate before last night,
compounding our confusion.
I took a few CODA runs with cosmics. Run 2896 is with
cosmicTOF_CC.settings. Adrian looked at it; not many events have good
TDC on the left sector. BUT the left tubes count reasonably on the
scalers. Using the CFD mask feature and looking at scalers, we see only
15Hz from the left sector, >600Hz from the right sector. Since this is
independent of CODA or FASTBUS, there must be something funny in the
trigger HW/SW. Adrian is checking that now.
Adam DeGrush wrote:
>
> Reconstructing the story of the B Shift:
>
> --The ROC module residing on the right sector was replaced with a new one
> .At this point both sector data was bad (using xcefdump)
>
> --Replaced ROC module back with original still didn't work
>
> --Replaced Right Sector SFI. Still didn't work
>
> --Karen came in and discovered that someone had switched the roc modules
> without notifying anyone. Since the ID's reside on the boards what was
> thought the whole time to be problems with the right sector was really the
> left. Note:Because the replacement board was configured for the left
> sector, this explained why both sector data was bad with two left configured
> boards are in.
>
> --After exhausting all permutation of SFI's/modules between the right and
> left, we are still left with the left sector not working.
>
> --Karen will investigate the problem further tomorrow morning.
>
> Chi and Adam
>
> Special thanks to Brian O' Rourke for removing the stripped screw w/o
> hurting the module or anyone around
>
> Peter Karpius wrote:
>
> > The Fastbus troubleshooting continued for the rest of the shift.
> >
> > After speaking with Karen we found that there was no connection between
> > the L crate and R power supply other than in the current configuration
> > both SFI's must be powered for CODA to run.
> >
> > Since we had Left TDC's and ADC's but missing Right ADC/TDC signals we,
> > upon Karen's suggestion, swapped cables. We exchanged the LTOPTDC for
> > RTOPTDC and saw that the RIGHT data returned and now left was gone. This
> > told us that either the SFI, the TS-SFI cable, or the entire
> > right Fastbus crate was bad.
> >
> > Tancredi suggested that we swap the SFI's. In attempting to do this we
> > noticed that a screw on the R SFI has been stripped and we could not
> > remove the module. At change if shift Chi and Adam were to consult
> > Ernie Ihloff (who was working in the South Hal) about removing the
> > stripped screw and thus being able to swap SFI's.
> >
> > Pete
> >
> > ----------------------------------------------
> > Pete Karpius
> > Graduate Research Assistant
> > Nuclear Physics Group
> > University of New Hampshire
> > phone: (603)862-1220
> > FAX: (603)862-2998
> > email: karpiusp@einstein.unh.edu
> > http://pubpages.unh.edu/~pkarpius/homepage.htm
> > ----------------------------------------------
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST