Displaying reports 12721-12740 of 84342.Go to page Start 633 634 635 636 637 638 639 640 641 End
Reports until 16:01, Friday 27 October 2023
H1 General
camilla.compton@LIGO.ORG - posted 16:01, Friday 27 October 2023 (73780)
Ops Day Shift End

TITLE: 10/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: IFO has been locked 28h30. Just finished up a commissioning period from 20:00 to 22:55UTC
LOG:

During commissioning:

This morning we had to touch FC2 alignment when the FC unlocked 73770, but since then Naoki has adjusted the FC2 beam centering 73777 so we except this won't be an issue in the future.

Start Time System Name Location Lazer_Haz Task Time End
15:21 FAC Randy EY N Lab room 17:16
17:40 FAC Randy MY N MY 19:40
18:02 FAC Kim MX N Technical Cleaning 18:33
18:59 FAC Kim H2 N Technical Cleaning 19:10
20:02 ISC Camilla CR N Mich FF measured 20:21
20:21 COMM Vlad CR N PI injections 15kHz 22:21
20:22 CAL Louis CR N Calib sweeps for DARM boost 23:00
21:00 SQZ Naoki CR N Retune and FC2 centering 23:00
21:03 PCAL Tony PCAL lab Local PCAL ?????
21:16 AOS Jason, Austin Optics Lab N Oplev work 22:39
H1 General
ryan.crouch@LIGO.ORG - posted 15:57, Friday 27 October 2023 (73781)
OPS Friday eve shift start

TITLE: 10/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
OUTGOING OPERATOR: Camilla
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 20mph Gusts, 15mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

H1 ISC
camilla.compton@LIGO.ORG - posted 15:47, Friday 27 October 2023 - last comment - 15:04, Tuesday 14 November 2023(73773)
MICH FF Remeasured but not Changed

Took MICH FF measurements following instructions in lsc/h1/scripts/feedforward/README.md but running MICHFF_excitation_ETMYpum.xml. Data saved in lsc/h1/scripts/feedforward/ as .txt files. Last tuned MICH in 73420

I saved a new filter in FM6 as 27-10-23-b (red trace) but it made the MICH coupling worse between 20 and 80Hz so we left the original (pink trace). We could try to re-fit the data to load in Wednesday's commissioning period.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 14:49, Sunday 29 October 2023 (73821)

I re-fit this data and think i have a better filter saved (not loaded) in FM3 as "27-10-23-a". We could try this during a commissioning period this week if we wanted to try to further improve MICH.

Plot attached of proposed filter FM3 (red) with current filter FM5 (blue REF0) and Friday's failed filter FM6 (green REF1). 
We would like to be close to FM5 (blue) 20-80Hz close to FM6 (green) above and below this. Proposed filter does have increased gain at low frequencies.
Images attached to this comment
camilla.compton@LIGO.ORG - 15:04, Tuesday 14 November 2023 (74206)

Tried this FM3 FF 2023/11/14 16:04:30UTC to 16:06:30UTC. It did not cause a lockloss. I did not run the MICH comparism plot but DARM looked slightly worse. Plot attached.

From 16:07:05, I tried FM6 which is the currently installed MICH FF (FM5) without the 17.7Hz feature 74139.

Images attached to this comment
naoki.aritomi@LIGO.ORG - 13:57, Friday 03 November 2023 (73962)

I tried to test a new MICH FF FM3 Camilla made. First I measured the current MICH FF FM5 as shown in the attached figure. The pink and black curves are the current MICH FF FM5 on 20231027 and 20231103, respectively. The current MICH FF gets worse between 30-80 Hz in a week. The MICH FF on 20231103 was measured after 6.5 hours into lock. Then I ramped the MICH FF gain to 0 and turned off FM5 and turned on FM3. After I ramped the MICH FF gain to 1, a lockloss happened immediately.

Images attached to this comment
camilla.compton@LIGO.ORG - 11:13, Monday 06 November 2023 (74021)

Sorry that this caused the 1383077917 lockloss.

Unsure why this FM3 would be unstable. Lockloss occurred 10 seconds after MICHFF had finished ramping on (13s - 3sec ramp time). FM3 MICH_FF looks to be outputting ~ factor of 2 higher than the current FM5 filter. Don't see any obvious instabilities in the 10seconds before the lockloss.

LSC and ASC plots attached. I wonder if the lockloss was just badly timed. We could attempt to repeat this before our Tuesday Maintenance period.

Images attached to this comment
H1 SUS (ISC)
jenne.driggers@LIGO.ORG - posted 15:43, Friday 27 October 2023 - last comment - 11:51, Tuesday 31 October 2023(73778)
Script ready for changing BS M2 coil driver state

A recent suggestion is that we see if the BS coil drivers are a limit to our sensitivity now.  The way we'd check is to put the BS back to it's acquisition state, and see if we see noise in DARM.  Any excess noise can then be projected down with the ratio of the coil driver filters. 

I took an old version of a coil state switching script (from userapps/isc/guardian/bs_m2_switch_fast.py), and added to it turning off the output gain (upon recommendation of LLO who suspects that as contributing to their lockloss).  We don't have time to try it out today, but the script (attached here, as well as checked in to userapps) should be ready to try next week.  We can consider running it on Tuesday morning just to check that there are no issues with it, but then actually try it Wednesday afternoon.

To turn the BS to it's actuation state, line 12 setting the 'actuatorState' variable should be set to 2, then run the script.  Then, to go back to the lownoise setting, change that variable back to 3 and re-run the script.

Note that the BS suspension guardian can take us from the acquisition state to the low noise state gracefully, but it doesn't look like it's got built-in a graceful way to go back to the high noise state.

Non-image files attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 11:51, Tuesday 31 October 2023 (73869)

We were not locked (due to an earthquake) at the beginning of maintenance, so we have not yet tried this with the IFO locked.

However, I ran it a few times during maintenance and it seems to work.  I did need to update the script to convince it to work with python3 (the version I started with was quite old).  I attach the updated script here, but it's also still in userapps/isc/h1/guardian/bs_m2_switch_fast.py

I see some small motion in the BS optical lever siganls when I do the switching, particularly from the low noise state to the high range state (3->1->2), but I'm still working on convincing ndscope to lookback at data from the last time we went through ISC_LOCK state 552 (lownoise_coil_drivers) to see what scale of oplev motion we normally survive in that state.

I might try running this once or twice as we acquire lock after maintenance today, but otherwise this is probably as ready to go as possible in preparation for trying it during a commissioning time.

Non-image files attached to this comment
H1 SQZ
naoki.aritomi@LIGO.ORG - posted 15:29, Friday 27 October 2023 (73777)
FC2 centering

Since the FC2 centering is not good now and it could cause the FC2 L2A coupling issue in alog73770, I centered FC2 using IR dither. The first attached figure shows the FC IR error signal with FC1/2 dithered. FC2 is dithered at 7.1Hz in pitch and 16.1Hz in yaw. You can see the FC2 dither peak at 7.1Hz, which indicates that FC2 centering is not good in pitch. I changed the green QPD offset at FC transmission while running FC ASC to minimize the peak at 7.1Hz. I changed the offset of INJ ANG P from 0.08 to 0.18 as shown in the second and third attached figures. After the centering, the dither peak at 7.1Hz is removed and the FC2 centering is as good as one in May.

Images attached to this report
H1 ISC (CAL)
louis.dartez@LIGO.ORG - posted 14:00, Friday 27 October 2023 - last comment - 20:42, Monday 30 October 2023(73776)
DARM Boost activated in DARM2 FM2
I activated Jenne's DARM2 boost from LHO:73745 (in FM2) at 10/27/2023 13:25:54. The FM2 change has been saved in SDF.

The file that includes this new DARM2 boost filter is at /opt/rtcds/lho/h1/chans/filter_archive/h1omc/H1OMC_1382307261.txt. I've copied it to /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/H1CalFilterArchive/h1omc for the Cal group. The file has been committed to the SVN. The corresponding repo has been updated on the LHO cluster under the cal account too.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 14:54, Saturday 28 October 2023 (73802)

Added this FM2 boost to ISC_LOCK state LOWNOISE_LENGTH_CONTROL, FM2 is now turned on at the same time as DARM2 FM8 is.

louis.dartez@LIGO.ORG - 20:42, Monday 30 October 2023 (73859)
This Calibration-affecting change has been recorded in the H1 Record of Real-Time Calibration Pipeline Parameter Changes (DCC T2300297).
H1 CAL (DetChar)
louis.dartez@LIGO.ORG - posted 13:41, Friday 27 October 2023 (73774)
CW injection stays on during NLN_CAL_MEAS
Jenne, Vlad, Louis


Vlad noticed that the injection on H1:CAL-INJ_CW_EXC stays on during NLN CAL MEAS. This is a note to say that we should have ISC_LOCK turn it off/on when moving into/out of NLN_CAL_MEAS.
LHO VE
david.barker@LIGO.ORG - posted 10:20, Friday 27 October 2023 (73772)
Fri CP1 Fill

Fri Oct 27 10:14:19 2023 INFO: Fill completed in 14min 14secs

Jordan confirmed a good fill curbside. Outside air +6C, TC mins -138C, -129C.

Images attached to this report
H1 General (DetChar)
camilla.compton@LIGO.ORG - posted 10:14, Friday 27 October 2023 (73771)
20Hz Peaks in DARM

Vlad and I noticed a set of 20Hz peaks in DARM at 16:50UTC, see attached. Maybe similar to the peaks Robert and Tyler mitigated by changing AC settings in 73430

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 09:20, Friday 27 October 2023 - last comment - 09:33, Friday 27 October 2023(73769)
Out of Observing 15:40 to 15:56UTC as SQZ FC Unlocked

Vicky, Camilla

IFO was Out of Observing 15:40 to 15:56UTC as SQZ FC Unlocked. After 5 failed automatic SQZ_FC TRANSION_IR_LOCKING attempts, Vicky and I kept the FC GRD in DOWN, closed the Input 1 loop (SQZ Overview > FC Servo > H1:SQZ-FC_SERVO_IN1EN) to manually lock FC on green and aligned FC2 using the GR camera and maximizing H1:SQZ-FC_TRANS_C_LF_OUTPUT. Accepted FC2 alignment sdfs and went back to observing. Updated "Issues with SQZ FC Guardian" wiki

Think the issue could have been due to alignment drifts over the long 21 hour lock and as the M3 length was cleared, this couples in with pitch and yaw alignments, plot attached. Enough that the FC2 alignment needed to be slightly tweaked to relock. From plot, can see that M2 Pit (grey trace, bottom left) changed ~40urad on FC unlock?! This is a lot of drift over 20 hours, zoomed out plot here.

Images attached to this report
Comments related to this report
victoriaa.xu@LIGO.ORG - 09:33, Friday 27 October 2023 (73770)

We have previously decoupled L2A for FC2's M1 stage, see LHO:67957, March 2023, most L2A decoupling was needed in pitch. But we have not decoupled L2A for FC2's lower M3 stage (in principle we should not have to do this as most DC gain is on M1). More relevant is probably that since March 2023, the beam spots on FC1/2 mirrors have since drifted away from center so the previous L2A decoupling may be less valid now. May be worth checking and re-centering FC cavity axis on the optic centers now, where our previous L2A decoupling should work better, and may overall be more stable. 

I think that if L2A decoupling coefficients are very different now, that could impact FC alignment and relocking after long lock stretches. That's basically what happened before, which led us to do the decoupling FC2 M1 L2A in the first place (i.e., after long locks, the FC alignment drifts a lot due to the length-to-pitch coupling, such that when FC unlocks and we stop pushing on FC2 in length, then FC2 pitch changes suddenly and we lose FC alignment). Something to keep an eye on as Camilla's fixing of FC2 pitch alignment seemed to recover the filter cavity lock transition from green to red, which feels similar to before.

H1 General
camilla.compton@LIGO.ORG - posted 08:04, Friday 27 October 2023 (73768)
Ops Day Shift Start

TITLE: 10/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 162Mpc
OUTGOING OPERATOR: Austin
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

IFO has been locked 20h30. There is plans for commissioning time 1-3pm this afternoon.

H1 General
anthony.sanchez@LIGO.ORG - posted 00:02, Friday 27 October 2023 (73767)
Thursday Ops Eve Shift End

TITLE: 10/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 163Mpc
INCOMING OPERATOR: Austin
SHIFT SUMMARY:
Very Quiet night. Violins look great! Everything running smoothly.
 

H1 Current Status: Locked in NOMINAL_LOW _NOISE & OBSERVING for 12.5 hours. 


LOG:
No Log

 

H1 General
oli.patane@LIGO.ORG - posted 16:08, Thursday 26 October 2023 (73765)
Ops DAY Shift End

TITLE: 10/26 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 163Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Earlier lockloss due to earthquake, then we needed to do an Initial Alignment before being able to lock agian. Currently inn Observing and have been Locked for 4.5hours.
LOG:

15:00UTC Detector Locked for 2.5hours

16:20 Earthquake mode activated due to local earthquake
16:25 Earthquake incoming from Japan
16:38 Lockloss due to earthquake
    - Holding in DOWN for ~10mins
    
16:53 Started relocking
17:21 Took us to DOWN to start an initial alignment
    - While I was waiting for PREP_FOR_LOCKING to complete, IMC kept going between OFFLINE and FAULT
17:23 Started Initial Alignment
17:43 INITIAL_ALIGNMENT complete, started relocking
    -At PREP_ASC_FOR_FULL_IFO got lots of IFO_OUT call-outs, similar to what Tony had noticed (73753)
18:29 Reached NOMINAL_LOW_NOISE
18:49 Observing

Start Time System Name Location Lazer_Haz Task Time End
15:28 FAC Tyler, Randy, Eric EX/EY n Chillers 16:44
15:36 FAC Karen OptLab,VacPrep n Tech clean 16:00
16:13 FAC Karen WS n Tech clean 16:38
16:39 VAC Travis LVEA n Checking ion pump 16:47
18:21 FAC Cindi MechRoom n Tech clean 19:51
20:09 VAC Travis MY n Looking for tools 20:51
20:36 EE Fil MY n Moving things to/from 21:01
H1 General
anthony.sanchez@LIGO.ORG - posted 16:07, Thursday 26 October 2023 (73764)
Thursday Ops Eve Shift Start

TITLE: 10/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 163Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:
IFO is currently Locked for 4 .5 hours and is no longer in earthquake mode.

H1 ISC (ISC, TCS)
vladimir.bossilkov@LIGO.ORG - posted 15:51, Thursday 26 October 2023 (73763)
80.3 kHz PI margin for RH adjustments in the X-arm

Based on the unexpectedly high gain of this PI (~260), if LHO is in a position where they wish to avoid inducing this PI at any cost, without requiring to have active actuation runnning to damp it, they have some breathing room in the settings of the X-arm ring heaters (RHs) before the mode-spacing crosses the threshold of parametric gain, R > 1. Here I give a rough estimate on the magnitude these RH settings can be, whilst remaining in this "safe space", based on Diopter per Watt estimates here.

Presently modespacing for the relevant interacting mode in a well thermalised state sits at (see black curves in figures of this aLog): 5240 Hz in the 0'th FSR, and 80287 Hz in the 2'nd FSR.
To reach the condition for R > 1, modespacing can go up as high as 5244.5 Hz in the 0'th FSR, giving us 4.5 Hz of breathing room right now.

3 basic scenarios to reach that threshold:

Effective PI damping actuation would relax this further.

H1 ISC
vladimir.bossilkov@LIGO.ORG - posted 14:45, Thursday 26 October 2023 (73761)
80.3 kHz PI Gain

The last time LHO lost lock to this PI was 22nd May 2023. I fetched tape data to derive the observed paramertic gain (R_obs) for that event, and fit exponentials to periods of exponential growth, to get the time constants:

I will take the conservative estimate and take R_obs = 16.

Given an estimate of the mechanical Q factor of 1.7 million, all I need to know is what was the difference between the optical mode frequency and the mechanical mode itself, in order to deduce the underlying Parametric Gain (R0), which would occur at an exact frequency match of these parameters.
To fetch these paramters, I fetched spectra of the OMC_DCPD_SUM (to see optical mode spacing) and MODE28_BP_IN1 (to see exact PI frequency which is demodulated at 80000 Hz). I use the frequency mapping I established earlier for the optical mode to project what the frequency is 2 FRSs away:

Now I take these juicy details and I crank the algebraic handle with this simple script.

R0 = 260

Images attached to this report
Non-image files attached to this report
H1 AOS (DetChar)
adrian.helmling-cornell@LIGO.ORG - posted 13:00, Thursday 26 October 2023 (73760)
DQ shift report for 10/16-10/22

Highlights:

All in all, a pretty quiet week, data qualiity wise. Full shift report here: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20231016

H1 General (Lockloss)
oli.patane@LIGO.ORG - posted 09:40, Thursday 26 October 2023 - last comment - 11:50, Thursday 26 October 2023(73756)
Lockloss

Lockloss @ 16:38 UTC due to earthquake

Holding in DOWN for a bit while the ground motion settles.

Comments related to this report
oli.patane@LIGO.ORG - 10:12, Thursday 26 October 2023 (73757)

16:53 Started relocking

oli.patane@LIGO.ORG - 11:50, Thursday 26 October 2023 (73759)

18:49UTC Observing

H1 AWC (AWC, CDS, DetChar-Request, ISC)
keita.kawabe@LIGO.ORG - posted 17:20, Tuesday 24 October 2023 - last comment - 10:51, Wednesday 08 November 2023(73706)
OM2 thermistor sensor voltage supplies are oscillating (Fil, Fernando, Keita)

Summary:

It seems that the supply voltage for thermistors is oscillating, the frequency depends on whether or not the supply is loaded with thermistors (830mHz open to 1.66Hz fully connected to the in-chamber thermistors), the amplitude of the oscillation jumps seemingly randomly, and this is also happening for the unused Beckhoff module for the yet-to-be-installed second T-SAMS unit, all measured at the back of the Beckhoff chassis. (Can't we measure this from Beckhoff itself, without me going to the floor?)

Fil and Fernando quickly set up the same Beckhoff module in the lab and didn't observe this. Could we swap or maybe restart the modules in the chassis?

As of now, Beckhoff cable is disconnected from the back of the heater driver chassis. (I'm applying DetChar-Request tag just so people know, but we're just changing from one no-comb configuration to the other.)

Detaisls:

Since the past findings about OM2 and 1.66Hz comb (alogs 73367, 73233, 72967 72241 and 72061) didn't make sense, I went to the floor and remeasured the comb in the Beckhoff heater output (which goes to the heater driver input) as well as thermistor pins in the back of the heater driver chassis while Beckhoff connection was intact.

Turns out that all of these things share the same frequency but the voltage across thermistor pins was ~3 orders of magnitude larger than Beckhoff heater driver output pins (pin 9 and 19) (the latter were referenced from the driver board ground as it's common mode for both pins). I used a scope on battery and the thermistor voltage was like roughly 1Vpp 1.66Hz rectangular wave (1st pic). Yellow is the voltage across pin10 and 23 (across thermistor 1), blue is pin9 and 22 (thermistor 2) of the DB25 at the back of the driver chassis when the Beckhoff cable was still connected.  Voltage difference seemed to have come from the temperature difference of the thermistors (I disconnected the Beckhoff cable and measured the thermistor 1 and 2 resistance incl. cables to be 7.41k and 4.08k, respectively). When I disconnected the cable from the chassis and just measured the pin10-23 and pin9-22 voltage coming from the cable (picture 2), they were both about 1.2V pp. This is supposed to be the source voltage for thermisters. The frequency slowed down by about a factor of 2 (832mHz) when the thermistors were disconnected.

For your convenience, below is a table of which pins are what (see e.g. E1100530 and D2000212). Note that thermistors themselves only have two pins, therefore supply and readback pins are bundled together in chamber as shown. Supply is presumably a reference voltage supplied through a reference resistor.

which thermistor? DB25 pin Beckhoff in chamber
1 10 Temperature Supply 1A+ thermistor 1 pin 1
(10&12 bundled together in chamber)
12 Temperature Readback 1A+
23 Temperature Supply 1A- thermistor 1 pin 2
(23&25 bundled together in chamber)
25 Temperature Readback 1A-
2 9 Temperature Supply 2A+ thermistor 2 pin 1
(9&11 bundled together in chamber)
11 Temperature Readback 2A+
22 Temperature Supply 2A- thermistor 2 pin 2
(22&24 bundled together in chamber)
24 Temperature Readback 2A-

 

Went to the CER, disconnected the cable from the back of the Beckhoff chassis and did the same measurement. Frequency didn't change but the amplitude was much smaller (~280mVpp instead of 1.2Vpp) for a while, but suddenly the amplitude of the thermistor 1 supply changed back to 1.2V (pic 3). Nuts. When the beckhoff cable was reconnected (and the connection to in-chamber thermistor was restored) the frequency went back to 1.66Hz (picture 4).

Picture 5 shows pin 10-23 (thermistor 1 supply) and pin12-25 (thermistor 1 readback, which is not connected to anything). Picture 6 is the same thing but for the unused Beckhoff unit for the second T-SAMS. It's strange that the same thing is happening in two independent units. Picture 7 is the thermistor 1 supply and pin 6-19 (voltage output for the heater driver). It really seems that this is a problem of the supply voltage.

I checked the 24V power strip for the Beckhoff chassis but it was good (pic 8 and 9).

Fil and Fernando set up EL3692, which is the Beckhoff unit used for Thermistors. They didn't observe this oscillation behavior.

I wanted to do some injections into thermistors to see how this couples to DARM but didn't have time.

Images attached to this report
Comments related to this report
daniel.sigg@LIGO.ORG - 00:46, Thursday 26 October 2023 (73754)

Well, this seems to be a feature! The EL3692 terminal has 2 measurement inputs for resistance but only one ADC and current source. In alternating mode it switches between the 2 channels continuously. From the scope traces, the measurement time per channel looks like about ~400 ms. This is consistent with the data sheet. We expect about ~0.16 mA of current in the range between 10 Ω and 10 kΩ.

fernando.mera@LIGO.ORG - 16:07, Friday 27 October 2023 (73782)
Fil, Marc, Keita, Daniel, Fernando

Fil and I set a test bank in the lab and verified the square pulses found are part of the features of the EL3692 terminal when both channel reading is set. Then we implemented a configuration using a continuous reading over the channel 1 and one shot reading over the channel 2 (under request by a raising edge on the Start Conversion input in the module, that will be never used). 

Finally the scopes show the continuous signal in the channel 1 with some minor noise component that is still in analysis (basically 60Hz and 12Hz) however this virtually solves the main problem with the square pulses. One ECR should be open to double the quantity of EL3692 in the places where reading in both channels are necessary since just one channel provides continuous reading at this point. 

Note: the autorange feature was left intact so the new configuration will not cause any limitation in the resistor range to be measured and also will keep the same PDO to not break the Epics configuration.

Attached: scopes and the EL3692, configuration applied to the EL3962 and spectral analysis for the noise signals.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:00, Tuesday 31 October 2023 (73886)
WP 11501

Daniel Keita Fernando

Today we configured the one channel reading on the two Beckhoff EL3692 modules for the PSL IO Chassis. After restarting the system Keita Daniel and I were to the rack to scope the thermistor channels we verified the absence of the square pulses reported initially. Finally the module R20 CH2 was rewired to R21 CH1 and configured in the system accordingly. Attached the picture including the R20 and R21 EL3692 modules for reference.
Images attached to this comment
fernando.mera@LIGO.ORG - 17:17, Thursday 02 November 2023 (73940)
After having a solution for the issue duplicating the number of EL3692 modules, and ECR and FRS ticket have been created:

ECR:
https://dcc.ligo.org/E2300408-v1

FRS ticket:
https://services1.ligo-la.caltech.edu/FRS/show_bug.cgi?id=29563
fernando.mera@LIGO.ORG - 10:51, Wednesday 08 November 2023 (74092)

Daniel, Fernando

As part of the WP11506  a new configuration was loaded into the Beckhoff system which includes the 1-channel continuos reading for the EL3692 terminals. The change included the rewiring in the TCS Corner EtherCAT chassis TSAMS consisting of connecting the second channel in the EL3692 (R20) to the first channel in the terminal EL3692 (R21) to match the TwinCAT configuration added. The disconnected wires are not currently connected ot any thermistor on the floor.

Displaying reports 12721-12740 of 84342.Go to page Start 633 634 635 636 637 638 639 640 641 End