Closed cameronc137 closed 4 years ago
This is what notified me to the problem originally:
Opposite sign convention:
Can we identify how much this has happened so far?
Are we sure the variable is present in the EPICS events through all of CREX? Are we decoding it into the slow tree yet?
Yes, this is present for all of CREX. I’ve added the condition to use the other variable if this new one isn’t present.
I see that for CREX runs it has happened 5 times in production runs. 4 times (5476, 5486, 5639, 5752) were single read errors that only wipe out ~500 multiplets, and this one at run 5749 was the unlucky opposite case where the glitch was in the first event, causing all the others to fail.
FIxed on operations by PR #276.
The fix should be verified to not cause problems on PREX-2 runs. It should be fine, but lets' check it anyway.
This is fixed in the develop and master branches.
Run 5749 got nearly completely wiped out by a blinder error -> IHWP glitch
IHWP slow EPICs variable should be IGL1I00OD16_16 instead of IGL1I00DI24_24M
Because IGL1I00DI24_24M glitches from time to time, we should use the more stable value IGL1I00OD16_16 (0 = out, 1 = in) for IHWP checking.