Displaying reports 58081-58100 of 78003.Go to page Start 2901 2902 2903 2904 2905 2906 2907 2908 2909 End
Reports until 00:59, Wednesday 12 August 2015
H1 ISC
sheila.dwyer@LIGO.ORG - posted 00:59, Wednesday 12 August 2015 - last comment - 01:04, Wednesday 12 August 2015(20458)
ASC work tonight

Jenne, Sheila, Terra, Cheryl, Corey

Tonight we worked on some ASC (the wind was gusting to 30mph when we started this, the IFO locked just fine but the buildups were fluctating at low frequencies).  At first we wanted to check on CHARD.  We increased the gain for CHARD P by 6dB, and then were able to add a gentle boost (the same MSboost used in DHARD) to increase the gain at low frequencies.  The attched screenshot and template were measured at 3Watts, with the new configuration (which is in guardian) and the ITM oplevs on.  For an old measurement taken at 23 Watts see Evan's alog 19934

Jenne did a similar job for yaw, adding the same gentle boost, and including the 20dB in the guardian. Both the pitch and Yaw loops could have ugfs below 1 Hz as the power increases, but they should be stable.

Once we increased the power to 24 Watts, we found we weren't stable for more than 5 minutes.  This happened both before and after the CHARD changes.  We ran Hang's lockloss script which picked MICH ASC loops as a suspicous channel.  We locked at 15 Watts were we seemed to be indefintely stable, and measured both MICH loops.  They look fine, I'm just attaching them here so we have the templates. 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 01:04, Wednesday 12 August 2015 (20461)

For posterity, here is the CHARD Yaw measurement. 

Blue is before putting in the MsBoost, Red is afterward.  It's hard to see the effect of the boost in magnitude, since we didn't wait to finish the low frequency portion of the measurement, but the phase descrepancy between red and blue exactly matches the Foton filter, so we were satisfied.

Images attached to this comment
Non-image files attached to this comment
H1 CAL (CAL)
sudarshan.karki@LIGO.ORG - posted 00:43, Wednesday 12 August 2015 (20459)
LHO EndY Pcal Calibration

Travis, Sudarshan

We calibrated the EndY photon calibrator today. We have started reporting the final calibration factors in Newtons/Volt of PD  readout as per our new calibration scheme detailed in alog # 20334. The new calibration factors compared to the the last calibration is tabulated below and is also uploaded to T1500252.

Calibration Date

TxPD (N/V)

RxPD (N/V)

20150522

1.513E-09+/- 0.80%

1.064E-09+/- 0.80%

20150811

1.524E-09 +/- 0.57%

1.056E-09 +/- 0.57%

Weighted Mean

1.520E-09

1.059E-09

A detail comparison that includes physical parameters, intermediate ratios, optical efficiency  is attached.

Non-image files attached to this report
LHO General
corey.gray@LIGO.ORG - posted 00:08, Wednesday 12 August 2015 (20449)
Ops EVE Summary
H1 ISC
nutsinee.kijbunchoo@LIGO.ORG - posted 23:56, Tuesday 11 August 2015 (20456)
A Visualized Violin Mode Monitor

Locates at SITEMAP > SUS > VIOLINS. This monitor simply turns the log RMS output of the violin monitor into a bar chart. One bar chart monitors two frequencies due to the lack of filter bank space (only those that have known to cause trouble get its own narrow BP filter). Low value is 0 and high is 4. The green marks indicate the violin (RMS) amplitudes after 10 minutes of a lock stretch. Healty violin modes shouldn't go pass the green marks and some should get better as time passes. More fine-tuning can be done but it's good for now. I will put in the first harmonics once we know more about them.

Images attached to this report
H1 PEM
corey.gray@LIGO.ORG - posted 23:29, Tuesday 11 August 2015 - last comment - 01:45, Wednesday 12 August 2015(20455)
EY Dust Alarms Since Last Night

Roughly from last night (5:00UTC [10pmPT]), EY has been steadily increasing in dust levels (and obviously alarming constantly the whole time).  0.3um counts are over 10,000.  No other VEAs are seeing an increase in dust like this building.  I don't see a temperature increase.  Could a door be open?  HVAC issue?  Something burning? 

(Will send an email to Bubba, Jeff B, John)

Non-image files attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 01:45, Wednesday 12 August 2015 (20462)
H1 SYS (CAL, CDS, ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 20:57, Tuesday 11 August 2015 (20454)
IFO Maintenance Recovery Complete -- but IFO not brought to Low Noise
J. Kissel, for the locking recovery team (S. Dwyer, J. Driggers, B. Weaver, J. Warner, T. Shaffer, C. Gray, K. Kawabe)

During the heat of battle, today's maintenance day seem no less chaotic than the past month of horrific Teusdays. However, all being said, we were able to recover the IFO to DC READOUT by 23:30 UTC (4:30p PDT). The commissioning team has decided to stay in DC READOUT for further work on the ASC system for stability further up the guardian state ladder, so they consider the IFO recovered. (This does mean we have not yet confirmed that we can completely recovered the ~60-70 MPC IFO, but we have no evidence to suspect that today's maintenance activities have spoiled the *noise* of the instrument).

The biggest problems / time sucks and lessons learned from today:
(a) (30 minutes) (10:15 - 10:45) After the ASC model restart, we found the EPICS settings for unmonitored channels in SDF system had setting that meant the ASC was blasting the suspensions with non-sense. LHO aLOG 20442
(b) (30 minutes) (12:15 - 12:45) Communication issues between small side commissioning projects cause the IMC to go into high power with lock/unlock oscillations. (no aLOGs yet)
(c) (2 hours) (12:55 - 14:55) Discovering the the ASC output matrix had been reshuffled in the model but not on the MEDM screen, so we were feeding green WFS control to the wrong suspensions. LHO aLOG 20433.

Also it didn't cause a loss in recovery time, but they did cause greater confusion for the recovery team and expose that we still have a failure of communication:
(d) TMSX satellite amp repair was not planned, nor was the operator or relocking team informed that it was happening while it was happening LHO aLOG 20448.

Regarding (b) and (d), the intent is not to further shame or embarrass anyone (and apologies if it does, no offense is meant). The point is to remind you that the relocking team is here to help you. If you have a commissioning or repair task that needs doing, tell us ahead of time (the Monday prior, preferably, but at least a few hours in advance), so we can coordinate your task with all other tasks that we know will be going on. We've worked hard to make sure we know everything that is planned to better help those activities succeed. If you tell us ahead of time, we have a chance to think about the broader impact, and can hopefully avoid collisions, and reduce recovery time. Our experience and the interferometer has informed us that no matter how little impact you think your commissioning or repair task will have, it will have an impact on the IFO or someone else's little commissioning/repair task, so let's work together to minimize it!

We are getting better at this, thank you for everyone's hard work and help.
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 19:50, Tuesday 11 August 2015 - last comment - 20:39, Tuesday 11 August 2015(20452)
Updated ER7 reference values in CAL-CS for Pcal, DARM and ESD lines

JeffreyK, Darkhan

To test new GDS pipeline that estimates DARM parameters kappa_{tst}, kappa_{p/u}, kappa_C and f_c we've updated reference values that were calculated from ER7 model (see LHO alog #20291 for earlier values).

New values entered for ESD line at 35.9 Hz are

H1:CAL-CS_TDEP_ESD_LINE1_REF_C_REAL 1.2896e+06
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_IMAG -189585
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_REAL 1.30877e+06
H1:CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_IMAG -59171.7
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_REAL 8.8387e+09
H1:CAL-CS_TDEP_ESD_LINE1_REF_D_IMAG 1.12814e+10
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_TST_REAL -4.38814e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_TST_IMAG -3.39859e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_PUM_REAL -2.61782e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_PUM_IMAG 4.21051e-17
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_UIM_REAL -5.14962e-21
H1:CAL-CS_TDEP_ESD_LINE1_REF_A_UIM_IMAG -2.34929e-21
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_REAL -1.05327
H1:CAL-CS_TDEP_ESD_LINE1_REF_OLG_IMAG -0.791652

for PCALY line at 36.7 Hz:

H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_REAL 1.28869e+06
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_IMAG -193725
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_REAL 1.30872e+06
H1:CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_IMAG -60499.8
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_REAL 8.99945e+09
H1:CAL-CS_TDEP_PCALY_LINE1_REF_D_IMAG 1.15726e+10
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_TST_REAL -4.2798e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_TST_IMAG -3.22538e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_PUM_REAL -2.41611e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_PUM_IMAG 4.01322e-17
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_UIM_REAL -4.53934e-21
H1:CAL-CS_TDEP_PCALY_LINE1_REF_A_UIM_IMAG -1.9945e-21
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_REAL -1.03047
H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_IMAG -0.772912

for DARM line at 37.3 Hz:

H1:CAL-CS_TDEP_PCALY_LINE1_REF_OLG_IMAG -0.772912
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_IMAG -196826
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_NOCAVPOLE_REAL 1.30868e+06
H1:CAL-CS_TDEP_DARM_LINE1_REF_C_NOCAVPOLE_IMAG -61495.8
H1:CAL-CS_TDEP_DARM_LINE1_REF_D_REAL 9.12151e+09
H1:CAL-CS_TDEP_DARM_LINE1_REF_D_IMAG 1.17888e+10
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_REAL -4.19953e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_TST_IMAG -3.10345e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_PUM_REAL -2.2773e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_PUM_IMAG 3.87215e-17
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_UIM_REAL -4.13563e-21
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_UIM_IMAG -1.76881e-21
H1:CAL-CS_TDEP_DARM_LINE1_REF_OLG_REAL -1.01416
H1:CAL-CS_TDEP_DARM_LINE1_REF_OLG_IMAG -0.759088
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_REAL -1.12869e+16
H1:CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_IMAG -1.91871e+16

for PCALY line at 331.9 Hz:

H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_REAL 373718
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_IMAG -890155
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_REAL 1.20595e+06
H1:CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_IMAG -540755
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_REAL 7.75468e+10
H1:CAL-CS_TDEP_PCALY_LINE2_REF_D_IMAG -8.57657e+09
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_REAL -9.24752e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_IMAG -1.86072e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_PUM_REAL 1.11411e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_PUM_IMAG 1.83559e-19
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_UIM_REAL -2.19997e-26
H1:CAL-CS_TDEP_PCALY_LINE2_REF_A_UIM_IMAG -3.04968e-27
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_REAL -0.0175432
H1:CAL-CS_TDEP_PCALY_LINE2_REF_OLG_IMAG 0.0586971

kappa_tst correction factor (- 1 / A_0^tst(f_tst)) * (C_0(f_pcal) / (1 + G_0(f_pcal))) * (C_0(f_tst) / (1 + G_0(f_tst)))^{-1} is

H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_REAL 1.425e+16
H1:CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_IMAG -1.17617e+16

and A(f_ctrl) correction factor (C_0(f_pcal) / (1 + G_0(f_pcal))) * (C_0(f_ctrl) / (1 + G_0(f_ctrl)))^{-1} is

H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_REAL 1.425e+16
H1:CAL-CS_TDEP_REF_CLGRATIO_CTRL_IMAG -1.17617e+16

Most of these new values have been accepted in SDF_OVERVIEW table. Some of the values (that are very small) show difference in SDF even after "accept"+"confirm".

Notice that in the A_TST, A_PUM, A_UIM for ESD line (at frequency f_tst) include time delays due to IOP error checking (3 IOP cycles) + IOP computation (1 * IOP cycle) + zero order hold delay (0.5 * IOP cycle), but does not include 1 SUS computation cycle time delay (that was included into respective quantities for other cal lines). This means that when calculating kappa_{tst} in GDS pipeline (see eq. 9 in T1500377-v6), there is no need to account for time delay when using X_tst signal. Other values C, OLG and (G used for CLGRATIO calculations) include full time delays associated with sensing and actuation.

Images attached to this report
Comments related to this report
darkhan.tuyenbayev@LIGO.ORG - 20:39, Tuesday 11 August 2015 (20453)CAL

For details about what each of the channels represent see LHO alog comment #20361.

H1 INJ (INJ)
eric.thrane@LIGO.ORG - posted 18:32, Tuesday 11 August 2015 (20451)
EPICS down on h1hwinj1 (hwinj machine), restarted
Eric and Jim Batch

Eric wrote to Jim on Aug 10:

The ability to access EPICS channels appears to have disappeared at LHO when connected to h1hwinj:

[hinj@h1hwinj1 eric.thrane]$ ezcaread H1:CAL-INJ_TINJ_STATE
channel H1:CAL-INJ_TINJ_STATE not accessible

However, the same command works fine from cdsssh:

eric.thrane@cdsssh:~$ ezcaread H1:CAL-INJ_TINJ_STATE
H1:CAL-INJ_TINJ_STATE = 1

This problem appears to have occurred after ER7 since we would have seen errors during transient injections otherwise. Your assistance would be greatly appreciated.

Jim wrote back on Aug 11:

The problem has been resolved.  An update turned on some rather restrictive network filtering.
H1 SUS (CAL, SUS, SYS)
leonid.prokhorov@LIGO.ORG - posted 18:08, Tuesday 11 August 2015 (20450)
OPLEV charge measurements
Charge measurements was done on both ETMs.
It is the first measurements after changing the bias sign on ETMY (changed Aug, 10 (alog 20410), history and motivation in 20387).
Results are in attachment. Too early to discuss the new tendencies.
Images attached to this report
H1 SUS
vernon.sandberg@LIGO.ORG - posted 17:53, Tuesday 11 August 2015 - last comment - 10:13, Wednesday 12 August 2015(20448)
Replacement of Oscillating SUS-TMSX OSEM Satellite Box

V. Sandberg & R. McCarthy

The SUS-TMSX OSEM Satellite Box was driving a ~2kHz oscillation on its DC power line again. (See https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20428) This time we replaced the satellite box.  Verified that H1:SUS-TMSX_M1_OSEMINF_RT_IN1 and H1:SUS-TMSX_M1_OSEMINF_SD_IN1 were behaving themselves.  Work was done during the interval 18:00 - 18:45 UTC (11:00am - 11:45am PDT).

Apologie: I failed to follow my own rules and neglected to notify the operator on duty before we left and changed out the satellite box at End X.  Shame and humiliation duly noted.  :-(  Fortunately, no damage was done.

Comments related to this report
andrew.lundgren@LIGO.ORG - 02:01, Wednesday 12 August 2015 (20463)DetChar
After the replacement there was a DC readout lock (Aug 12 4 UTC). The TMSX QPDs look cleaner during this lock, although not quite perfect. The first plot is the spectrum of the TMSX QPD sum at three times - ER7 (blue), Aug 1 (red), and today (green). The second plot is the same for TMSY. It looks like there might still be some excess noise with the same shape but a much smaller amplitude. We'll check this again when there's a nominal lock.

Contrary to what I reported in my previous alog, it is possible to see the 1821 Hz noise in the OSEMs even though they are recorded at 256 Hz. The third plot shows the OSEM RT signal (and SD is the same) at four different times. Blue is the time when Matt and Evan alogged the problem. Red is the lock after the amplifier had been smacked and the audible oscillation was gone. Green is Aug 8 (a week later), and yellow is today. The noise is gone today after the amplifier was replaced.

The confusing thing is that the red trace is the same time as the plot in my alog. It seems that the high frequency noise in the amplifier was not there, but there was still just as much excess noise on the TMSX QPD. That might mean that the decrease in the excess noise today is just coincidental. We'll have to keep monitoring this.
Images attached to this comment
andrew.lundgren@LIGO.ORG - 07:11, Wednesday 12 August 2015 (20468)DetChar
There's a later DC lock today that seems to have a more nominal configuration. The noise in the TMSX QPD is like it was before the amplifier swap, so it hasn't been fixed and must be unrelated to the satellite amplifier problem. The previous lock, where the noise looked smaller, had a factor of ten lower DC level than the current value. The second plot is just a quick check showing that the high frequency line from the satellite amplifier is still gone since the swap.
Images attached to this comment
vernon.sandberg@LIGO.ORG - 10:13, Wednesday 12 August 2015 (20476)

The S number and S/N for the "old" satellite box for SUS-TMSX_M1_OSEM SD and  RT channels are:

S-number bar code  S1100176

S/N  3202-022

The identifiers for the new box will be obtained at a future oportunistic entry to the EX electronics racks area.

H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:25, Tuesday 11 August 2015 (20447)
offloading full lock ASC

We made a state a week or so ago that offloads the ASC in full lock to the alingment sliders.  This offloads the top mass of every optic that we control with ASC (except PR3) to the alignment sliders.  We are not offloading PR3 since it moves so much due to wire heating.  

We've tried this a few times and it works and we are able to relock afterwards, so I've added it to the main guardian path, ater the transition to DC readout.  

LHO VE
kyle.ryan@LIGO.ORG - posted 16:45, Tuesday 11 August 2015 (20444)
Replaced suspect leaking O-ring on Y-mid turbo
Kyle, Gerardo 

Today we replaced the decomposing vibration isolators, vented the y-mid turbo and removed the motor electrical feed through flange that had the 10-5 torr*L/sec leak -> The O-ring was dirty with lots of particulate but otherwise typical -> We cleaned the sealing surfaces of the mating flanges and installed a new O-ring that we had "slathered" with Krytox - > Pumped volume with QDP80 for 90 minutes followed by full spin up and spin-down of the turbo -> we then isolated the turbo volume from the foreline and observed the pressure rate of rise -> it appears that we reduced the leak but it is not clear if the pressure rise observed is due to a reduced air leak, wet surface out gassing or a combination of both -> the observed pressure after 24 hours will help answer this
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 16:44, Tuesday 11 August 2015 - last comment - 09:58, Wednesday 12 August 2015(20443)
CDS maintenance summary

h1susex re-install original computer WP5430

Dave, Carlos, Jim:

The original h1susex front end computer was re-installed at EX to fix the glitching seen with the newer faster computers. The script which was clearing the EX glitch errors has been stopped, any FEC errors will now latch on until cleared by the operator.

h1tcscs model change WP5422

Duncan, Nutsinee, Dave:

The new L1 TCS model was installed on h1tcscs. A new TCS_MASTER.mdl was used. The h1tcscs.mdl file was modified to: add the ez_ca_read parts to get TCS CO2 and Ring Heater channels from the Beckhoff computers (corner and end stations) into the model; add new inputs to the CO2 parts for RH input; add ODC output from the CO2 parts; add new ODC block; add SHMEM ODC sender (to be injested by h1odcmaster model).

I discovered that there is a naming mis-match in the Beckhoff Ring Heater channels in the corner station slow controls system. There is no mismatch in the end station Beckhoff systems. I modified h1tcscs use use the H1 names.

Conlog channel reconfiguration

Dave:

After the TCS, CAL and ASC model changes I rescanned the channel lists for Conlog. It still showed a disconnection for the Guardian LSC_CONFIG node, which I tracked down to a very out-of-date autoBurt.req file for h1guardian0 target. I updated the autoBurt.req file and reconfigured Conlog, it is now happy.

H1LSCAUX filter coeff load

Dave:

The h1lscaux model was reporting a modified filter file. I took a look and could not see any difference between the current file and the archived file. I pushed the coeff-load button to clear this.

DAQ Restart

Dave:

After the TCS, CAL and ASC model changes, the DAQ was restarted. There were no GDS frame broadcaster changes made today (ECR is pending).

Comments related to this report
david.barker@LIGO.ORG - 16:48, Tuesday 11 August 2015 (20445)

CDS overview is nice and green. The only red we expect are the TIM bits on the ETM Quad Suspension models now they are running on slower computers (a rate of about four per day is anticipated). We are investigating offloading the violin mode monitors from these models to resolve this.

Images attached to this comment
david.barker@LIGO.ORG - 17:25, Tuesday 11 August 2015 (20446)

I have updated the RCG Versions MEDM screen, all models are running RCG SVN version 4054 (2.9.6)

Images attached to this comment
corey.gray@LIGO.ORG - 23:56, Tuesday 11 August 2015 (20457)

Dave mentioned to me if you notice a red TIM error on the ETM models (i.e. H1SUSEY [EX]), click the button for the offending ETM (i.e. H1SUSETMX_GDS_TP.adl).  Here you will notice a red CPU Max value.  To clear this, hit the Diag Reset button on the upper right of the window (under the GPS time).

I did this for ETMx at around 6:50utc (23:50pt).

david.barker@LIGO.ORG - 09:58, Wednesday 12 August 2015 (20475)

model restarts logged for Tue 11/Aug/2015

2015_08_11 08:37 h1calcs
2015_08_11 08:57 h1iopsusex
2015_08_11 08:57 h1susetmx
2015_08_11 08:57 h1susetmxpi
2015_08_11 08:57 h1sustmsx
2015_08_11 09:00 h1alsex
2015_08_11 09:00 h1calex
2015_08_11 09:00 h1hpietmx
2015_08_11 09:00 h1iopiscex
2015_08_11 09:00 h1iopseiex
2015_08_11 09:00 h1iscex
2015_08_11 09:00 h1isietmx
2015_08_11 09:00 h1pemex
2015_08_11 10:15 h1asc
2015_08_11 12:03 h1tcscs

2015_08_11 12:54 h1broadcast0
2015_08_11 12:54 h1dc0
2015_08_11 12:54 h1fw0
2015_08_11 12:54 h1fw1
2015_08_11 12:54 h1nds0
2015_08_11 12:54 h1nds1

no unexpected restarts. CAL model change, SUS-EX computer swap-out, ASC model change, TCS-CS model change,  supporting DAQ restart.

H1 SYS
betsy.weaver@LIGO.ORG - posted 16:35, Tuesday 11 August 2015 (20442)
ASC inputs now turned off after bootfest

This morning, the ASC system was found to be blasting signals out after the model change because the inputs and output switches in the main loops were still ON even though all of the Guardians were set to DOWN for maintenance day.  So, I set the SDF to capture that the h1ascsafe.snap should restore the INPUT switches to OFF, then the Guardian will turn them on when appropriate later.  I watched the guardian turn them on during transition, just now, so all is good.

H1 ISC
keita.kawabe@LIGO.ORG - posted 13:56, Tuesday 11 August 2015 - last comment - 16:25, Tuesday 11 August 2015(20433)
New ASC model installed, SDF updated

New ASC model was installed.

SDF showed more than 6000 channels that are not available in the frame. These were either deleted in this model uptate (entire Initial Alignment System, some Alignment Dither System signals etc.) or obsolete channels from long time ago (e.g. all ASC-ALS signals that were moved to ALS model a long time ago).

Betsy made a new snapshot and we confired everything in SDF for new channels.

Note that the ASC MEDM screen is NOT updated. Functionality of the new model is exactly the same as before (new things introduced at LLO are terminated at the top level at LHO except new dither system).

Comments related to this report
keita.kawabe@LIGO.ORG - 16:12, Tuesday 11 August 2015 (20439)

Just after I wrote the above entry, I was looking at the old model file again and caught something that I didn't yesterday: The output matrix signal order was funny (OM1, OM2, TMSX, TMSY, then OM3).

I went back to the new model, and unfortunately it turned out that the new model from LLO "fixed" the funny order by reshuffling TMSX, TMSY and OM3 signals in the matrix. What used to be the matrix elements for TMSX, TMSY, OM3 are now for OM3, TMSX, TMSY, i.e. the TMSX signal is now sent to OM3, and TMSY signal to TMSX.

Since the guardian is not touching this output matrix, we decided to just manually change the output matrix (not the model, but the epics values for corresponding matrix elements). After this change, new output matrix MEDM screen was pulled from svn and everything was fine.

New ASC master medm was also pulled from svn and it looks OK.

I updated the input matrix MEDM, but everything was white on that one so I put the old one back.

betsy.weaver@LIGO.ORG - 16:25, Tuesday 11 August 2015 (20441)

And, SDF has been updated to capture the new matrix elements in the ascsafe.snap

H1 ISC
evan.hall@LIGO.ORG - posted 03:05, Sunday 26 July 2015 - last comment - 00:48, Wednesday 12 August 2015(19935)
Some things not in the guardian
Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 00:48, Wednesday 12 August 2015 (20460)

I think that evan meant to say he increased the gain for CHARD by 20 dB by engaging FM1

Displaying reports 58081-58100 of 78003.Go to page Start 2901 2902 2903 2904 2905 2906 2907 2908 2909 End