Hugh, Patrick, Dave:
We built and restarted h1isiham6 model, followed by a DAQ restart to add some slow channels from h1isiham6, and install the new H0EDCU_FMCS.ini
WP 7026 Finished restart. There are white boxes on the medm screens for the channels that were removed. I will update the medm screens at a later time. A DAQ restart is still required.
H0EDCU_FMCS changes due to today's code change. 62 channels added, 28 channels removed, net addition of 34 channels.
Channels Added:
+[H0:FMC-CS_CY_H2O_PUMPCALC]
+[H0:FMC-CS_LVEA_AH_COOLVALVE_1_PC]
+[H0:FMC-CS_LVEA_AH_COOLVALVE_2_PC]
+[H0:FMC-CS_LVEA_AH_COOLVALVE_3_PC]
+[H0:FMC-CS_LVEA_AH_COOLVALVE_4_PC]
+[H0:FMC-CS_LVEA_AH_DAMPER_1_PC]
+[H0:FMC-CS_LVEA_AH_DAMPER_2_PC]
+[H0:FMC-CS_LVEA_AH_PITCH_VANE_1_PC]
+[H0:FMC-CS_LVEA_AH_PITCH_VANE_2_PC]
+[H0:FMC-CS_LVEA_AH_PITCH_VANE_3_PC]
+[H0:FMC-CS_LVEA_AH_PITCH_VANE_4_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE1A_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE1B_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE2A_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE2B_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE3A_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE3B_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE4_PC]
+[H0:FMC-CS_LVEA_HEATER_ZONE5_PC]
+[H0:FMC-CS_OSB_AH_COOLVALVE_5_PC]
+[H0:FMC-CS_OSB_AH_COOLVALVE_6_PC]
+[H0:FMC-CS_OSB_AH_HEATINGCOIL_10_PC]
+[H0:FMC-CS_OSB_AH_HEATINGCOIL_9_PC]
+[H0:FMC-CS_OSB_CR_DV6_DEGC]
+[H0:FMC-CS_OSB_CR_DV7_DEGC]
+[H0:FMC-CS_OSB_CR_DV8_DEGC]
+[H0:FMC-CS_OSB_CUR_DV9_DEGC]
+[H0:FMC-CS_OSB_GC_DV10_DEGC]
+[H0:FMC-CS_OSB_MSR_DV5_DEGC]
+[H0:FMC-EX_AH_COOLVALVE_1_PC]
+[H0:FMC-EX_AH_COOLVALVE_2_PC]
+[H0:FMC-EX_AH_DAMPER_1_PC]
+[H0:FMC-EX_AH_DAMPER_2_PC]
+[H0:FMC-EX_AH_HEATER_PC]
+[H0:FMC-EX_AH_PITCH_VANE_1_PC]
+[H0:FMC-EX_AH_PITCH_VANE_2_PC]
+[H0:FMC-EX_CY_H2O_PUMPCALC]
+[H0:FMC-EY_AH_COOLVALVE_1_PC]
+[H0:FMC-EY_AH_COOLVALVE_2_PC]
+[H0:FMC-EY_AH_DAMPER_1_PC]
+[H0:FMC-EY_AH_DAMPER_2_PC]
+[H0:FMC-EY_AH_HEATER_PC]
+[H0:FMC-EY_AH_PITCH_VANE_1_PC]
+[H0:FMC-EY_AH_PITCH_VANE_2_PC]
+[H0:FMC-EY_CY_H2O_PUMPCALC]
+[H0:FMC-MILLIAMP_MAXVAL]
+[H0:FMC-MX_AH_COOLVALVE_1_PC]
+[H0:FMC-MX_AH_COOLVALVE_2_PC]
+[H0:FMC-MX_AH_DAMPER_1_PC]
+[H0:FMC-MX_AH_DAMPER_2_PC]
+[H0:FMC-MX_AH_HEATER_PC]
+[H0:FMC-MX_AH_PITCH_VANE_1_PC]
+[H0:FMC-MX_AH_PITCH_VANE_2_PC]
+[H0:FMC-MX_CY_H2O_PUMPCALC]
+[H0:FMC-MY_AH_COOLVALVE_1_PC]
+[H0:FMC-MY_AH_COOLVALVE_2_PC]
+[H0:FMC-MY_AH_DAMPER_1_PC]
+[H0:FMC-MY_AH_DAMPER_2_PC]
+[H0:FMC-MY_AH_HEATER_PC]
+[H0:FMC-MY_AH_PITCH_VANE_1_PC]
+[H0:FMC-MY_AH_PITCH_VANE_2_PC]
+[H0:FMC-MY_CY_H2O_PUMPCALC]
Channels removed:
-[H0:FMC-EX_AH_COOLVALVE_1]
-[H0:FMC-EX_AH_COOLVALVE_2]
-[H0:FMC-EX_AH_DAMPER_1]
-[H0:FMC-EX_AH_DAMPER_2]
-[H0:FMC-EX_AH_HEATER]
-[H0:FMC-EX_AH_PITCH_VANE_1]
-[H0:FMC-EX_AH_PITCH_VANE_2]
-[H0:FMC-EY_AH_COOLVALVE_1]
-[H0:FMC-EY_AH_COOLVALVE_2]
-[H0:FMC-EY_AH_DAMPER_1]
-[H0:FMC-EY_AH_DAMPER_2]
-[H0:FMC-EY_AH_HEATER]
-[H0:FMC-EY_AH_PITCH_VANE_1]
-[H0:FMC-EY_AH_PITCH_VANE_2]
-[H0:FMC-MX_AH_COOLVALVE_1]
-[H0:FMC-MX_AH_COOLVALVE_2]
-[H0:FMC-MX_AH_DAMPER_1]
-[H0:FMC-MX_AH_DAMPER_2]
-[H0:FMC-MX_AH_HEATER]
-[H0:FMC-MX_AH_PITCH_VANE_1]
-[H0:FMC-MX_AH_PITCH_VANE_2]
-[H0:FMC-MY_AH_COOLVALVE_1]
-[H0:FMC-MY_AH_COOLVALVE_2]
-[H0:FMC-MY_AH_DAMPER_1]
-[H0:FMC-MY_AH_DAMPER_2]
-[H0:FMC-MY_AH_HEATER]
-[H0:FMC-MY_AH_PITCH_VANE_1]
-[H0:FMC-MY_AH_PITCH_VANE_2]
I was not expecting the addition of any channels. No harm done I guess though.
TITLE: 06/13 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
Wind: 22mph Gusts, 17mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY: Currently locked for ~1 hour, but have transitioned Observatory Mode to Preventative Maintenance in prep for Tuesday maintenance activities.
TITLE: 06/13 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC STATE of H1: Observing at 32Mpc INCOMING OPERATOR: Travis SHIFT SUMMARY: Appearance of noise around 38 and 80 Hz (alog 36819). Three lock losses, the first coincident with the arrival of an earthquake. Verbal alarms is crashing upon hitting the observing intent bit. NOISE_TUNINGS is being announced twice by verbal alarms along with an error message (see previous alogs). H1:ALS-X_REFL_SERVO_COMBOOST is alternating between 1 and 2 (see SDF differences in previous alogs). LOG: 07:14 UTC Restarted nuc5 and video0 09:01 UTC Lock loss 09:18 UTC Lock loss from CARM_ON_TR 09:21 UTC Changed observatory mode to earthquake ~10:00 UTC Observing 09:46 UTC Lock loss 10:48 UTC Starting initial alignment 11:22 UTC Initial alignment done ~11:52 UTC Observing 13:01 UTC Peter walking to mid Y 13:34 UTC Peter back 13:43 UTC Lock loss 14:08 UTC Ken to warehouse 15:00 UTC Bubba and Apollo to CER 15:04 UTC Set ISI config to SC_OFF_NOBRSXY 15:05 UTC Pep to end X 15:06 UTC Pest control on site
Set state to commissioning at 15:00 UTC. Set observatory mode to preventative maintenance. Turned off BRS.
Back to observing at 14:20 UTC. Screenshot of accepted SDF differences attached. It appears that H1:ALS-X_REFL_SERVO_COMBOOST keeps alternating between 1 and 2. Again: NOISE_TUNINGS was announced twice by verbal alarms, along with: 'TypeError while running test: LOCK_STATE'. Verbal alarms crashed upon hitting the observing intent bit.
Lock loss at 13:43 UTC. No obvious issues prior.
NOISE_TUNINGS was announced twice by verbal alarms, along with: 'TypeError while running test: LOCK_STATE'. This occurred the last time as well. Accepted the attached SDF differences. Why are these coming up each time? Verbal alarms crashed again upon hitting the observing intent bit. Hopefully the initial alignment will help this lock.
Lock loss at 9:46 UTC. Ran initial alignment. Relocking.
Accepted the attached SDF differences. Verbal alarms crashed upon hitting the observing intent bit. Previously seen DARM noise is gone.
Lock loss at 09:00 UTC. Possibly from the mechanism causing the DARM noise?
May have actually been from an earthquake. I do not believe seismon saw it. A tconvert on the GPS time gives: patrick.thomas@zotws3:~$ tconvert 1181363865 Jun 13 2017 04:37:27 UTC patrick.thomas@zotws3:~$
I believe this is the one seismon is reporting, which was much earlier.
Range is dropping with it. See attached.
I have seen this before: alog 35173. If I recall, Jeff K. knew what it was, but I don't remember what he said.
Found it: alog 35184
What is rung up at 6kHz? That might be the problem.
Good question. Somehow I hadn't noticed that. It is not there in the screenshot in the first alog I linked to (from when this happened before).
Well, maybe it is, but at a much reduced amplitude.
TITLE: 06/13 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 58Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 9mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
QUICK SUMMARY:
Restarted nuc5 and video2.
TITLE: 06/13 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 57Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 15hour lock, range has been a bit lower than the last lock (59Mpc) but the wind has calmed down and the rest of the environment is calm.
Locked and Observing for 12hrs. The range drop that we saw previously definitely seems to correlate with the wind, which is odd since the wind was only peaked at 35mph for a few tens of minutes and then slowly decreased again.
There does still seem to be some more noise than usual in the 30-1000hz and our range is still only at 60Mpc, about 5Mpc worse than the last lock.
Some trends maybe showing that low wind is affecting our range.
Hugh made a minor change to h1isiham6.mdl to generated a payload MEDM adl file. A new h1isiham6.ko was generated and the model was restarted for completeness.