Reports until 11:20, Thursday 19 July 2012
H2 SUS
keita.kawabe@LIGO.ORG - posted 11:20, Thursday 19 July 2012 - last comment - 11:30, Thursday 19 July 2012(3501)
OPLEV was totally screwed up by a terrible burt restore from yesterday (Thomas, Matt, Keita)

This morning Thomas told me that ETMY OPLEV MEDM screen was not working.

Though the medm screen for new OPLEV channels are present (H2SUSETMY_ETMY_L3_OPLEVWIT_P and Y, what's this stupid ETMY_ETMY thing anyway?), and though the output of the QPD segmens looked OK, the INMONs of OPLEVWIT_P and Y were zero, and more outrageously, the outputs were 1E20 though the gains were 1 and there was no filters. As soon as we set the gain to anything except 1.0, the output becomes zero. Some serious stupidity was going on.

We found that the signs of the oplev segments were all wrong, but that didn't fix this 1E20 thing.

On a deeper inspection we've found that OPLEV does all calculation  in a C code /opt/rtcds/userapps/release/aos/common/src/OPLEV.c, and in this code PIT and YAW are calculated by

pitch = (UL + UR - LR - LL)/(sum*linearResponse*leverArm);
 yaw   = (UR + LR - UL - LL)/(sum*linearResponse*leverArm);

linnear Response and leverArm are EPICS channels H2:SUS-ETMY_L3_OPLEVINF_LINRESP and H2:SUS-ETMY_L3_OPLEVINF_LEVERARM. These used to be 1, but in yesterday's terrible burt restore these were set to zero,  therefore both pitch and yaw were calculated as NaN or something, and depending on what number you multiply that would be displayed as 0 or 1e20, or something like that.

I set these two parameters to 1 and the OPLEV error signal started working.

Comments related to this report
keita.kawabe@LIGO.ORG - 11:30, Thursday 19 July 2012 (3502)

On a side note, I think OPLEV could use an input matrix (cdsMuxMatrix) to generate raw SUM, YAW and PIT, then use a standard multiply/divide, rather than maintaining its own C code.

It's the way all qpd and wfs DC are done in ISC (see attached).

Images attached to this comment