I have added some blinkies/flashies to the OPS_OVERVIEW medm screen. FSS: When the TPD Voltage drops below .9V a yellow alert blinker will appear under the FSS button. TCSX: A button similar to the one someone added for the Fast Shutter has been added and will turn red if the LASER should lose power. These are just for "heads-up" until something better can be arranged and implemented.
Just for referecne. If you want to decode a SWSTAT value use the following, and replace '#' with the SWSTAT value:
cdsutils sfm decode #
While Stuart and I were looking at SDF and GRD monitoring, we noticed that there were some empty filters that were requested to be on, but were not on. I've turned them off. Attached are the 2 screens where I found such benign filters in the half-state (ETMX L3 LOCK, and BS M2 COIL). They are off now. We intend to get new safe.snaps tomorrow so likely any remaining leftover empty filtering will be cleared out.
[Doug C, Jason O, Stuart A] We are planning a B&K hammer training session on an OpLev pier during the maintenance period tomorrow. I conducted a survey of current OpLev power spectra to help identify any particular piers that we should target. The power spectra (attached below) suggest some very low resonances (3.3 Hz & 6.6 Hz) for ITMY, so we shall focus our attention there. n.b.PR3 looks to be misaligned.
Note, while the PR3 OL looks to have been decentered in some event last week, the PR3 itself took a pointing jump yesterday. We might want to double check the PR3 alignment with comissioners before we bother recentering it.
Note, he the OL did not see yesterdays PR3 alignment, maybe because it is out of range.
Here are the trends for the past 10 days:
Seismic – Jim running tests on ETM-X, ITM-X, and HAM4 for Jeff K. Working on feed forward on HAM4 Suspensions – Stuart is rebuilding suspension models Installed switchable Mid-Stage coil Cleaning up old/unused channels PSL – Realigned the RefCav to bring power up to 1.5V. Tightened loose periscope mirror mounts. These could be the source of the alignment drift. 3IFO – Jodi and team parts hunting in the LVEA. They moved the IO parts top the staging building. The remaining three desiccant cabinets were moved to the VPW Danny checked optics for first contact The Seismic team moved the last BSC-ISI into its storage container FAC/VAC – Roughing on HAM1. Kyle needs to install a temporary gauge onto of HAM1 SnoValley – On site working on A/C at VPW and chiller yard OpLev – Modifying grout forms. Hope to start grouting OpLev piers next week
As a follow on from my alog last week (16811), I ran TFs on the PR2 while the largish IFO pointing offsets were enabled. With offsets of P = 1816, Y = 4315, the P and Y TFs look healthy. Phew.
With some guidance from T. Abbott, I have gotten the SUS Drift Monitor back up and functioning. I have updated all the suspension alignments to the most recent good lock stretch of 1108702216 GPS. After this update, a few suspensions were showing that they are misaligned from this previously good alignment.
PR3 - Pitch, not sure why this is aligned differently now. Trends show this changed Feb. 24 at 20:00 UTC. I could not find an aLog specifically stating that this SUS was touched.
SR2 - Changed Pit alignment to alleviate possible rubbing. See aLog 16831.
RM, IM, and OM alarm level are still in a state of flux. To be continued.
No significant changes from last week.
The version of root software used on x1work has been updated to root-5.34.21, the version of gds software for x1work has been updated to gds-2.16.12.4, to match what is used in the LHO control room.
The daqd and nds software for x1dc0, x1nds1, and x1fw1 has been updated to branch 2-9, r3965. It was fairly old, at r3626 and needed to be updated to test daqd protocol 12.1 with nds2 client software.
Since we started running feedforward on the BSC-ISI's, Jeff and Hugh noticed that the feedforward path is not controlled by Guardian. This means that if FF is engaged and the ready state is requested through Guardian, the St1 actuators will still be driving. From a safety standpoint, it looks like this probably isn't an issue. I took spectra this morning with the ITMX ISI off (FF off, too) and with FF only (no damping or isolation loops). The FF only state actually still provides some isolation above 1hz (see attached plot, dashed references are the off state, solid lines are FF only). I also turned HEPI off, then turned it back on while watching the ISI seismometers, and didn't see anything obviously terrible. The actuator signals stayed below a couple hundred counts the whole time, much like the ISI with damping only, and only the T240's got agitated while HEPI servoed to position, which is normal. It's still possible that whacking the HEPI piers could cause FF to do bad things, so...don't do that.
See JeffK's 16857 where he analyses the End Station's performance relative to the fluid pressure noise. The attached plots compare those final performance numbers for YEND from Sunday at 6pm pst with data taken 25 Feb at 0230utc -- after the EndY HEPI plumbing system maintenance detailed in 16899.
Bottom line--The DOFs still showing coherence on Sunday (Jeff's 16857) are all almost completely gone, there is still a bit of coherence in the HP dof in places between 10 & 100mhz. So this maintenance would appear to be very important. The DOFs remaining were the 'common' mode dofs. That is, the Z and the HP modes of the HEPI--those dofs where the Actuators move in common. All other dofs have counter moving actuators which one might expect a common noise like pump pressure to cancel out.
Now, understand, Jeff's work on the controller characterization and tuning provided most of the decoupling to the platform; this maintenance work just closed a few final loose ends.
The xml for these is /ligo/svncommon/SeiSVN/seismic/HEPI/H1/Common/2015-02-25_H1HPI_EndYStation_Coh_wISIT240s.xml
I spent some time tonight attempting to adapt the guardian codes to the new LSC and OMC models (alog 16893, alog 16904 ). I went through most of the guarduans by actually running them with the interferometer and tried fixing as many bugs as possible. Here is a summary of the guardian situation (red=bad, blue=OK):
In addition, a couple of associated parameter files (e.g. ISC_library, pdstep and etc.) were also edited for the same reason. Even though I could test most of the necessary parts, one should still pay attention to the codes as it is very likely that I have missed some bugs in there.
(For the ISC experts)
I have several items to mention.
Looking at some of the LSC demodulated signals, I found that the RF phases changed by some noticable amount. I then found that the CO2 laser on ITMX had been tripped at 13:51 local (or 21:51 UTC) today. I went to the rack at the floor and saw that a red indicator for 'TEMP' was on at the front panel. Power cycling the unit with the key untripped it. I pressed the red button for opening the gate and confirmed that the laser power was back to the nominal of 210-ish mW in the medm screen. The attached is a one day trend of the laser power, calibrated into the power at ITMX.
I did not do any deep investigations at this point.
ISC/SUS Code Changes
Daniel, Jeff, Kiwamu:
During the maintenace period the following models were restarted for new code: h1lsc, h1omc, h1alsex, h1alsey, h1asc, h1susetmx, h1susetmy, h1susitmx, h1susitmy, h1oaf, h1susbs. LSC to OAF Dolphin IPC channels were removed from the LSC, Daniel renamed the IPC channels being used by the OAF to their CAL equivalent channels.
DAQ Restart
To support the code changes and the new guardian system several DAQ restarts were performed.
Guardian Reboot
Jamie and Dave:
13:34PST the h1guardian0 machine was rebooted to test its autostartup. No problems were found.
RFM Diagnostics
Daniel, Jim, Dave:
To test the remaining IPC errors on the ETM SUS models, an ISC model (we chose PEM) was temporarily changed to read the same RFM IPC. The ISC receiver shows zero errors, so the problem appears to be within the SUS front end only. Investigation is continuing.
We perfomed some RFM tests on the LHO DTS, verifying the RFM loop transit direction.
[Stuart A, Betsy W] After earlier using the front-end to take a safe SDF snapshot of the Beamsplitter Suspension (see LHO aLOG entry 16886), thus stripping out the redundant read-only channels and alarms, I used Jamie's script to set all channels to be monitored (see LLO aLOG entry 15907) i.e. sdf_set_monitor 1 h1susbs_safe.snap. I've since manually edited the SDF snapshot setting channels we do not wish to monitor, which are essentially consistent with those reported at LLO (see LLO aLOG entry 15987). Finally, I've checked the safe SDF snapshot into the svn: /opt/rtcds/userapps/release/sus/h1/burtfiles/ M h1susbs_safe.snap Need to monitor for changes in the BSFM configuration as commissioning/locking continues overnight...
Added 352 channels. Removed 302 channels. There are still 7 channels unmonitored: H1:GRD-ISI_ETMY_ST2_REQUEST_S H1:GRD-ISI_ETMY_ST2_STATE_S H1:GRD-ISI_ETMY_ST2_STATUS H1:GRD-ISI_ETMY_ST2_TARGET_S H1:GRD-ISI_ITMY_ST1_LOGLEVEL H1:GRD-ISI_ITMY_ST1_MODE H1:GRD-ISI_ITMY_ST1_NOMINAL_S
They connected, just took a little while.
Kyle, Gerardo Added remaining bolts to HAM1 West door and finished torquing -> Soft-closed GV5 and GV7 (GV5 hard-closed on its own at only 20 psi) -> Pumped HAM1 with scroll pump via vent/purge valve (as such, atmospheric pressure remains on air-side of closed vent/purge valve) -> Opened GV5 and GV7 Richard M. is investigating getting signal cables to HAM1 gauges
Kyle, Gerardo ~0910 hrs. local, Wednesday morning -> Installed temporary pirani gauge controller on top of HAM1 so as to view pressure until CDS cabling gets installed -> HAM1 now showing 0.4 torr which is as expected. In retrospect, I should have not pumped HAM1 without this to monitor -> I had reasoned that the view ports are exposed to 2 atmospheres (gauge) differential (both directions) during bench testing so are considered "safe" -> I now consider the failure mode whereby a view port could have cracked during pumping resulting in a measurable change in the pump down curve -> In this scenario we would not have opened GV5 and GV7 -> Lesson learned
There are a couple of other useful SFM tools inside of cdsutils as well:
You can get a textual display of the full current state of a filter module by using the 'switch' command without any arguments (note the leading "H1:" IFO prefix is optional):
The 'sfm' command can also guess that you're looking to decode a SWSTAT:
Note that SWSTAT doesn't include the "_ENGAGED" status bits that are included in the 'switch' readback above. But you can also give 'sfm' SW{1,2}R values to get the full status:
See 'cdsutils sfm -h' for help: