Displaying reports 54661-54680 of 83146.Go to page Start 2730 2731 2732 2733 2734 2735 2736 2737 2738 End
Reports until 12:23, Wednesday 24 August 2016
H1 CDS
david.barker@LIGO.ORG - posted 12:23, Wednesday 24 August 2016 - last comment - 13:23, Wednesday 24 August 2016(29280)
models using the cdsEzca read and write parts

Daniel and Vern asked for a list of H1 models which are using the cdsEzcaRead and cdsEzcaWrite parts to transfer data to remote IOCs. This is following my discovery that the h1psliss model is attempting to send data to LLO EPICS channels (which also do not exist at LLO, presumably obsolete channels).

To make the list, I created a list of front end model core mdl files and grep within each file (grep -B 2 cdsEzCaWrite */h1/models/${model}|grep ":")

cdsEzCaRead:

h1ioppemmx.mdl *

      Name       "H1:DAQ-DC0_GPS"

h1ioppemmy.mdl *

      Name       "H1:DAQ-DC0_GPS"

h1sushtts.mdl 

      Name       "H1:LSC-REFL_A_LF_OUTPUT"

h1pslpmc.mdl

 

      Name       "H1:PSL-OSC_LOCKED"

h1tcscs.mdl

      Name       "H1:ASC-X_TR_B_SUM_OUTPUT"

      Name       "H1:ASC-Y_TR_B_SUM_OUTPUT"

      Name       "H1:TCS-ETMX_RH_LOWERPOWER"

      Name       "H1:TCS-ETMX_RH_UPPERPOWER"

      Name       "H1:TCS-ETMY_RH_LOWERPOWER"

      Name       "H1:TCS-ETMY_RH_UPPERPOWER"

      Name       "H1:TCS-ITMX_CO2_LASERPOWER_ANGLE_CALC"

      Name       "H1:TCS-ITMX_CO2_LASERPOWER_ANGLE_REQUEST"

      Name       "H1:TCS-ITMX_CO2_LASERPOWER_POWER_REQUEST"

      Name       "H1:TCS-ITMX_CO2_LSRPWR_MTR_OUTPUT"

      Name       "H1:TCS-ITMX_RH_LOWERPOWER"

      Name       "H1:TCS-ITMX_RH_UPPERPOWER"

      Name       "H1:TCS-ITMY_CO2_LASERPOWER_ANGLE_CALC"

      Name       "H1:TCS-ITMY_CO2_LASERPOWER_ANGLE_REQUEST"

      Name       "H1:TCS-ITMY_CO2_LASERPOWER_POWER_REQUEST"

      Name       "H1:TCS-ITMY_CO2_LSRPWR_MTR_OUTPUT"

      Name       "H1:TCS-ITMY_RH_LOWERPOWER"

      Name       "H1:TCS-ITMY_RH_UPPERPOWER"

h1odcmaster.mdl

      Name       "H1:GRD-IFO_OK"

      Name       "H1:GRD-IMC_LOCK_OK"

      Name       "H1:GRD-ISC_LOCK_OK"

      Name       "H1:GRD-OMC_LOCK_OK"

 

      Name       "H1:PSL-ODC_CHANNEL_LATCH"

* mid station pem systems do not have IRIG-B timing, cdsEzCaRead is used to remotely obtain starting GPS time.

EzCaWrite:

h1psliss.mdl *

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_1_GAINSTEP"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_1_SET_1"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_1_SET_2"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_1_SET_3"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_2_GAINSTEP"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_2_SET_1"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_2_SET_2"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_2_SET_3"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_3_GAINSTEP"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_3_SET_1"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_3_SET_2"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_3_SET_3"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_4_GAINSTEP"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_4_SET_1"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_4_SET_2"

  Name   "L1:IMC-SL_QPD_WHITEN_SEG_4_SET_3"

h1pslpmc.mdl

      Name       "H1:PSL-EPICSALARM"

* all writes to L1 channels will be removed on next restart of PSL ISS model.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:05, Wednesday 24 August 2016 (29281)AOS, DetChar, GRD, IOO, ISC, PSL, SUS
Tagging all subsystems that are nominal responsible for these models.
david.barker@LIGO.ORG - 13:23, Wednesday 24 August 2016 (29282)

Interestingly h1tcscs is cdsEzCaRead'ing some of its own EPICS channels. Looks like a copy-paste issue, I'll work with Nutsinee when she gets back.

LHO General
thomas.shaffer@LIGO.ORG - posted 11:05, Wednesday 24 August 2016 (29273)
Morning Meeting Minutes

See yesterday's alogs for a review of yesterday's activities. Please close all FRSs.

SEI - All good. ITMX did not trip from the two big EQs last night.

SUS - Charge is growing, needs a sign flip soon.

CDS - Next tues pulling demod board and putting the common mode board back in.

PSL - After recovering from a trip yesterday, things look good.

Vac - Hoping for more experiments on CP4, it will cause alarms. Kyle still baking vertex RGA, noise will continue for the week.

Facilities - [[Edit]] Safety meeting today.

H1 CDS
david.barker@LIGO.ORG - posted 10:36, Wednesday 24 August 2016 - last comment - 16:39, Wednesday 24 August 2016(29278)
summary of software watchdog timing

I was asked to summarize the SWWD (software watchdog) timing sequence as a reminder.

 

t=0: SUS IOP detects top OSEM RMS exceeds trip level, starts its 1st countdown (5 mins)

t=5mins: SUS IOP 1st countdown expired, its IPC output goes to BAD and it starts its 2nd countdown (15 mins). SEI IOP receives the BAD IPC, and starts its 1st countdown (4 mins)

t=9mins: SEI IOP 1st countdown expired, its IPC output goes to BAD and it starts its 60 second 2nd countdown. SEI user models get the 60 second warning IPC so they can cleanly shutdown before the DACs are killed

t=10mins: SEI IOP 2nd countdown expired, DAC cards associated with the chamber the SUS is located in are killed

t=20mins: SUS IOP 2nd countdown expired, SUS DAC cards are killed

 

For the hardware watchdog (HWWD) the times are doubled. The power to the ISI Coil Driver chassis is removed after 20 mins of continuous SUS shaking.

Comments related to this report
jeffrey.kissel@LIGO.ORG - 16:39, Wednesday 24 August 2016 (29289)SEI, SUS
Tagging SEI and SUS.
H1 General
vernon.sandberg@LIGO.ORG - posted 07:46, Wednesday 24 August 2016 (29271)
Work Permit Summary for 2016 August 23

Work Permit Date Description   alog
6119.html 2016-08-23 22:37 Activity: GC core router will be removed and replaced. Wireless and Internet connectivity will be disrupted during the short outage. CDS and LDAS internal networks will be unaffected, along with the phone system. * New equipment will be racked ahead of time (non-disruptive) * New cabling will be run ahead of time as needed * Cisco 6504 will be left on (for ease of rollback) * External optical taps will be removed (too lossy at 10Gb) * External and internal connections from the Cisco will be moved to the new routers * Internal links will be brought up and internal traffic will be checked (flows between wireless/wired) * External link will be brought up and routing tables will be checked. Area of Activity: GC core router and Internet connection    
6118.html 2016-08-23 19:46 Activity: Move code from separate device support module and libraries directly into FMCS EPICS IOC. Add relative humidity channels to FMCS EPICS IOC. Requires DAQ restart to add humidity channels to frames.    
6117.html 2016-08-23 16:49 Activity: Recompilation of the SUSETMY front-end model to add the second synchronized oscillators (LHO alog 29231).   29245, 29231, 29245
6116.html 2016-08-23 15:35 Activity: Removal and inspection of the OMC DCPD AA chassis. Repair and testing of channel 14.   29257
6115.html 2016-08-23 15:13 Activity: Improve the lock loss monitor by adding information that the arms are locked in red. Requires TwinCAT corner reboot. [h1ecac1plc1 code changes.]   29251, 29252
6114.html 2016-08-22 21:43 Activity: Perform annual maintenance at Mid-Y and LSB. [Hanford Fire Department inspection.]    
6113.html 2016-08-22 21:14 Activity: Collect data from CP4 manual fills to simulate CP3 in an effort to write code for CP3 manual overfill work-around. Experiment: 1) set CP4 LLCV in manual mode to nominal setting 2) increase LLCV in 10% increments while monitoring flow meter, exhaust pressure, and CP level 3) Repeat   29179, 29248
6112.html 2016-08-22 16:11 Activity: Replace broken water cooled power meter in HPO. The power meter did not survive the June power outage. This is the power meter in the HPO's external shutter assembly; power meter can be swapped in situ, external shutter assembly removal is not required. The PSL and its chillers will have to be shut down for this work.   29270
6111.html 2016-08-22 16:02 Activity: Energize RGA and take post-bake scans to assess effectiveness of recent bake * Combine RGA volume to Vertex Vacuum Volume if applicable * Decouple locally mounted turbo pump from RGA and install 1 1/2" O-ring valve in place of turbo (requires venting one side of metal valve which isolates turbo from Vertex Vacuum Volume * Pump to rough vacuum volume between newly installed O-ring valve and existing metal valve * Shut down pump cart   29194, 29196
6110.html 2016-08-22 15:53 Activity: Take Asahi Shinbun staff to the site tour. We'll enter LVEA in the morning and will stay there for less than an hour.    
6109.html 2016-08-22 15:46 Activity: Tour PNNL and visiting physicists through site and LVEA. We expect to be in the LVEA for 30min starting approximately 10am, on Tue 23rd.    
6108.html 2016-08-22 15:22 Activity: Change pre-filters on AHU-2.    
6107.html 2016-08-22 15:17 Activity: Flow test and zero count all dust monitors in LVEA, Diode Room, Optics Lab and both end stations. Have already tested the PSL dust monitors. Do Not need to get into the PSL enclosure.    
6106.html 2016-08-22 14:18 Activity: Install conduit from mechanical room to air handler rooms, pull control wiring and install electric actuators at AHU 1,2,& 3.    
6105.html 2016-08-19 21:44 Activity: Pull EtherCAT End Station Chassis 3 at EY and EX. Will inspect cabling for the Demod readbacks for the green WFS. Fault Report 6024    
6104.html 2016-08-19 20:12 Activity: Install 200 kHz pole optional daughter board into IMC PDH Common Mode Servo Board (D040180). See LHO aLOG 28363. Should not take more than an hour.   29250
6103.html 2016-08-19 18:05 Activity: Valve in 500 L/s ion pump and valve out turbo pump. Pressure is currently at 1.1e-6 Torr (new gauge). Pressure will initially rise; after pressure reduction is observed, we will power down turbo and backing scroll pump.   29206
6102.html 2016-08-19 16:28 Activity: upgrade h1dmt0 to SL7, as requested by John Zweizig    
6101.html 2016-08-19 13:55 Activity: Replace Beckhoff temperature module 3202. One channel has been failed since installation. This is the link chassis so all of the Beckhoff will be disconnected.   29200
6100.html 2016-08-19 12:03 Activity: Make corrections to the FSS front end model. The corrections are related to the temperature readouts for the reference cavity. Currently these do not reflect the hardware in place. This work will require a restart of the FSS front end model and a DAQ reboot.   29229, 29197
6099.html 2016-08-18 21:09 Activity: Measure transfer functions of OMC DCPD AA   29189
6098.html 2016-08-18 17:13 Activity: Tour for family member which will include LVEA (as long as Operator gives OK).    
6097.html 2016-08-18 15:01 Activity: VIP tour a group from the US House Science Subcommittee on Research & Technology    
6096.html 2016-08-18 00:15 Activity: Add dust monitor Temp and R/H channels to EPICs   29177
6095.html 2016-08-17 17:43 Activity: Check suspected water leak in the high power oscillator.   29203, 29190, 29186
6094.html 2016-08-17 16:55 Activity: Replace faulty check valve on instrument air compressor tank at Mid X.    
6093.html 2016-08-17 15:45 Activity: Swap CO2 laser RF driver on TCSx table and measure the output power of the TCSx CO2 laser. We want to test if we have a bad RF driver from the TCSy laser, and the best way to do that is install the RF driver into a working system and see if the output power changes. Once complete we will reinstall the original TCSx RF driver to return the TCSx CO2 laser to normal operation. Risk to the TCSx CO2 laser is low.   29174
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 04:46, Wednesday 24 August 2016 - last comment - 09:49, Wednesday 24 August 2016(29270)
power meter replaced in high power oscillator
The power meter in the high power oscillator's external shutter was replaced.  The existing unit
ceased to function some time around the planned power outage a couple of months ago for reasons
best known to itself.

old S/N = 589365
new S/N = 627203

Jason/Peter
Comments related to this report
peter.king@LIGO.ORG - 08:26, Wednesday 24 August 2016 (29272)
Forgot to mention that the hoses for the power meter and front end cooling circuits were swapped over
at the water manifold under the table.  Given that the hoses were labelled numerically, this seems to
have been a remnant from the laser installation.
jeffrey.bartlett@LIGO.ORG - 09:38, Wednesday 24 August 2016 (29276)
  After the hose swap yesterday the flow of the PSL_AMP_FLOW dropped by 0.3bar and the PWRMETERFLOW increases by 0.4bar. 
Images attached to this comment
jason.oberling@LIGO.ORG - 09:49, Wednesday 24 August 2016 (29277)

The hoses were swapped because we found that they were hooked up backwards.  I.E. the MOPA cooling hose was plugged into the Power Meter water circuit and vice versa (most likely during the recent water manifold swap).  This means that in the trend data the flow for the front end (H1:PSL-AMP_FLOW) was actually reading the flow through the power meter circuit; the same applies to the power meter circuit flow (H1:PSL-OSC_PWRMETERFLOW), it was actually reading the flow for the front end.  This was fixed yesterday and the flow data is now reading from the correct water circuits.

H1 AOS
terra.hardwick@LIGO.ORG - posted 02:23, Wednesday 24 August 2016 (29269)
ASC SOFT loops work

Sheila, Terra

Tonight we implemented the decoupled ASC SOFT matrix (first tried here but reverted a few days later). In past locks, the test mass op levs show common soft drift during power up; diagonalizing SOFT and HARD should help reduce this. 

Powering up with this new matrix rang up a CSOFT power-to-angle instabiltiy ~0.5 Hz, causing us to break lock a few times near the end of power up. Next lock, we stopped at 20 W and adjusted SOFT offsets to get the best alignment (PRG ~32) and then powered up to 50 W successfully with no instability.

We still lost PRG during the remaining power increase, so adjusted POP_A offsets then SOFT offsets again. POP_A offsets only slightly improved; far less dramatic than with old matrix and SOFT offsets. In the end we recovered quite a bit of PRG but at the cost of sideband loss. Final offsets shown in attachment.

Tomorrow we'll try applying offsets at 2 W and/or putting offsets on QPDs instead. We're leaving the new matrix implemented in the guardian (but not offsets yet).

We also had trouble with bounce modes tonight, mostly in ETMX. This was solved by turning on the EVANBR filter (which was the only test mass that hadn't had this filter turned on). We did not see the 9.4 Hz DHARD_P instability

We leave the interferometer at 50 W with DOWN requested.

Images attached to this report
LHO General
corey.gray@LIGO.ORG - posted 00:04, Wednesday 24 August 2016 (29268)
EVE Operator Summary

First few hours of the shift were spent with recovery from the issues at the electronics racks out on the floor near the PSL.  As Jeff K, noted, when we tried walking through locking we found issues with the MC Common Mode Servo Board (it was swapped out per his alog). 

The rest of the evening was spent with commissioning.

There was a 6+ magnitude earthquake which shook things around (while we were still in recovery mode)---hope Virgo rode through it OK.

H1 ISC (CDS, IOO)
jeffrey.kissel@LIGO.ORG - posted 20:25, Tuesday 23 August 2016 - last comment - 10:17, Friday 02 September 2016(29265)
IFO Recovery: IMC's Common Mode Chassis (S1102626) Input 2 has 2 [V] Offset; Temporarily Replaced with Spare (S1102627)
S. Dwyer, J. Kissel, C. Gray

After successfully recovering the IMC's VCO and recovering the IMC (29264), we were able to get up through LOCKING_ARMS_GREEN in the lock acquisition sequence. However, we found that ALS COMM failed caused lock losses during the next step (LOCKING_ALS), when the input for IMC length control in its Common Mode Chassis was switched from the IMC's PDH output to the ALS COMM PLL output. The ALS COMM PLL output is connected to IN2 of the IMC chassis that had a new daughter board installed in the star-crossed ISC rack H1-ISC-R1 today (LHO aLOG 29250). After fighting through MEDM screen confusion* at the racks, we found that OUT2 (an analog pickoff pick-off just after the input gain circuit) indicated a ~2.5 [V] offset, even with IN2 terminated with 50 [Ohms]. 

Suspecting that this symptom was indicative that the input gain circuit (circled in red in MEDM screen capture) was yet another causality of the unfortunate rack power mishap today (LHO aLOG 29253), we've replaced the entire chassis (which lives in U14 of H1-ISC-R1) with a spare we found in the EE shop -- S/N S1102627 (or Board S/N S1102627MC). 

Notably, this spare does not have one of the new daughter boards on which Chris has worked so hard.

We're not suggesting this swap be permanent, but we make the swap for tonight at least, so we can hopefully make forward progress. We suggest that IN2 and/or the input gain stage of SN S1102626 be fixed tomorrow, and the chassis restored so we can employ the new daughter board.

Other Details:
- Before removing the chassis, we powered down the entire rack using the voltage sequencer around the back at the top of the rack. 
- After installing the rack, we were sure to have all cables connected appropriately before turning the rack power on again (via the sequencer again).
- We added a few labels to the IMC's PDH output and the ALS COMM PLL output cables such that they're easier to follow and reconnect in the future.

*MEDM Screen Confusion -- whether IN1 or IN2 is fed into OUT2 of all common mode chassis is selectable on their MEDM screens. For the IMC's common mode board (at least for SN S1102626), the MEDM screen's indication of the status of that switch is exactly backwards. When the screen indicates that IN1 is feeding OUT2, IN2 is feeding OUT2, and vice versa. #facepalm
Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 00:00, Wednesday 24 August 2016 (29267)

With Sheila's help, the OUT 2 switch should now be correct for the MC Common Mode Servo medm (H1IMC_SERVO.adl).  This change was committed to the svn.

jeffrey.kissel@LIGO.ORG - 16:47, Wednesday 24 August 2016 (29290)CDS, IOO, SYS
M. Pirello (reported by J. Kissel from verbal discussion with F. Clara)

Marc has inspected the Common Mode Board chassis we've removed (SN S1102626), and indeed found several blown transistors and opamps -- and is not even through the chassis test procedure. Unfortunately, the EE shop needs a restocking of surface mount components before we can make the repairs, but the plan is to shoot for a re-install of this board by next Tuesday (Aug 30th). 
marc.pirello@LIGO.ORG - 10:17, Friday 02 September 2016 (29466)

Repairs to S1102626 are complete and the chassis has been tested with the 200kHz low pass filter.  The chassis performance is similar to the previous test performed September 2011.  

When the 200kHz low pass filter is activated we detected a 3mV dc offset which should be noted.  The low pass filter works as designed with -3dB gain at 200kHz and rolls off nicely.  I have attached files from the testing.  File details can be found in the readme.txt included in the zip.

Non-image files attached to this comment
H1 CAL (CAL)
darkhan.tuyenbayev@LIGO.ORG - posted 18:24, Tuesday 23 August 2016 (29263)
A notch at PcalY line frequency (331.9 Hz) was turned

A notch at 331.9 Hz in now turned on in the LSC-DARM2, FM4. The change was accepted in SDF_OVERVIEW "safe.snap" and "OBSERVE.snap".

This filter suppresses the DARM loop at PcalY calibration line frequency that is used to track the optical gain and the coupled-cavity pole frequency.

In an earlier report we pointed out that the notch was switched off during ER9 (see LHO alog 29108).

Images attached to this report
H1 CAL (CAL)
evan.goetz@LIGO.ORG - posted 17:34, Tuesday 23 August 2016 - last comment - 10:25, Tuesday 01 November 2016(29259)
Better understanding Pcal timing signals
Summary:
Repeating the Pcal timing signals measurements made at LHO (aLOG 28942) and LLO (aLOG 27207) with more test point channels in the 65k IOP model, we now have a more complete picture of the Pcal timing signals and where there are time delays.

Bottom line: 61 usec delay from user model (16 kHz) to IOP model (65 kHz); no delay from IOP model to user model; 7.5 usec zero-order-hold delay in the DAC; and 61 usec delay in the DAC or the ADC or a combination of the two. Unfortunately, we cannot determine from these measurements on which of the ADC or DAC has the delay.

Details:
I turned off the nominal high frequency Pcal x-arm excitation and the CW injections for the duration of this measurement. I injected a 960 Hz sine wave, 5000 counts amplitude in H1:CAL-PCALX_SWEPT_SINE_EXC. Then I made transfer function measurements from H1:IOP-ISC_EX_ADC_DT_OUT to H1:CAL-PCALX_DAC_FILT_DTONE_IN1, H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1, and H1:CAL-PCALX_SWEPT_SINE_OUT to H1:CAL-PCALX_TX_PD_VOLTS_IN1, as well as points in between (see attached diagram, and plots)

The measurements match the expectation, except there is one confusing point: the transfer function H1:IOP-ISC_EX_MADC0_TP_CH30 to H1:CAL-PCALX_DAC_NONFILT_DTONE_IN1 does not see the 7.5 usec zero-order-hold DAC delay. Why?

There is a 61 usec delay from just after the digital AI and just before the digital AA (after accounting for the known phase loss by the DAC zero-order-hold, and the analog AI and AA filters). From these measurements, we cannot determine if the delay is in the ADC or DAC or a combination of both. For now, we have timing documentation such as LIGO-G-1501195 to suggest that there are 3 IOP clock cycles delay in the DAC and 1 IOP clock cycle delay at the ADC.

It is important to note that there is no delay in the channels measured in the user model acquired by the ADC. In addition, the measurements show that there is a 61 usec delay when going from the user model to the IOP model.

All this being said, I'm still a little confused from various other timing measurements. See, for example, LLO aLOG 22227 and LHO aLOG 22117. I'll need a little time to digest this and try to reconcile the different results.
Non-image files attached to this report
Comments related to this report
shivaraj.kandhasamy@LIGO.ORG - 09:53, Thursday 25 August 2016 (29298)

By looking at the phase of the DuoTone signals we can constrain whether there is any delay in ADC side (like Keita's analysis here). The DuoTone signals are desgined such that the two sinusoidal signals 960 Hz and 961 Hz will be maximum at the start of a GPS second (and also in phase with each other). To be presice, the maximum will be 6.7 µs delayed from the integer GPS boundary (T1500513). The phase of 960 Hz signal at IOP (L1:IOP-ISC_EX_ADC_DT_OUT) is -92.52 degrees with respect to GPS integer boundary (LLO a-log 27207). Since the DuoTone signal is supposed to be maximum at GPS integer boundary i.e, it is a cosine function, this corresponds to -2.52 degrees (estimate of 92.52 assumes it is a sine function) phase change. Converting this phase change to time delay we get 7.3 µs. Since there is an inherent 6.7µs delay by the time the DuoTone signals reaches the ADC, we are left with only 0.6 µs delay possibly from ADC process (or some small systematic we haven't accounted for yet). This is what Keita's measurements were showing. Combing this measurment and above transfer function measurments we can say that we understand the ADC chain and there are no time delays more than 0.6 µ in that chain. This also suggest that the 61 µs delay we see in ADC-DAC combination exist completely in DAC side.  

evan.goetz@LIGO.ORG - 10:44, Tuesday 27 September 2016 (29999)CAL
The DuoTone signals are sine waves, so a minor correction to Shivaraj's comment above, the zero-crossing corresponds to the supposed GPS integer second. I looked at a time series and observe that the zero-crossing occurs at ~7.2 usec. Since the analog DuoTone signal lags behind the GPS second by ~6.7 usec, I can confirm that the ADC side has essentially no delay. Thus, the 61 usec seen through the DAC-ADC loop is entirely on the DAC side.

Attached is a time series zoom showing the zero crossing of the DuoTone signal.
Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 16:41, Thursday 06 October 2016 (30282)

When using dtt to make a transfer function measurement between an IOP model and a user model, one has to keep in mind that dtt does another decimation silently. This is due to dtt trying to match the number of data points between two models. Fortunately, this does not seem to affect the phase, see my note at https://dcc.ligo.org/T1600454.

evan.goetz@LIGO.ORG - 10:25, Tuesday 01 November 2016 (31062)
Updated the timing diagram for consistency with other timing measurements (LHO aLOG 30965). See attached PDF to this comment.
Non-image files attached to this comment
H1 ISC
chris.whittle@LIGO.ORG - posted 14:36, Tuesday 23 August 2016 - last comment - 18:34, Tuesday 23 August 2016(29250)
Installed FSS IMC 200kHz LPF daughter board

Marc P, Chris W

As per Work Permit #6104, we added a 200 kHz lowpass filter (D1600314) to the fast path of the Common Mode Servo Board (D040180), located in the LVEA ISC-R1 rack. The serial number of the servo board is S1102626.

When reconnecting the power to the Common Mode Servo Board, the 17V supply was connected first (should connect 24V first or use the sequencer), which resulted in blowing diodes D4 and D5 at the power input (see D0901846). At the time, we saw LEDs of other boards on the rack turning off. The diodes were replaced and the current drawn by the Common Mode Servo Board was confirmed to be the same as drawn by an equivalent spare board. The board was then replaced in ISC-R1 rack, this time using the sequencer switch to power cycle the whole rack.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 14:12, Tuesday 23 August 2016 (29253)

For reasons unknown it seems that the first channel on the modecleaner IQ demodulator broke today. The I output gives a fixed 300mV offset. We switched to the second channel (spare).

I also removed 2 TNC-to-BNC adapters, 2 BNC cables and a BNC barrel which were used to connect the I output of the demodulator with the IMC board input. This mashup was replaced with a proper TNC cable.

vernon.sandberg@LIGO.ORG - 17:30, Tuesday 23 August 2016 (29262)FRS, ISC

An FRS ticket has been opened for this event.  See https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=6084

daniel.sigg@LIGO.ORG - 18:34, Tuesday 23 August 2016 (29264)

The IMC VCO had a couple of blown OpAmps that were replaced. The IMC is locking again and the MC_F spectrum looks OK.

H1 OpsInfo (SYS)
jim.warner@LIGO.ORG - posted 11:17, Tuesday 23 August 2016 - last comment - 09:11, Wednesday 24 August 2016(29247)
Python script to do weekly oplev trends

I've made a script to somewhat automate the weekly oplev trends FAMIS task. It makes 3 plots like the attached image of the oplev pit, yaw and sum channels for the test-masses, BS, PR3 and SR3. It still requires a little fiddling with the plot, you have to zoom in manually on any plots that have 1e9-like spikes, but this should still be easier than running dataviewer templates. It uses h1nds for data and a pre-release version of the python nds2 client that has gap handling, so updates in the future could break this. I'll try to maintain this script, so any changes or improvements should come to me. The script lives in the userapps/sys/h1/scripts folder.

The script is run by going to the sys/h1/scripts folder:

jim.warner@opsws0:~ 0$ cd /opt/rtcds/userapps/release/sys/h1/scripts

And running the oplev_trends.py script with python:

jim.warner@opsws0:scripts 0$ python oplev_trends.py

You will then need to do the usual zooming in on useful data, saving screen shots and posting to the alog. I'll look into automating more of this, but it works well enough for now. It would also be very easy to add this to a "Weeklies" tab on the sitemap, which I believe LLO has done with some similar tasks.
 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 15:01, Tuesday 23 August 2016 (29255)

I've now added the HEPI monthly pressure trends to the same folder. Admittedly, there's little difference here between running my python script and running the dataviewer template, as the HEPI trends all fit on one dataviewer window easily. But this was pretty easy to throw together, and may allow us to automate these tasks more in the future, say if we could couple this with something like TJ's shift summary alog script.

Running it is similar to the oplev script:

jim.warner@opsws0:~ 0$ cd /opt/rtcds/userapps/release/sys/h1/scripts
 

jim.warner@opsws0:scripts 0$ python hepi_trends.py
 

Images attached to this comment
Non-image files attached to this comment
jason.oberling@LIGO.ORG - 09:11, Wednesday 24 August 2016 (29275)

For the oplev trends, they look good.  I'll update the FAMIS procedure to run this script instead of using dataviewer. 

Can you add the HAM2 oplev to this as well?  While its usefulness is debated, it is an active optical lever so we should be trending it as well.

Thanks Jim!

LHO VE
kyle.ryan@LIGO.ORG - posted 19:32, Friday 12 August 2016 - last comment - 14:06, Wednesday 24 August 2016(29079)
Y-end RGA captures IFO locking effects on partial pressures
After decoupling the pumping components used during the recent bake out of the Y-end RGA, I exposed the RGA to the Y-end vacuum volume, energized the filament and let it come into equilibrium for an hour or more.  I then let the RGA scan continuously with the multiplier (SEM) on for an additional hour or so while I gathered up my mess(es).  I periodically checked the scanning as I walked past the screen.  At one point, I noticed that the spectrum was changing rapidly towards the "dirty".  I monitored the scanning and noted that after reaching a temporary maximum, the amus which had increased then returned to near their original values.  

After consulting with the Jeff B. (the operator on shift), I feel that the observed changes in partial pressures were likely the result of IFO locking attempts as they coincide closely in time.  Perhaps something gets hot when the IFO is locked or when mirrors are steered?  

See attached scans 
Non-image files attached to this report
Comments related to this report
michael.zucker@LIGO.ORG - 04:46, Saturday 13 August 2016 (29086)

If true that could be kind of scary (!)  Can we set an RGA in MID (stripchart) mode and run time series following the main peaks through a locking attempt?

 I could imagine baking the adsorbed water off the ETM and perhaps nearby baffles. But this should not persist (or repeat) after the first good cavity buildup. 

 

 

 

joshua.smith@LIGO.ORG - 15:39, Saturday 13 August 2016 (29087)DetChar
It's not clear whether this effect could be seen on the overall vacuum pressure, but if it could be, we don't see it. Here is 8 hours (yesterday/today) ofthe y-end vacuum pressure together with the y-arm transmitted power. I don’t see anything in the vacuum pressure channels that relates to the locking attempts, though that may be my untrained eye. 
 
1. H1:ASC-Y_TR_A_NSUM_OUT_DQ, raw,start: 2016-08-13 00:00:00 (1155081617) len: 8:20:00. 
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137580
 
2. H0:VAC-EY_Y3_PT410B_PRESS_TORR, raw,start: 2016-08-13 00:00:00 (1155081617) len: 8:20:00. 
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137573
 
3. H0:VAC-EY_Y2_PT424B_PRESS_TORR, raw,start: 2016-08-13 00:00:00 (1155081617) len: 8:20:00. 
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137576
 
...and here is 5 hours from the day we think the lock losses damaged the OMC (this includes the 5 lock losses reported in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=28684 ). 
 
4. H1:ASC-Y_TR_A_NSUM_OUT_DQ, raw,start: 2016-07-27 03:40:00 (1153626017) len: 5:00:00.
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137591
 
5. H0:VAC-EY_Y2_PT424B_PRESS_TORR, raw,start: 2016-07-27 03:40:00 (1153626017) len: 5:00:00. 
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137590
 
6. H0:VAC-EY_Y3_PT410B_PRESS_TORR, raw,start: 2016-07-27 03:40:00 (1153626017) len: 5:00:00. 
https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=137589
 
I don’t see any obvious relationship between these high power locks and vacuum pressure in the Y-end. 
 
The last plot shows the first set of data with the vacuum channels highpassed 3rd order at 1Hz. Nothing visible. 
 
Let me know if you’d like to chase this another way. 
Images attached to this comment
kyle.ryan@LIGO.ORG - 20:36, Saturday 13 August 2016 (29090)
Mike - 
Chandra's stated goal is to eventually continuously trend 7 AMUs (max allowed by software) at each building.  The observance cited in this aLOG obviously would have been missed while in Faraday.  Too bad that the RGAs don't live long with their SEMs on 24/7.  As we install/commission the RGAs and as she works out the issues with the CDS and/or GC folks this trending will eventually be happening.  


J. Smith - 
The partial pressures that are changing are too small and not expected to show up on the total pressure gauges. From the graphic scans and knowing that the total pressure at the Y-end is 2 x 10-9 torr, we see that the partial pressures that changed are small (10-12 torr) - but still interesting because they are measurable and even more interesting if the changes can be shown to be tied to some IFO locking activity.  (Science interesting?  Who knew?)
kyle.ryan@LIGO.ORG - 09:17, Monday 15 August 2016 (29101)
Doh!!!  Here are the .txt versions of the ASCII data
Non-image files attached to this comment
kyle.ryan@LIGO.ORG - 14:06, Wednesday 24 August 2016 (29283)
The indicated currents for these scans are typical of the SEM @ 1300 volts (which is the factory default). I have noticed in the past that setting the SEM voltage value in the EDIT tab does not change the value displayed in the device status screen or vice versa - so, though I set this to 1500 volts in one of those two fields, it may not have taken effect.
Displaying reports 54661-54680 of 83146.Go to page Start 2730 2731 2732 2733 2734 2735 2736 2737 2738 End