SctRodDaqRelease4.1.1 fixes bug in SctRodDaqRelease4.1
SctServiceGui? and sctGui are now thought to be in working order (compare SctRodDaqRelease4.0) though still not all changes made to rel_3 branch during macro assembly have been migrated. Changes still not in are "quick characterisation" and "quick trim" (I think). There may be others.
There may (or may not, we don't know for sure) be a problem with "the very first" crate initialisaion since power on. See note at the foot of TestingSctRodDaq 4 1.
Just noticed while running at Cambridge that one should remember that this release will only work with 1.1.1 MDSP firmware (October 15th (and/or November 2004)) evidenced eg by the following snippet of SctApiServer?.out:
[MDSP: utilities.c, 614]:: SCT DSP code version 1.1.1 Nov 1 2004 Formatter code version SCT e 20 40 MHz EFB code version e 2b Router code version e 21 Controller code version e 1d
and if you accidentally have the more recent firmware you may see very strange noise occupancy plots ... due to masking errors ... most of which you can fix by replacing the line of CVS revision 1.122 of SctApi/SctApiHisto?.cxx from
api.getABCDModule(mid, SCTAPI_BANK_SCAN);
to
api.getABCDModule(mid, SCTAPI_BANK_CALIBRATION);
in order to make it better at coping with assembler histogramming. This change made things better, but not all things better, and was never committed to the repository, though there are arguments for doing so
BUGS
DoubleTriggerNoiseTest
seems to be histogramming the first rather than the second trigger - bug introduced during merge from Release3 to Release4Fix: in file CalibrationController/src/scripts/DoubleTriggerNoiseTest.h change
// Capture the second of the two triggers (index 1)
APICALL(s, setOption(Sct_SctApi::Scan::nth_rem, 1), "Failed to set nth_rem option")
to // Capture the second of the two triggers (index 0)!
APICALL(s, setOption(Sct_SctApi::Scan::nth_rem, 0), "Failed to set nth_rem option")