After our success in controlling the EY HWWD with the h1susetmy model, I reverted the h1sustmsy back to its original model and rebuilt it against RCG2.8.3. This required a DAQ restart due to INI changes.
Once HEPI actuators are re-attached, I will take another look at position/yaw to make sure alignment is maintained within spec. After that IAS only needs to align the ITMx in pitch and the CPx in pitch/yaw.
Olli, Justin and Volker
Task: Set power at bottom of the PSL periscope to 200mW and rotate the polarization by 90 deg to resonate in the low finesse mode of the IMC.
The HWP for the main power control was "unlocked/untagged" and energized outside of the PSL enclosure.
First we measured the power after the TFP after the PMC. Initial value 20.5W.
Next we turned to the main power contro stage. While temporarily turning the power after the TFP down to 200mW we assured that the main power stage HWP is set to a value that dumps most of the power. After that we maximized the power after the TFP after the PMC to 23.1W (HWP turned to 208deg).
Now the power at the bottom of the periscope was set to 205mW by rotating the main power control HWP to 63deg.
Currently there is a HWP at the pottom of the periscope to control the polarization after the power control stage. Using this HWP the polarization was rotated to "p" to operate the IMC in low finesse mode. The angle of this HWP is now set to 46 deg.
We verified that the polarization is rotated by 90 degree using an additional PBS.
Finally, the HWP for the main power control was "locked/tagged" and deenergized outside of the PSL enclosure.
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.
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.