The login scripts have been modified for the controls account to allow use of the account for either H1 or H2. This should have minimal impact on H2 users. Let me know if there are problems with the environment for controls.
Jim & Greg adjusted the level of the HAM3 ISI Table using HEPI Springs. It was a little slower than expected. We are ready for IAS to take another look before we continue with the HEPI Actuator installation.
As of around 4pm, sounds like the Gate Valve (GV18) will be opened tonight for OAT work.
John W. observed that actuating GV18 for 4 minutes and 18 seconds did not hard-close the valve, i.e. is a good value to use for soft-closing GV18. History: The individual actuation times resulting in a hard closure of the beam-tube valves (electric) was observed and recorded early on. This value is used to determine the actuation time to soft-close a given (electric) beam-tube valve. We are now wanting to record the actuation times of all of the electric valves.
Rebooted h2pemeyaux at 17:55 PDT July 10 to set IPMI address to correct value after reassigning the IP address of the computer, following dcuid value changes to the models running on the machine.
I started the evening shift with calibration of the VCO + Frequency divider used for the ALS PLL (S1200570 and S1000748). The objective was to measure the response of the VCO output to its Tune input, which is used for locking the arm cavity and thus provides a good calibration point for the arm cavity signal.
I set up the DC calibration measurement with a signal generator (output displayed on a scope to be sure), and a frequency counter. I took 6 samples between -1V and 1V, which resulted in an excellent linear relationship: f = 39.6MHz + 139 kHz/V * V_tune. For example, at V_tune = 1V, I measured f = 39.739 MHz. This is not the expected result of 50kHz/V given the nominal 100kHz/V from the VCO and the division by 2 which takes us from 80MHz to 40MHz.
From there I moved on to measure the AC response. I did this by rigging up a frequency to voltage converter with some bubble gum and duct tape I found nearby. The output of the converter was 725mV / V_tune. With the help of an SR785 and a lot of patience I turned this into a response measurment between 0.5Hz and 10kHz. I saved the curves on the SR785 floppy, which is a lot like throwing them into a black hole, so I also wrote down a few points: {-30.7dB, 178dg} at high frequency, {-27.7dB, 138dg} at 40Hz, {-16.8dB 112dg} at 8Hz, {-5.8dB, 136dg} at 1.6Hz and {-3.26dB, 136dg} at 5.62Hz. These are well fit by the measured DC response and the expected 1.6Hz pole and 40Hz zero.
Lastly, in preparation for using this calibration for the arm cavity, I cabled up an SR560 to the IR_PWR_MON channel. The SR560 is AC coupled with a gain of 10, and the tabletop interface gain is set to 10. From the output of the SR560 to counts of IR_PWR_MON, I measured 32060 counts/V. Just to be sure, I checked the gain of the SR560 and appears to be very close to the stated value of 10, so we should expect 320.6 counts/mV refered to the SR560 input, which is attached to V_tune. Assuming the above VCO calibration is correct, this converts to 0.434Hz/count as seen at IR_PWR_MON. The cavity should lock should convert length to frequency as L_cavity / f_laser = 3995m / 5.635e14Hz = 7.09 pm/Hz, so we will be left with 3.07pm/count as our length calibration. (To relate this to the number found with the OSEMS in 3363, we should remove the gain of the SR560, the TTIF box, and another factor of 10 for the FMON signal filtering. This would give 3nm/count instead of the 1nm/count found with the BOSEMS, so somewhere we're missing a factor of 3, not unlike the 139kHz/V vs. 50kHz/V discrepence... to be investigated tomorrow in the light of day.)
On a side note: I found the PLL unlocked and no beatnote evident. On closer inspection there was no light coming from the fiber, so I went to the optics lab and found the laser in Standby. I have no idea why it would be left in this state, since this clearly makes cavity work impossible. That should have been enough to make me leave it as I found it, but instead I turned it back on and relocked the reference cavity. From the trend data, it looks like it unlocked about 15 hours ago (at 16:20 UTC, see figure).
A harder look at the VCO schematic lead Keita and I to believe that 139kHz/V is plausible. Also, the FMON path has a DC gain of 0dB and gain at HF of 40dB (2 zeros at 10s, 2 poles at 100Hz), so the relation to the OSEM calibration in entry 3363 is 0.3nm/count from the VCO calibration (above) vs. 0.8nm/count from from OSEMs. Still a factor of ~3 is missing.
Short story: I created a manual burt backup and burt restore script to back up the PLL and PDH common mode board settings in the EY Beckhoff system. You can find them in /ligo/home/controls/bram.slagmolen/burt/h2etcatey and are called h2ecateyBurtbackup and h2ecateyBurtrestore. They use a local autoBurt.req and safe.snap file.
Long story: Every time the beckhoff system in EY breaks all settings are losts, this greatly inconvience the the locking of the PLL and the PDH system.
Patrick T. generated an autoBurt.req file from Beckhoff system h2ecatey at EY with all the epics channels.
With help from Dave we created and place the autoBurt.req file in the target directory and created a safe.snap file in the burt/ direcotry (burtrb -f autoBurt.req -o safe.snap).
> controls@opsws5:burt 0$ pwd
> /opt/rtcds/lho/h2/target/h2ecatey/h2ecateyepics/
I edited the autoBurt.req file adding 'RO' infront of some channel names, this prevented some errors while creating the .snap file.
When trying to restore from the .snap file, not all settings are restored correctly. With some digging around, it seems that when we added and set '.ZNAM Off ' and '.ONAM On' to the variable names it seemed to work. In addition in the autoBurt.req file I added .VAL to the same channel names. I only did this to few required channels in the PLL and PDH CM path. After a burtrb the burtwb worked correctly.
This is seemed only required for the toggle swithces. Why this is required I don't know, although this doesn't happen with the QPD whitening channels. I think the OPC database may need some work.
When the Beckhoff system is rebooted all the .ZNAM and .ONAM addition are lost. I made a little script set_ZNAM_ONAM_records to add these again (not tested but should work).
A listing of the directory follows:
controls@opsws5:h2etcatey 0$ pwd
/ligo/home/controls/bram.slagmolen/burt/h2etcatey
controls@opsws5:h2etcatey 0$ ls -al
total 156
drwxrwxr-x 2 controls controls 4096 2012-07-10 18:44 .
drwxrwxr-x 3 controls controls 4096 2012-07-10 15:53 ..
-rw-rw-r-- 1 controls controls 28005 2012-07-10 17:39 autoBurt.req
-rw-rw-r-- 1 controls controls 27971 2012-07-10 16:17 autoBurt.req~
-rwxrwxr-x 1 controls controls 241 2012-07-10 18:20 h2ecateyBurtbackup
-rw-rw-r-- 1 controls controls 38 2012-07-10 16:55 h2ecateyBurtbackup~
-rwxrwxr-x 1 controls controls 225 2012-07-10 18:21 h2ecateyBurtrestore
-rw-rw-r-- 1 controls controls 34666 2012-07-10 18:23 safe.snap
-rw-rw-r-- 1 controls controls 31283 2012-07-10 17:01 safe.snap~
-rwxrwxr-x 1 controls controls 716 2012-07-10 18:44 set_ZNAM_ONAM_records
-rw-rw-r-- 1 controls controls 703 2012-07-10 18:09 set_ZNAM_ONAM_records.txt
-rw-rw-r-- 1 controls controls 498 2012-07-10 18:07 set_ZNAM_ONAM_records.txt~
controls@opsws5:h2etcatey 0$
Patrick updated the OPC database. He rebooted the Beckhoff and it recovered its settings.
He generated a new autoBurt.req file, which was copied to the target directory.
Doing my local burtback up and burt restore without any modifications to the channel names or burt files seemed to work.
An hourly burt back up is performed automatically and the .snap files can be found at /ligo/cds/lho/h2/data/burt/{year}/{month}/{day}/{date-time}/
Attached are plots of dust counts > .5 microns in particles per cubic foot.
Work resumed following yesterday's "Stop Work" and today's subsequent "Stop Work Release"
The first thing I found in the morning was that Beckhoff was dead.
On Windows computer that runs Beckhoff, both of two PLCs showed an error message dialog box ("connection error" or some such) and it was not talking to the hardware.
Alexa did several attempts to make it work without rebooting Windows, but eventually Patrick rebooted Windows.
This did the trick, but it had a side effect of wiping the settings for OPC variables (again).
Bram is working on a sad implementation of burt restore.
Jim Jason & Hugh The Initial Alignment Subsystem(IAS) crew gave us the bad news late morning and we translated East 5mm shortly after lunch. Given all the initial movement we saw on the Dial Indicators when we first floated & further when we tweaked the level yesterday, I'm not surprised by this shift requirement. And you all have heard my spiel about from where our initial position originated. Anyway, after the East shift we were almost bang on N-S & rotationally with ~.5mm & 300urad to correct. That done, East-West checked again and still good. Now back to level and elevation: our runout on the table level is 0.3mm and we are ~0.4mm low in elevation. Tomorrow we will bring this back in and attempt to equalize the load cell readings while we are at that and finally followed by a revisit of the table position by IAS.
The attached pdf plots the first transfer function measurements completed on the H1SUSMC2 triple suspension slated for the HAM3 install in the LVEA (chamber-side). The suspension has been cabled and powered by the H1 Production electronics. After the assessment of the BIO switch cabling by Richard M., the CDS crew were able to configure the CDS network to allow awgstream excitations to the H1 electronics. The measurements were run on a newly-configured H1 workstation in the Control Room named "opsws0". The results are postitive with excellent coherence on all DoFs. The resonances are clearly visible and match reasonably well with measurements from the Staging Building. --------------------------------------------------------------------------------------------------------------- As a note to other users of DTT on the new H1 workstations: To open a DTT session with the correct server configuration settings, special command line arguments must supplement the usual "diaggui" command. The H1 channel lists are now grabbed from the "h1nds1" server. To open DTT on H1: >> diaggui -n h1nds1 -m 8088 ---------------------------------------------------------------------------------------------------------------- DTT XML files: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Data/ 2012-07-10_H1SUSMC2_M1_WhiteNoise_L_0p01to50Hz.xml 2012-07-10_H1SUSMC2_M1_WhiteNoise_T_0p01to50Hz.xml 2012-07-10_H1SUSMC2_M1_WhiteNoise_V_0p01to50Hz.xml 2012-07-10_H1SUSMC2_M1_WhiteNoise_R_0p01to50Hz.xml 2012-07-10_H1SUSMC2_M1_WhiteNoise_P_0p01to50Hz.xml 2012-07-10_H1SUSMC2_M1_WhiteNoise_Y_0p01to50Hz.xml Individual (by DoF) and coalesced PDF files are located in: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Results/ 2012-07-10_H1SUSMC2_M1_WhiteNoise_All_DOFs_0p02to50Hz.pdf
Round 1 of HAM 3 table axial positioning, translation setting, rotational positions are dialed in. A second alignment will be done tomorrow after ISI crew completes their installation and we re-level the table. Alignment tooling worked well an is simple to set.
Craning work in the LVEA in the morning hours End-Y Optical Lever cover installation Richard M. at End-Y to cable WFS and Beckhoff system Rebooting of H2 machines by CDS during the Tuesday morning maintenance hours (8:00AM - 12:00PM) Closing of Gate Valve 5 by Kyle Transfer function measurements on H1SUSMC2 by Jeff G.
J. Kissel, P. Fritschel, Curious about the various features seen in Matt's spectra of the cavity length, Peter and I grabbed some data during the long stretch of cavity lock that Matt mentioned. Attached are the results: We show the ASDs of - (What we believe to be) Ground Seismometer at IY, (we think) Y direction [(we think) uncalibrated] - (What we believe to be) Ground Seismometer at EY, (we think) Y direction [(we think) uncalibrated] - Input to the Isolation Filters of Stage 2 of BSC8-ISI (ITMY), Y direction in [nm/rtHz] - Input to the Isolation Filters of Stage 2 of BSC6-ISI (ETMY), Y direction in [nm/rtHz] - The input to the cavity control loop at the TOP / M0 of the H2 SUS ETMY, in L [uncalibrated] and the coherence between all of the above with respect to the cavity length signal. A couple of things that we can tell from these plots: - The 0.12 Hz peak in the cavity L signal is most likely indeed just the micro-seism (even though it's incoherent with these Y direction sensors), because the frequency content of the ASD is roughly the same. - The 1.05 Hz peak in the cavity L signal, which we believe is the second L/P mode of the QUAD, is NOT present in the ISIs or on the GND. - The 0.43 Hz peak in the cavity L signal, which we believe is the first L/P mode of the QUAD, is also not terribly present in the the ISIs or the GND - The BSC8-ISI (ITMY), which (we believe) has HEPI displacement sensor loops and high-blend ISI isolation loops, is directly, coherently transmitting ground motion into the cavity, as told by the coherence, between ~0.4 and 1.0 Hz -- and BSC6-ISI (ETMY) is not. I convinced myself that this made sense for BSC8-ISI (ITMY), because both the HEPI displacement sensor loops and the high-blend, mostly displacement-sensor-up-to-0.75 Hz, ISI loops are actively "locking" the platforms to the ground. The only sensible thing we could come up with for why the GND and ISI at the end were not coherent would be if the GND Y was not actually, as in the sensor was rotated, or we picked the wrong channel, or it was poorly labeled, or whatever. BUT that doesn't explain why the BSC6-ISI (ETMY) sensor was incoherent with the cavity length... - It's confusing as to why the micro-seism is incoherent with everything. Food for thought! ------- Data is stored and committed to /ligo/svncommon/SusSVN/sus/trunk/Common/Data/2012-07-10_H2OAT_ASDs.xml
Valved-out, removed, cleaned, adjusted and reinstalled. Valved-in -> Working OK now. No interruption to purge air supply
We've found two discrepancies between the ADC/DAC channel assignment document T1100472 and the end station ISC wiring document D1100670. After some discussion, we decided that the right way to proceed is to change the channel assignment in the model and update T1100472. The model was already updated but the document is yet to be done. Physical wiring was not changed at this time.
1: CM boards fast readback channel assignment
We have two CM boards at the end station, one for PLL and one for PDH, and the fast readback looked like they were swapped.
According to the wiring diagram, the first CM board is PLL and the second one is PDH. Which means that the PLL CM board uses the first ADC DB9 input for AA for ADC 1 and PDH uses the second. Physical wiring as well as slow control follows this convention.
OTOH, the channel assignment document says that DB9_1 for ADC1 is used by PDH and DB9_2 is PLL. h2iscey model follows this.
We decided to change the channel assignment so everything agrees with everything.
2: Misc. diodes DC fact readback channel assignment
There are two kinds of photodiode DC output, one is the DC of the legacy iLIGO RF diode and the other is the output of generic diodes (e.g. PDA 100A) via the new aLIGO generic tabletop interface.
In the wiring diagram, the legacy output is not connected to the fast readback at all. The generic interface is connected to the third DB9 of AA input for ADC1.
In the channel assignment document, DB9_3 for ADC1 is used by the iLIGO RF diode (PDH_DC) and the generic interface uses DB9_4.
We decided to leave the physical wiring alone, but swap the channel assignment (i.e. DB9_3 for generic and DB9_4 for legacy) in the model.
Each DB9 holds up to four channels, and before the model change DB9_3 and DB9_4 used to hold a total of 4 channels.
After the change, each of these have 4 channels.
In DB9_3, PD1 is the new channel H2:ISC-ALS_EY_REFL_PWR_MON (which is a diode in the Hartman WFS path). Three old channels that already existed were shifted by one slot (PD2=red power monitor, PD3=green power monitor, PD4= PLL DC power).
In DB9_4, we have four channels (PDH DC, AUX1, AUX2 and AUX3 in this order). AUX channels are new (but PDH DC was not available in reality anyway, because there was and is no physical connection to the AA, it was/is only connected to Beckhoff). We need another cable going from the field to the AA chassis to actually use these four channels.
To clear up some confusion, everything was conforming to one document or the other. It's not like something didn't agree with any document.
Field wiring and Beckhoff model was made according to the wiring diagram.
ISC frontend was made according to the channel assignment document.
HAM-ISI Unit #6 was balanced, and CPS readouts were within acceptable range, on 07/03 when we left it for long TF measurments. When checked this morning, CPS readouts featured an offset of approximately +/-3000 counts:
|
|
07/03 |
07/09 |
Difference |
|
H1 |
-387.82 |
2014.8 |
2402.62 |
|
H2 |
-15.363 |
2259.8 |
2275.163 |
|
H3 |
291.12 |
2534.3 |
2243.18 |
|
V1 |
-80.917 |
-3112.1 |
-3031.183 |
|
V2 |
-38.773 |
-3118.5 |
-3079.727 |
|
V3 |
119.34 |
-3054.5 |
-3173.84 |
There is no drive/offset on MEDM channels.
Coil drivers were turned off. The CPS readouts remained unchanged.
CPS interface chassis were turned off, and then turned back on. The CPS readouts remained unchanged.
Dataviewer plots are attached. They show the drifting of the CPS readouts.
We experienced high temperatures over the last few days.
| 3-Jul | 9-Jul | Difference | |
| H1 | -387.82 | 2014.8 | 2402.62 |
| H2 | -15.363 | 2259.8 | 2275.163 |
| H3 | 291.12 | 2534.3 | 2243.18 |
| V1 | -80.917 | -3112.1 | -3031.183 |
| V2 | -38.773 | -3118.5 | -3079.727 |
| V3 | 119.34 | -3054.5 | -3173.84 |
| 3-Jul | 9-Jul | Difference | |
| H1 | -387.82 | 2014.8 | 2402.62 |
| H2 | -15.363 | 2259.8 | 2275.163 |
| H3 | 291.12 | 2534.3 | 2243.18 |
| V1 | -80.917 | -3112.1 | -3031.183 |
| V2 | -38.773 | -3118.5 | -3079.727 |
| V3 | 119.34 | -3054.5 | -3173.84 |
The ISI was re-blanced this morning. Reasonable values were obtained along Z.
However, re-balancing the ISI did not correct the out-of-specification offset observed on horizontal CPSs.
CPS readouts, after re-balancing this morning, are presented below:
| H1 | 1901.6 |
| H2 | 2268.7 |
| H3 | 2417 |
| V1 | -34.45 |
| V2 | 47.896 |
| V3 | -201.18 |
In order to get a better understanding of what was happening, we collected data from GS13/L4C pressure sensors. Data shows:
Notes:
The ISI was locked. CPS readouts are within expected range.
| H1 | -348.96 |
| H2 | 297.36 |
| H3 | -156.01 |
| V1 | 252.29 |
| V2 | 155.3 |
| V3 | 323.62 |
The drifting we observed was not caused by a malfunctioning of the CPSs.
We later found that one circuit of our air conditioning had failed and therefore we could not maintain normal conditions in the staging building. There is no record of the indoor temperatures during this event but I estimate that the temperature excursions were on the order of 5-10 degrees F. Normal excursions (night-day) are probably 2-3F and perhaps closer to 1F during the day only (if you exclude the cooling overnight.
