J. Kissel, H. Radkins, J. Warner [+ J. Driggers and E. Hall for code assistance]
After Hugh had gone down to the end-stations to check the centering of the STS-2s (aLOG pending), we looked back at Brian's LHO aLOG 22985 that reminds us that we digitally store the mass centering information. There were a few mysteries still associated with those channels, however, namely whether they were the X/Y/Z mass positions or U/V/W mass positions. As such, we went out the CER / SEI racks with a DVM and toggled some switches. We learned several things:
(1) The output of the X/U, Y/V, and Z/W BNC spigots are proportional to each of the stored IOP ADC EPICs channels
(2) To match them up, one must account not only for the 40/2^16 [Vpp/ct] ADC gain, but the gain difference of 2.0 [V_adc/V_spigot] between the spigot and the ADC channel because of the single-ended-to-differential driver in the STS interface chassis (see D040019, pg 5 specifically). Thus, to turn the ADC channel back into the volts which the STS-2 manual recommends for being less that 1.5 [V], one must multiply by (1/2) * (40/2^16) = (20/2^16) = 3.0518e-04 [V/ct].
(3) All of the corner station STS chassis had their XYX / UVW switches toggled to XYZ.
(4) The spigots are marked as "X/U", "Y/V", and "Z/W," the output of which (either X/Y/Z or U/V/W) should be controllable by the rocker switch to the right of the spigots (see attached image). However, Hugh and I toggled this switch on all three STS2 chassis in the corner station, and when toggled to U/V/W, the spigot output went to 0.0 [V] (maybe occassionally we'd see a ~1 [mV] offset) and the ADC readout went to ADC-noise-level zero. So either we're missing something, or the U/V/W readout functionality is busted on these chassis. Hopefully, it's busted in the "it never worked" sense, and the X/Y/Z readout *is* actually the U/V/W readout, and we're constantly monitoring it.
Hurumph.
Anyways, as a by-product of this investigation, I (with the help of Jenn and Evan) wrote a python script called /opt/rtcds/userapps/release/isi/common/scripts/check_sts_centering.py that takes a 10 second average of these IOP channels (ifo is an input argument, but otherwise hard-coded to be the IOP channels mentioned in Brian's aLOG), calibrates them into "STS Volts," compares them against the 2 [V] threshold, and spits out whether an STS on site ios out-of-spec. Here's today's results, to show how the script works:
/opt/rtcds/userapps/release/isi/common/scripts$ ./check_sts_centering.py H1
Averaging Mass Centering channels for 10 [sec] ...
There are 3 STS proof masses out of range ( > 2.0 [V] )!
STS B DOF X/U = -4.446 [V]
STS EX DOF Y/V = 7.656 [V]
STS EY DOF Z/W = -2.429 [V]
All other proof masses are within range ( < 2.0 [V] ):
STS A DOF X/U = 0.367 [V]
STS A DOF Y/V = -1.019 [V]
STS A DOF Z/W = -0.359 [V]
STS B DOF Y/V = 0.751 [V]
STS B DOF Z/W = -0.422 [V]
STS C DOF X/U = 0.88 [V]
STS C DOF Y/V = -0.508 [V]
STS C DOF Z/W = -1.313 [V]
STS EX DOF X/U = -1.112 [V]
STS EX DOF Z/W = 1.111 [V]
STS EY DOF X/U = 1.025 [V]
STS EY DOF Y/V = 0.828 [V]
Assessment complete.
/opt/rtcds/userapps/release/isi/common/scripts$
We intend to, for now and now that it's so easy, check the STS centering every maintanence day. As Jenne suggests, we could take the script up another 10 levels and code it up as a guardian monitoring node for the SYS_DIAG to watch that'll then notify the operator only when it has surpassed the threshold, that way we don't have to remember to check. But we'll leave that for another scripter for another day. Script has been committed for use at both sites.
