There are 3 in-vac thermistors mounted to the OPO. The first one is read through the TEC controller and works fine. The other 2 are reading zero Ohms. The wiring is correct up to the Squeezer EtherCAT chassis 3, indicating it has an internal wiring problem.
The Peltier heater works too. The controller parameters and loop shape were imported from LLO, and the servo works in-air.
Carlos and I racked the new hardware for h1tw0. The old hardware has been pulled from the racks.
Ran SEI seismometer mass position checks. The following are out of range: There are 13 T240 proof masses out of range ( > 0.3 [V] )! ETMX T240 1 DOF X/U = -0.345 [V] ETMX T240 1 DOF Z/W = -0.578 [V] ETMX T240 2 DOF X/U = -0.491 [V] ETMX T240 2 DOF Z/W = -1.077 [V] ETMY T240 1 DOF Z/W = -1.013 [V] ETMY T240 2 DOF Y/V = -0.852 [V] ETMY T240 3 DOF X/U = -0.912 [V] ETMY T240 3 DOF Y/V = -0.392 [V] ITMX T240 1 DOF X/U = -0.594 [V] ITMX T240 2 DOF Z/W = 0.343 [V] ITMX T240 3 DOF X/U = -0.671 [V] ITMY T240 3 DOF X/U = -0.677 [V] ITMY T240 3 DOF Z/W = -1.293 [V] and There are 2 STS proof masses out of range ( > 2.0 [V] )! STS A DOF Y/V = -4.67 [V] STS A DOF Z/W = 5.894 [V] All other T240s and STSs are reporting in range.
Trends reflect ongoing work during 70W installation.
Both DNS servers were upgrade to Stretch (Debian 9) this morning and place under puppet management. no unexpected events during upgrade process happened. Some user may experience and few (maybe 3 to 5 ) seconds delay on their Internet browsers when accessing some website, that is due to the DNS servers updating/reloading their cache.
J. Kissel During the teething period for ZM1 (for most relevant aLOG see LHO aLOG 40847), I've identified that I have been mistakenly and blindly installing COILOUTF gains for the HTTS (Ham Tip Tilt Suspensions; OM1, OM2, OM3, RM1, RM2, ZM1, ZM2) that match the magnet configuration of a QUAD UIM (E1000617) instead of what they've been built to be (E1400316), which is exactly opposite the QUAD UIM. Thus, damping loop feedback gains have been positive for quite some time. I have now remedied this flaw in sign allocation on all** HTTS, and saved the the change into the SDF system (and committed the safe.snaps to the userapps svn). This has three main benefits: - The COILOUTF signs vs. Magnet polarities are now consistent with other BOSEMs / magnet systems. - Each DOF's M1 to M1 transfer functions now show an overall 0 [deg] phase at DC, and decreases to -180 [deg] above resonance as one expects from a single-stage suspension. - The allocation of signs understandable from a simple logic thread, as defined in T1200015. Just to be explicit, the correct COILOUT gains are UL = +1 (for N), LL = -1 (for S), UR = -1 (for S), LR = +1 (for N). and all feedback damping loop gains are -1. ** All excludes RM2 -- because it has always had the opposite damping loop sign as the other (now) 6 HTTS. I suspect it's because RM2 *actually* has its magnet polarities incorrectly in the QUAD UIM BOSEM configuration. Thus, I've left the COILOUTF in the configuration to compensate for it, this way we're correctly compensating for the incorrect magnet polarities, and we can have a negative feedback gain on the damping loops like every other HTTS. Thus, for RM2 only, FOR RM2 ONLY UL = -1 (for S), LL = +1 (for N), UR = +1 (for N), LR = -1 (for S).
Sheila, Dave Barker
I have made several model changes for squeezing with help from Dave for some debugging.
The models which have been compiled and checked into the svn are:
omc/common/models/omc.mdl omc/h1/models/h1omc.mdl asc/common/models/ASC_MASTER.mdl asc/h1/h1asc.mdl sus/h1/models/h1susopo.mdl sqz/common/models/SQZASC_MASTER.mdl sqz/common/models/h1sqzwfs.mdl
I also changed sqz/common/SQZ_MASTER.mdl and sqz/h1/models/h1sqz.mdl but have not checked them into the svn because they don't compile. Dave and I will continue to look at that tomorrow.
The changes to h1susopo.mdl were just to add IPC receives from sqzwfs for ZM1/2 pit and yaw.
The changes to the omc models were just to add IPC senders that send the DCPD null and sum to the SQZ_MASTER model. There are already IPCs sending SUM and NULL to the calibration model, but with normalizations that are not quite the same for sum and null. I decided to just add new IPCs so that we don't need to worry about settings in the calibration models for the squeezer.
The changes in the ASC models were similarly just to add IPC sends. We are now sending AS_C sum to SQZ_MASTER. This is used for the seed phase locking I added a few months ago, which we haven't used yet. (You can try to lock the phase of the seed beam to generate a stable 1064nm beam out of the OPO, I was thinking this might be useful while we are in chamber trying to scan or lock the OMC, although it wasn't used at LLO.) The rest of the senders added to ASC are AS QPDs which are added to the SQZWFS input matrix so that we can close some simple alignment loops around the ZMs while we are working on the alignment without the full interferometer.
In the SQZ_MASTER model I added some blrms for the DCPD sum and nullstream, which we can use to make monitors of the squeezing level. I also added code for a noise lock which can dither the LO loop lock point, demodulate one of our BLRMs, and feedback to the lock point of the LO loop. There is also the option of demodulating the CLF Q signal, or the DCPD Q signal (or the homodyne 3MHz signal), which was an idea that Lee suggested for setting the LO demod phase. Right now this has an output matrix which only allows the signal to offset the lock point of the LO loop, but other options could be added.
Bugs:
Dave helped me to debug a problem in the sqz wfs model. I had originally not given descriptive names to the input and output ports on the subsystems, using the default in1, in2, ect. I attempted to rename these to more descriptive things this time, like AS_A_RF42_I_PIT, which was fine in the SQZ_ASC block, but when I tried to do this in the ASC block the RCG gave bogus errors and would not compile. We have left these as non descriptive names. We are currently having trouble compiling h1sqz because the RCG isn't creating automatically generated medms for the new dither lock.
J. Kissel, T. Shaffer TJ has flipped the flag/magnets on H1 SUS ZM1 such that they now obey E1400316 as designed. I've also flipped the sign on the COILOUTF gains, such that make sense according to T1200015. Great! But, sadly, in flipping the flags, the suspension is now rubbing, as shown by especially the Y to Y transfer function which now shows a second, unexpected resonance at 1.17 Hz (which is *not* the first L/P mode at 1.26 Hz, nor the first P/L mode at 1.68 Hz). Also, the P to P transfer function shows an abnormal change in the mid-resonances zero, and the (what should be the only) Y to Y resonance has shifted down in frequency. Hurumph. When TJ came in he was mentioning that the OSEMs weren't well centered any more, and he later guesses that it's because the re-installed flags weren't as straight as he'd liked. Sounds like he's got an idea or two on how to free up the rubbing, so hopefully tomorrow's fix will be easy.
CP4 is cooking along. Smells real good at mid-y now. I forced the enclosed air temp to rise faster than 1C/hr for several minutes to test ROC alarms, which we found work as intended, along with max temperature alarm. The setpoint is now 110C (TC#1 measuring 76C now, with some fluctuations due to testing). We will continue to monitor overnight with assurance that we have text alarms to help out.
The Y1 arm pressure is increasing. GV11 and BSC replacement spool are relatively wet compared to beam tube and thus outgassing. We discussed closing GV10 and valving in main turbo (and small IP below CP1); still contemplating that (WWJD?). May take action if/when Y1 pressures exceed the turbos ultimate pressure (~5e-8 Torr). Alarms for Y1 have been adjusted to 5e-8 Torr setpoint. CP4 pressure raised to 5e-5 Torr.
Bubba turned the VEA chiller on this morning to help control room temp. It was approaching 70F.
J. Kissel, T. Shaffer Last Friday, I told TJ to flip 2 of the 4 H1SUSZM1 magnets (UR and LR) because I'd found that I needed to flip the signs of the corresponding COILOUTF bank to make the transfer functions look clean (see LHO aLOG 40808 and subsequent comments). In doing so, I'd insisted that "sadly, all HTTSs (except for RM2) have their magnets oriented exactly opposite to their documentation" (the controls arrangment poster, E1400316), and concluded that -- instead of fixing every other HTTS -- we convert ZM1 to the "wrong" convention such that they're at least all the same. This statement was based on the sign of the required damping loop gain, assuming all other digital signs were correct. This morning, he flipped magnets according to what I've insisted, so I re-took transfer functions. They revealed the phase remained zero at DC, instead of being -180 like every other HTTS, implying that I understand the magnet polarities exactly wrong. Upon closer inspection and a review of all signs with TJ, we've identified the real problem is because I have been blindly obeying the sign convention table in T1200015 for "BOSEM 4 OSEM Stage" when it comes to the COILOUTF gains. However, this table was created for the QUAD's UIM stage (the only other 4 OSEM stage in the IFO that has BOSEMs). The QUAD's UIM, BOSEM 4 OSEM magnet orientation, as shown in E1000617, is exactly opposite that of the HTTS. #facepalm. So, after apologizing profusely to TJ, I've asked him to now flip both sides flag/magnets to be exactly as is shown in the HTTS controls arrangement poster (again, E1400316), namely UL UR N S S N LL LR and now *I* need to change all HTTS's COILOUTF gains: Are Now Should Be UL -1 +1 LL +1 -1 UR +1 -1 LR -1 +1 so that the BOSEM coils obey the correct push-pull force table at the top of T1200015, damping loop gains can be an easily understood -1. I'll sure to check with LLO to make sure they update, if needed, and then make a new version of T1200015 that specifies the difference between a QUAD and an HTTS BOSEM 4 OSEM stage.
I have oriented the magnet flags as you have listed above. I could not check the polarities of the magnets in their PEEK holders due to their lack of strength, but I could check the polarity of a magnet that was on one of our dental mirrors (thanks Cheryl and Jeff for the idea). I then could confirm that the magnets were as we expected and that their new locations matched Jeff's above scheme.
Plots in the attached file show a large glitch in the FLOWRATE that also shows up in other signals. Glitch seen in QPD segments, and LASERTEMPVOLTAGE.
During the glitch in the FLOWRATE, the LASERTEMPERATURE instantaneously dropped by almost -0.5C, which is not physically possible.
The QPDs also glitched.
There's one box that reads the laser temperature and the QPDs, D1300649.
I don't know if this is the same box as the one in alog 33816, from Feb 2017, because I might have missed an alog where it was swapped out.
The box in alog 33816 was uninstalled, tested, and reinstalled, and had some voltage changes due to how it was positioned on the table, and voltage changes when someone was touching the outside of the box.
The signals I saw glitch today do not go through the TCS controller box, D1200745.
The laser temperature is on line 28 in the block diagram although the numbering is identified in the Bill of Materials: https://dcc.ligo.org/E1400342 - apparently to prevent redundancy but inadvertently making it much more difficult to track down cable numbers. This does go back through the CO2 controller.
So we're seeing glitches that involve two separate boxes.
WP7392 Chandra, Dave:
Y1 Beam Tube Gauge, Increase Alarm Level
H0:VAC-LY_Y4_PT124B_PRESS_TORR and H0:VAC-MY_Y1_PT243B_PRESS_TORR high alarm level increased from 5.0e-09 to 5.0e-08 Torr
CP4 Gauge, Increase Alarm Level
H0:VAC-MY_Y4_PT245B_PRESS_TORR high alarm level increased from 5.0e-06 to 5.0e-05 Torr
Added Thermocouple Channels And Their Associated ERROR Channels
H0:VAC-MY_CP3_TE202A_DISCHARGE_TEMP_DEGC added with high alarm 8.0e+01 C. H0:VAC-MY_CP4_TE253A_REGEN_TEMP_DEGC added with high alarm 4.0e+01 C.
CP3 TE202A Rate-Of-Change Alarm Added
The new Rate-Of-Change system was installed on h1fescript0. Two programs are running as background processes: epics_rate_of_change_ioc.py and epics_rate_of_change.py. Both are being ran as user controls.
The 1 HOUR ROC channel was added to the alarm system, with alarm levels +/-1.0 degCperHour.
<Channel name="H0:CDS-ROC_VAC_MY_CP3_TE202A_DISCHARGE_TEMP_DEGC_1HOUR" low="-1.0e+00" high="1.0e+00" fields="0" description="CP3 TE202A ROC">
note fields="0" needed as this channel is being server on a pcaspy IOC and is missing the VAL, STAT and SEVR fields.
No PSL status checks run as the PSL is down for the 70W amp changes. Closing FAMIS # 7480.
Sheila Daniel
We couldn't see the thermistors after connecting the in-vac sqz cables. Investigating, we found that the signals can be found on cable 303 rather than 304 at the sqz satellite chassis; and the PZTs seem to show up on cable 304 rather than 303. The DCPDs show up as expected on 305. As a side note, we noticed that for DCPD2 the case is connected to the anode, where this is not true for DCPD1. The sqz satellite chassis seems to short the case to the cathode, so this looks like an unwanted short.
We traced the cables to the vacuum flange and found them to be connected correctly, indicating that they are swapped in the chamber. Taking a look inside, we couldn't figure out how relate the cable harness routing described in D1300122 with what is installed. We gave up and left the cables disconnected at the satellite chassis.
Hugh and I went in and checked each cable down from the flange and the short seems to be either in the DCPD2 box or the cable leading out of it. I left the 9pin cable bracket unplugged until we have an idea what to do with this.
While I was in there I also swapped the two cables that connected to D1700439 & D1700438 (Termistors and PZTs).