I ran a script to let PSL roration stage go back and forth 100 times between 0 and 3 Watts. The result of measured power vs. requested power is ~2% uncertainty. The ISS first loop wasn't locked at the time of the measurement. Repeating the test by letting the rotation stage go between 0, mid power (~30 W), and max power (~56W) yielded similiar result. We could expect even a better performance when ISS is locked.
Repeated the same test for CO2X and CO2Y rotation stages. Later realized that the laser weren't locked due to today's Guardian computer restart. CO2X RS yielded .3% uncertainty and CO2Y RS yielded 3% uncertainty. I'm not sure if our powermeters are a thermopiles. I would disregard this number if they are.
In trying to figure out what's happening with the power stabilisation, I looked at the "dark" noise of the power stabilisation photodiodes. pda-dark1.png shows the measured "dark" noise for both the AC and DC output of the photodiode. Both are the same. I suspect that both photodiodes are damaged. The ISS will lock but is very temperamental and depends on the set point (reference level). When running the diffraction level should be between 12-14%. There is a problem with the reported DC output and that measured at the photodiode. Often they do not agree. For example the MEDM screen will report that the DC output is ~11V but measured at the photodiode it is ~7V. Whilst the reason might be related to how the DC value is calculated from the AC value of the photodiode, it still is not consistent with the measured value.
When so-called analog "AC" signal (which is in reality a whitened signal with DC gain of 0.2) hits the rail, digital DC on the MEDM wouldn't agree with analog DC (first attachment).
Out of curiousity, I turned on the 1st loop and increased the diffraction to 16% by moving the REFSIGNAL from -2.3V to -1.9V, and ISS has been running OK in the past 40 minutes. Digital DC is a factor 5 larger than the REFsignal, this makes sense because the DC of the whitened analog signal that is actually used for the ISS is a factor of 5 smaller than the analog DC.
1st loop PDs as well as downstream of ISS 1st loop (FSS transmission) look about the same or maybe somewhat worse than before (e.g. 26758).
Morning Meeting
- It's Friday. Don't do anything goofy.
- More PSL tweaking today.
- Avoid end station (SEI)
- Shutdown HAM6 pump today (VAC)
- IM measurement continue
- RS measurement continue
#################################3
Activities. All time in UTC:
15:11 Carlos/Jeff B. going to PSL (conputer boot)
15:41 Jeff B. out, Carlos still in with Peter.
16:04 Jason joining Peter in the PSL
16:11 Kyle to HAM4-5
16:26 Carlos out
16:30 Kristaina and Karen to LVEA.
16:50 Joe to LVEA retrieve some equipment
17:01 Fil to CER to fire up UPS.
17:03 Joe out.
17:40 Kyle to EY. NOT into the VEA. He'll be turning on the light and look for quipment.
18:04 Kyle out
18:43 Jason and Peter out for lunch.
19:10 Kyle putting a fan near RCG (HAM4-5)
19:16 Kyle out
20:13 Jeff K. to LVEA
20:22 Jeff K and Evan G going to EY near chamber. I ramped off BRS. Jeff will also be turning off high voltage supple. Make sure he turn it back on.
20:27 Kyle to vertex RGA to plug "stuff" in.
20:50 Jeff B. to rack near PSL.
21:01 Peter done for the day
21:57 Bryn and David to LVEA to take some pictures.
21:58 Evan to ISCT1 working on POPX.
22:18 Bryn out
22:30 Kyle to MidY to do CP3 overflow and get rid of CP2 alarm.
22:35 Jeff B to cleaning area
22:39 Jeff B. out
22:53 Kyle back from Mid Y. Now going to vertex RGC.
23:01 Jeff K back from end station, putting tuff in the LVEA
Jeff K, Evan G
We (finally!) measured the ESD driver quadrant control voltage path transfer functions, which was needed because of the change made on Feb 9 (see ECR E1500341 and LHO aLOG 25468) for calibration/compensation use. Measurements are stored under
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Measurements/Electronics/2016-05-06
Measurement notes attached. Analysis to come...
The anaylsis is done.
I wrote a matlab analysis script which automatically fits all the measured transfer function by calling LISO. The script can be found in SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/model_ETMY_LVLN_driver_20160511.m
The results are attached and also can be found in SVN at
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Results/Electronics/2016-05-11_H1SUSETMY_ESD_LVLNDriver_*.pdf
An update:
Evan and Jeff pointed me out that I could have also subtracted the reference transfer function ( = the transfer function of the measurement setup, including SR785 and diff-to-single-ended-convertor). So I edited the code so that it subtracts the reference out of each measurement. This impacted mostly on the gain of each measruement which are now 1.88. The resulting pdfs are attached.
I have moved the analysis code to a slighlty place at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER9/H1/Scripts/Electronics/model_ETMY_LVLN_driver_20160511.m
The resulting pdfs are saved at the same location as the original ones.
CP4 was sending out a yellow alarm on CP4 so I looked more closely and noticed one of the temp sensors (from heat tape) is reading bogus value. Attached is trend. It started yesterday in the morning.
However, this bogus temp reading did not cause the alarm. The liquid level of CP4 was spiking (seen only in *seconds* trend scan) due to back pressure from flow meter. See Kyle's log entry above for more detail.
Re-initalized HWSX matlab files.
Included is the RPN image from the injection locked HPO for comparison. The 10Hz comb feature that was present in the Freq scan from Apr 29th is gone. The pointing seems to be slightly out of spec and I believe tha modescan looks relatively ok.
PSL might need another tweak after HPO work is done. I noticed maximum power changed day-to-day basis.
model restarts logged for Thu 05/May/2016 ISC and SUS-PI model work, h1tw0 rebuild, some unexpected fw restarts
2016_05_05 11:48 h1iscex
2016_05_05 11:50 h1iscey
2016_05_05 12:00 h1omc
2016_05_05 12:00 h1omcpi
2016_05_05 12:02 h1pemex
2016_05_05 12:02 h1susetmxpi
2016_05_05 12:06 h1broadcast0
2016_05_05 12:06 h1dc0
2016_05_05 12:06 h1fw0
2016_05_05 12:06 h1fw1
2016_05_05 12:06 h1nds0
2016_05_05 12:06 h1nds1
2016_05_05 12:06 h1tw1
2016_05_05 12:56 h1pemex
2016_05_05 12:57 h1broadcast0
2016_05_05 12:57 h1dc0
2016_05_05 12:57 h1fw0
2016_05_05 12:57 h1fw1
2016_05_05 12:57 h1nds0
2016_05_05 12:57 h1nds1
2016_05_05 12:57 h1tw1
2016_05_05 14:52 h1broadcast0
2016_05_05 14:52 h1dc0
2016_05_05 14:52 h1fw0
2016_05_05 14:52 h1fw1
2016_05_05 14:52 h1nds0
2016_05_05 14:52 h1nds1
2016_05_05 14:52 h1susetmxpi
2016_05_05 14:52 h1tw1
2016_05_05 15:06 h1fw0
2016_05_05 15:13 h1fw0
2016_05_05 15:23 h1fw0
2016_05_05 16:35 h1tw0
2016_05_05 17:06 h1tw0
model restarts logged for Wed 04/May/2016 No restarts reported
model restarts logged for Tue 03/May/2016 ALL SYSTEMS RESTARTED. RCG upgrade to 3.0.2. Front end and DAQ upgrade.
model restarts logged for Mon 02/May/2016 No restarts reported
model restarts logged for Sun 01/May/2016 No restarts reported
model restarts logged for Sat 30/Apr/2016 fw1 instability
2016_04_30 04:33 h1fw1
2016_04_30 06:24 h1fw1
2016_04_30 09:03 h1fw1
2016_04_30 11:26 h1fw1
2016_04_30 19:14 h1fw1
2016_04_30 19:44 h1fw1
2016_04_30 21:03 h1fw1
2016_04_30 21:53 h1fw1
model restarts logged for Fri 29/Apr/2016 No restarted reported
model restarts logged for Thu 28/Apr/2016 hw1 and nds1 instability
2016_04_28 00:34 h1fw1
2016_04_28 04:34 h1fw1
2016_04_28 04:54 h1fw1
2016_04_28 05:12 h1fw1
2016_04_28 06:05 h1fw1
2016_04_28 07:13 h1fw1
2016_04_28 07:43 h1fw1
2016_04_28 07:56 h1fw1
2016_04_28 08:02 h1fw1
2016_04_28 08:34 h1fw1
2016_04_28 08:54 h1fw1
2016_04_28 16:28 h1nds1
2016_04_28 16:29 h1nds1
2016_04_28 16:30 h1nds1
model restarts logged for Wed 27/Apr/2016 fw0+1 unstable. OMC and SUS PI IPC model work
2016_04_27 08:33 h1fw1
2016_04_27 09:53 h1fw1
2016_04_27 11:13 h1fw1
2016_04_27 11:30 h1fw1
2016_04_27 11:59 h1omcpi
2016_04_27 12:01 h1dc0
2016_04_27 12:01 h1susitmpi
2016_04_27 12:03 h1broadcast0
2016_04_27 12:03 h1fw0
2016_04_27 12:03 h1fw1
2016_04_27 12:03 h1nds0
2016_04_27 12:03 h1nds1
2016_04_27 12:03 h1tw1
2016_04_27 13:06 h1fw0
2016_04_27 14:33 h1fw0
2016_04_27 17:54 h1fw1
2016_04_27 20:33 h1fw1
I just pushed a minor upgrade to guardian to fix a small issue with the guardlog client when following node logs. The new version is r1542.
The client was overly buffering stream data from the server, which was causing data from the stream to not be output in a timely manner. This issue should be fixed in the version I just pushed.
As always make sure you have a fresh session to get the new version:
jameson.rollins@operator1:~ 0$ which guardlog /ligo/apps/linux-x86_64/guardian-1542/bin/guardlog jameson.rollins@operator1:~ 0$
Sorry, Sheila. This issue has been fixed now. Just needed to tweak the lockloss script to account for some updated guardlog arguments.
Yes, its working, thank you Jamie.
Jim rebooted h1guardian0 at 10:53 local. I was hoping this would help with the logging issues that we have had here alog26965. But no luck.
Notes to my future self - Soaked @ 120C - 150C for 60 hours. Static power to maintain zones at temperature = 405 watts Zone specifics Turbo + 1.5" valve -> VAR = 38%, 0.18 amp and 200 ohm 1.5" valve to reducing Tee -> VAR = 44%, 0.48 amp and 136 ohm 2.5" to 1.5" reducer -> VAR = 44%, 0.9 amp and 70 ohm 2.5" to 1.5" reducing Tee -> VAR = 44%, 1.27 amp and 48 ohm Two 1.5" Tee assembly -> VAR = 38%, 0.39 amp and 140 ohm RGA #1 -> VAR = 44%, 0.88 amp and 70.5 ohm RGA #2 + elbow -> VAR = 44%, 0.9 amp and 70 ohm 2.5" valve -> VAR = 44%, 0.92 amp and 70 ohm N2 leak valve -> VAR = 38%, 0.40 amp and 141 ohm Kr leak valve -> VAR = 38 %, 0.40 amp and 137 ohm
Here "VAR" used as abbreviation for VARIAC and not "VOLT-AMP REACTANCE"
The plots reflect ongoing work being performed in terms of power recycling and environmental incursions.
Tega, Ross, Jim, Dave:
Late entry for Thursday work. The unused RFM channels H1:ASC-[x,y]_TR_A_SUM_RFM were removed from h1isce[x,y]. This closes WP 5868.
h1omcpi model was changed to export the 4 demodulated pairs of I,Q signals to shared memory RFM on h1lsc0. h1omc mode was modified to mux these 8 channels into one, and send it out on both X-Arm and Y-Arm RFM networks. h1pemex model was changed to receive the X-Arm RFM channel and demux it to 8 signals, then send these out over the EX Dolphin fabric. h1susetmxpi model was changed to receive and process these 8 signals.
Due to top-naming issues with pemex and susetmxpi, several rounds of model-the-DAQ restarts were needed.
We tested the mux-demux by applying large offsets to each channel one at a time and seeing the corresponding channel change at the end station. Note that the DEMUX OFFSET input for the 8-chan C code is set to 7.
Filiberto fixed the working 36/45MHz WFS, S/N 1300511. He extracted pins from the 5-coax connector, rotated the connector shell by 180 degrees, and inserted the pins again such that the connector looks like the mirror image of its old self. Since it's the mirror of the mirror, now it's correct.
I rerouted the cables inside the ISCT1 so the connections from outside of the table are still intact.
Connected the diff-single converter out 3 and 4 to the MCL PZT driver.
ISC R1, position 2, channel (3, 4) = H1:ISC-(434, 435) cable = MCL controller (X, Y) channel on ISCT1.
DAC works.
+175 ml (accdentally). Should have been < 150 ml. Jeff B. filled 200 ml three days ago.
After Tuesday activities, noticed a step change in pirani gauge signals. Attached is plot of PT100 (on HAM 1) and PT140 (on BSC4). Note: PT100 CC gauge keeps turning on and off due to pirani set point and stepping. PT120 also shows a step in signal. Yesterday Richard & Gerardo pulled the leads on PT120 while measuring the voltage. Voltage read higher valve when lifted from rack. PT140 pirani trend over 15 days shows a major step from 4/26 (when Beckhoff was installed) to 5/3 when power was switched and system rebooted.
Sounds like the input impedance of the Beckhof ADC is lower than the original VME card ADC. These form a voltage divider with the gage head's output impedance. I/O impedances should be listed in the respective instrument datasheets. There may be a jumper/selection available.
Beyond recalibrating epics records, good to confirm that the gage heads are happy driving whatever impedance they see full-scale.
Good idea Chandra. I hadn't even considered looking at the piranis!
WP5857 Keith, Rolf, Jim, Dave:
Tuesday 3rd May we upgraded the CDS front end systems and the DAQ to RCG3.0.2
The order of build-install was:
During the make installWorld h1fs0 developed a major NFS problem and stopped serving /opt/rtcds file system. We reboot h1fs0, but the NFS service did not start correctly and clients could not umount nor mount the file sytem. We restart kernel-nfs-server daemon and the NFS clients remounted correctly.
I need to change the SUS ITMY and ETMY now the HWWD part is synced to the hardware regarding signal levels (I removed temporary NOT inverters on binary signals).
16:00 h1iscex developed the connTrack Table Full error, new network connections were not permitted. We have to reboot this computer and disrupt the EX Dolphin fabric, requiring all EX models to be restarted (except susaux).
Vacuum controls Beckhoff gauges on BSC7,8 were moved from their temporary slow controls Beckhoff connect to the LX vacuum controls system. This required a name change (H1->H0), minute trends were changed on DAQ.
Upgrade built ISI-HAMS with latest isihammaster.mdl file, but team SEI needed to back out this latest change, so common file was reverse-merged to previous version and all isi-ham rebuilt and restarted.
CAL system was modified to remove the Blind Injection data path (h1calcs and h1calex).
Big DAQ restart at end of afternoon: new VE EDCU list, new Slow Controls EDCU LIST, new Dust monitor EDCU list, new susitmy/etmy hwwd code, new isi-ham models, new cal models
As of now CDS overview shows some IPC errors all related to h1iscex in H1HPIETMX (H1:LSC-X_TIDAL_HEPIETMX-IPC), H1ASC (a bunch of ALS ASC signals) and H1OAF (H1:SEI-EX_2_OAF_MUX_RFM).
Seems like the errors started at about 18:59 or so, went away after 3 minutes, then came back at about 19:53 or so and never went away, all UTC.
Hmm, now they're gone.