J. Kissel

The front-end logic for calculating the IMC ODC state vector (primarily looking at IMC WFS signals) had been updated in September (see LHO aLOG 14098), but the ODC MEDM screen and EPICs records didn't get updated accordingly. 

I've svn up'd the 
/opt/rtcds/userapps/release/ioo/common/medm/IMC_CUST_ODC.adl
ODC screen, which fixed some white channels that were a result of some of the channel changes. 
Further, I've reduced the Master Gain / Trigger OK Threshold, H1:IMC-ODC_WFS_GAIN_GT_EQ_TH to 0.1 (was formerly 0.604), after recent commissioning of the WFS loops have reduced the overall WFS gain from ~0.6 to 0.2 (e.g. LHO aLOGs 14301, 13280, etc.). 

Finally, I've captured a new safe.snap (with makeSafeBackup, saved to the userapps location), ensured that safe.snap in the target area is a soft-link to the userapps location (where the front end looks for safe.snaps upon boot) and committed
/opt/rtcds/userapps/release/asc/h1/burtfiles/h1ascimc_safe.snap

The IMC is currently locked happily, and the IMC ODC now agrees. It's interesting to see that only the MC2 TRANS and IM4 TRANS SUMs are used in conjunction with the Master Gain / Trigger Threshold (as indicated by the bitmask for what is used to compute the summary bit). Why aren't we using the error points? If we don't use them we should remove them from the vector as the filter calculations are wasting computation time (though we're far from being clock-cycle limited at 28 out of 480 [usec] or 5%). 

P.S. Gabriele has now been made aware of the state vector, and will ensure that when he's finished tuning that the ODC vector will be green again.