SEI HEPI work at BSC3 Apollo removing the doors on HAM2 and HAM3 PSL power being set to 200mW SEI locking the HAM2 and HAM3 ISI SEI working on payload of HAM6 EE working on chassis modifications Kyle working on HAM2/HAM3 purge air
Jim and Dave. We are now running a HWWD version of h1susetmy compiled against branch2.8. The model was restarted at 11:16PDT. If we determine there is an error with channel 25 of the binary output chassis, we will replace that chassis.
[Mark Arnaud]
as reported on thursday, sustools.py has been updated in order to account for the new IOP wd state channel names.
By typing in the command line :
/opt/rtcds/userapps/release/sus/common/scripts/./sustools.py -o ETMX wdNames
The output returns all wd state channel names associated with this suspension, including the new IOP channel name:
['H1:SUS-ETMX_R0_WDMON', 'H1:SUS-ETMX_M0_WDMON', 'H1:SUS-ETMX_L1_WDMON', 'H1:SUS-ETMX_L2_WDMON', 'H1:IOP-SUS_EX_ETMX_DACKILL', 'H1:SUS-ETMX_DACKILL']
All sus guardians will be restarted and tested tomorrow
By doing this change (adding "ifo-rooted" iop channels), guardian machine ran into a memory issue, similarly as few months ago with ISI guardians.
Without going into details, we basically reverted the upgrade, meaning that guardian won't look at iop wd until further notice.
All sus guardians were restarted.
The MC1, 2 and 3 suspensions are now damped manually with the guardians paused for the HAM2 in-vac work. There was an issue with these guardians who reported some Ezca errors when they were in SAFE state. Arnaud and Mark will have a look at this issue.
For record purpose, here are the error messages in the SUS_MC2 guardian:
20140617_19:55:36.156 SUS_MC2 [SAFE]
20140617_19:57:31.994 SUS_MC2 W: if is_tripped(sustools.Sus(ezca)):
20140617_19:57:31.994 SUS_MC2 W: File "/opt/rtcds/userapps/release/sus/common/guardian/SUS.py", line 27, in is_tripped
20140617_19:57:31.994 SUS_MC2 W: trippedwds = susobj.trippedWds()
20140617_19:57:31.995 SUS_MC2 W: File "/opt/rtcds/userapps/release/sus/common/guardian/sustools.py", line 211, in trippedWds
20140617_19:57:31.995 SUS_MC2 W: result = []
20140617_19:57:31.995 SUS_MC2 W: File "/ligo/apps/linux-x86_64/cdsutils-238/lib/python2.7/site-packages/ezca/ezca.py", line 233, in read
20140617_19:57:31.995 SUS_MC2 W: pv = self._connect(channel)
20140617_19:57:31.995 SUS_MC2 W: File "/ligo/apps/linux-x86_64/cdsutils-238/lib/python2.7/site-packages/ezca/ezca.py", line 223, in _connect
20140617_19:57:31.995 SUS_MC2 W: pv.pvname))
20140617_19:57:31.995 SUS_MC2 W: EzcaError: Could not connect to channel (timeout=2s): H1:SUS-MC2_M1_WDMON_STATE
20140617_20:28:40.013 SUS_MC2 [SAFE]
20140617_20:28:42.076 SUS_MC2 [SAFE.run] ezca: connecting to ifo-rooted channel: H1:IOP-SUS_H34_DACKILL_STATE
20140617_20:28:46.083 SUS_MC2 W: if is_tripped(sustools.Sus(ezca)):
20140617_20:28:46.084 SUS_MC2 W: File "/opt/rtcds/userapps/release/sus/common/guardian/SUS.py", line 27, in is_tripped
20140617_20:28:46.084 SUS_MC2 W: trippedwds = susobj.trippedWds()
20140617_20:28:46.084 SUS_MC2 W: File "/opt/rtcds/userapps/release/sus/common/guardian/sustools.py", line 214, in trippedWds
20140617_20:28:46.084 SUS_MC2 W: trig = self.ezca.read(pv+'_STATE')
20140617_20:28:46.084 SUS_MC2 W: File "/ligo/apps/linux-x86_64/cdsutils-238/lib/python2.7/site-packages/ezca/ezca.py", line 233, in read
20140617_20:28:46.084 SUS_MC2 W: pv = self._connect(channel)
20140617_20:28:46.084 SUS_MC2 W: File "/ligo/apps/linux-x86_64/cdsutils-238/lib/python2.7/site-packages/ezca/ezca.py", line 223, in _connect
20140617_20:28:46.084 SUS_MC2 W: pv.pvname))
20140617_20:28:46.084 SUS_MC2 W: EzcaError: Could not connect to channel (timeout=2s): H1:IOP-SUS_H34_DACKILL_STATE
Arnaud's post from Friday implied that some of the watchdog channel names have changed. This is almost certainly what's going on here.
Fix the names in the guardian code! Presumably sustools.py needs to be updated.
09:02 Jason heading out for ITMX alignment measurements 09:05 Jeff, Andres working on dust monitors, expanding vacuum line, investigating INVALID alarm on dust monitor 6 09:52 Corey to roof of LVEA, end X and end Y to take pictures 10:09 Jason done with ITMX alignment measurements 11:19 Corey to LVEA to work on 3IFO ISC enclosures 13:17 DAQ restart for Thomas' Beckhoff code changes (WP 4690) 13:21 Hugh, Greg and Jim heading out to work on BSC3 HEPI 13:49 Cyrus to mid X and mid Y to work on CDS wireless 14:39 Cyrus back from mid X and mid Y 14:48 Hugo remotely updating SEI medm screens to reflect IOP DAQKILL changes (WP 4672) 14:51 Ed Merilh arrived visiting from LLO 15:42 Robert and Christina to HAM6 15:47 Hugh, Greg and Jim done at BSC3 Today was Ski's last day at LIGO. We wish him safe travels and the very best in his retirement!
Apollo got the cleanroon pulled back enough to allow us access for the Dial Indicators on the West side. Once we found a few appropriate ladders and got them wedged into place, we locked the platform and disconnected the Horiozontal Actuators from the Feet.
On Monday we'll get the load cells readers on and continue with the vertical actuator disconnect.
We might be ready to reposition (and IAS checks/direction) Monday afternoon.
Jim/Greg/Hugh
SEI MEDM screens were all updated (HAM-ISI, BSC-ISI, HEPI) to account for the recent changes in the IOP Dackill channels names.
Displays are fully functional again for both HAM-ISI and HAM-HEPI. (before/after - notes)
BSC-ISI and BSC-HEPI need the IOP DACKILL parts to be updated so channel names match with chamber names, as It is currently the case on HAM chambers. DaveB has agreed to do those changes, and the related model restarts, next week so the BSC chamber IOP DACKILL channels are named as follow:
$(IFO):IOP-SEI_$(IOP)_SEI$(CHAMBER)_DACKILL_STATE, with $(CHAMBER) taking the following values: 'BS', 'ITMX', 'ITMY', 'ETMX', 'ETMY'
Work was performed under DaveB's WP #4672
$(IFO):IOP-SEI_$(IOP)_SEI$(CHAMBER)_DACKILL_STATE, with $(CHAMBER) taking the following values: 'BS', 'ITMX', 'ITMY', 'ETMX', 'ETMY'
This is not correct, it should be:
$(IFO):IOP-SEI_$(CHAMBER)_DACKILL_STATE, with $(CHAMBER) taking the following values: 'BS', 'ITMX', 'ITMY', 'ETMX', 'ETMY'
This line too in the medms needed to be correct from $(IFO):IOP-$(IOP_NAME)_DACKILL_STATE to $(IFO):IOP-SEI_$(CHAMBER)_DACKILL_STATE
In preparation for HAM 3 door removal on Monday, I have removed both the camera and illuminator cans from HAM 3 west door. Gerardo was going to do a viewport inspection thereafter. The mobility equipment is on a table next to the beamtube between HAM 2 and HAM 3. Please try not to disturb this table as I have attempted to maintain the camera and illuminator orientation in them. The table is labeled as such.
J. O'Dell, myself
With Joe's help, we "re-payloaded" the ITMx Quad with sleeve and vibration absorbers to bring it back to ~full weight for HEPI height adjustment. The chamber has been sealed back up with the temporary aluminum door for cleanroom detachment.
I've installed wireless APs in both mid stations for the use of the vacuum group and CDS when working with systems there. They work the same as those in the other VEAs.
Measured the ITMx X, Y, Z position this morning after yesterday's SUS adjustments. The errors are as follows:
I've finished upgrading the camera code on h1digivideo0,1, and 2 under WP 4682. In addition to the code change, the startup scripts are now handled via Monit which means they can be controlled from the web interface with the link added to the overview MEDM. The servers will now start all configured cameras at boot as well as the supporting IOC processes, so they are self-sufficient except for needing /ligo to read the camera INI files. The only remaining work is to re-shuffle the camera assignments to balance them out and make room for new installs, which I'll do after coordinating with Filiberto hopefully sometime next week.
BSC3 HEPI needs to be moved to account for the ITMX height discrepancy Jason will make a final measurement of the ITMX position first SUS is missing payload which will need to be accounted for before the HEPI move bolts have been broken on HAM3 a full cleaning has been done on HAM3, a partial cleaning has been done on HAM2 Travis will remove mobility experiment equipment from the HAM3 west door plan to pull HAM2, HAM3 doors on Monday hold putting doors on HAM6 until next week Robert will be going into HAM6 again today laser work finished on H1 PSL frequency servo investigations to be done planned work in the H2 PSL enclosure Gerardo looking for washers to finish CPB assembly Quad install ongoing in the staging building Scotty cleaning storage can
model restarts logged for Thu 19/Jun/2014
2014_06_19 04:18 h1fw1
2014_06_19 04:26 h1fw1
2014_06_19 08:21 h1fw1
2014_06_19 10:20 h1fw1
2014_06_19 10:29 h1fw1
2014_06_19 11:57 h1fw1
2014_06_19 12:03 h1fw1
2014_06_19 12:15 h1fw1
2014_06_19 12:29 h1iopsusb123
2014_06_19 12:39 h1iopsusb123
2014_06_19 12:48 h1susitmy
2014_06_19 12:49 h1susitmy
2014_06_19 12:51 h1susbs
2014_06_19 12:51 h1susitmx
2014_06_19 12:54 h1iopseib3
2014_06_19 12:58 h1iopseib3
2014_06_19 12:59 h1hpiitmx
2014_06_19 12:59 h1isiitmx
2014_06_19 13:09 h1iopseib1
2014_06_19 13:11 h1hpiitmy
2014_06_19 13:11 h1isiitmy
2014_06_19 13:12 h1iopseib2
2014_06_19 13:14 h1hpibs
2014_06_19 13:14 h1isibs
2014_06_19 14:13 h1iopsusex
2014_06_19 14:17 h1susetmx
2014_06_19 14:19 h1sustmsx
2014_06_19 14:24 h1iopseiex
2014_06_19 15:24 h1hpietmx
2014_06_19 15:24 h1isietmx
2014_06_19 15:29 h1sustmsy
many unexpected restarts of h1fw1, which was fixed by rebooting the QFS server. SUS and SEI model restarts due to new IOP models on those frontends.
After the IOP watchdog upgrades, sus guardians need to be updated. They are all currently in an error state since asking for iop channels that do not exist anymore.
Transfer functions were ran during the day on the OMC in HAM6 in order to check for rubbing before closing the doors. The 6 dofs were tested and compared with the previous measurements chamber side (cf alog 8637). They all agreed perfectly so things haven't changed since then. Attached is the screenshot for one of the dof (yaw) in blue, compared with the previous measurement in black. Dtt files are saved under the svn as :
/ligo/svncommon/SusSVN/sus/trunk/OMCS/H1/OMC/SAGM1/Data/2014-19-06_1000_H1SUSOMC_WhiteNoise_$(DOF).xml
Follow up the investigation https://alog.ligo-la.caltech.edu/SEI/index.php?callRep=499 of the glitch present in the H1:ISI-ETMY before the WD trips pointing the ST1 actuator as the cause (Figure 1): - The glitch spectrum shows that it has a frequency of 10 - 70 Hz, with a peak in 40 Hz. (Figure 2). - The L4Cs and GS13s are good sensors for frequencies above 1 Hz, then we may use them for our investigation. - The ground motion is expected to be low frequency, so the glitch may comes from the ETMY chamber. - The transfer function between the sensors and the excitation should be approximately flat. - For an excitation of the ISI stage 2 in the X direction, the transfer function (TF) and coherence for L4Cs in ST1, GS13s in ST2, and OSEMs in the reaction chain R0 are shown in Figure 3, 4 and 5 respectively. Comments: - Even that the coherence is high, the TF shows a peak near 45 Hz for ST1 L4Cs and ST2 GS13s.
(Betsy, Travis, Joe O)
We spent all day today moving things around in an effort to verify that all 8 of the ITMx QUAD masses, the12 blade springs, and the 20 actuator/sensor pairs were free of mechanical intereference such that we could move on with height diagnostics. Yesterday, the QUAD was left in a state where there was obvious course yaw to deal with. Revisiting that today cause the usual QUAD ripple (ha!) effect where were ended up adjusting X, Y, Z, pitch, yaw, roll of many things since many are coupled mechanically. As I've stated before, it's a painful iterative process to get a correctly pointed, yet mechanically free QUAD.
At the end of the day, we think we have the main chain pointing back down at the IAS station (on beam path-ish) with sneak peaks of healthy PITCH and VERTICAL DOFs. SO, I deem this good enough for Jason to remeasure and repost X, Y, Z measurements in the morning. From there, SEI, please adjust HEPI to fix the height error he posts. Sorry.
I have nothing further to add to the history that Jason posted in an earlier alog regarding where we introduced the 3mm error we seemed to need for the pilot-ITMx but do not need now...
I'll be out for a 2 of the next business days, so my understanding of the events to take place in this chamber are:
- Jason measure X,Y,Z (Fri)
- SEI HEPI height accomodation - few days
-- Meanwhile, Travis "mic the ITMx TM-to-corner cube for Jason's new length assessment now that things have moved in the QUAD (Fri)
-- Meanwhile, Travis/Arnaud sneak peak TFs on R0 just so we know what to expect there for later next week (Fri, time permitting only)
We determined that this was not a hardware problem. I removed an EPICS-OUTPUT part between the HWWD and the delay part in h1susetmy and we were able to control the HWWD. So no binary chassis change at EY and we are able to control the HWWD. Unfortunately when I re-installed the epics part the communication continued to work, so we are not able to reproduce the problem.