Displaying reports 12741-12760 of 84342.Go to page Start 634 635 636 637 638 639 640 641 642 End
Reports until 10:24, Thursday 26 October 2023
LHO VE
david.barker@LIGO.ORG - posted 10:24, Thursday 26 October 2023 (73758)
Thu CP1 Fill, new trip temperatures

Thu Oct 26 10:14:54 2023 INFO: Fill completed in 14min 49secs

Travis confirmed a good fill curbside.

Note that now the outside temperatures have dropped (and therefore also the thermocouple reference junctions) the TCs no longer drop down to -200C.

I increased the trip temperature from their summer setting of -130C to their winter setting of -100C this morning. The TCs min temps for today's fill were TCA=-125C, TCB=-119C.

The plot y-axis marker has been set to the new trip temp.

Images attached to this report
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 General
oli.patane@LIGO.ORG - posted 08:00, Thursday 26 October 2023 (73755)
Ops DAY Shift Start

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 155Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

We've been Locked for 2.5 hours and are Observing

H1 General
anthony.sanchez@LIGO.ORG - posted 00:08, Thursday 26 October 2023 (73753)
Wednesday Ops Eve Shift End

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 161Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
Since the Mid shift report relocking from that incoming earthquake went well. BUT

04:04 UTC: 
IFO OUT saturations happned again During Prep_ASC_FOR_FULL_IFO. And usually that does not tend to happen. Thats the second lock in a row that this has happened, in the same ISC_LOCK State. So maybe it's a coinicidense because both locks happened on the same night, after the same initial alignment. I'd be interested in seeing if this happens again after another initial alignment.

3:48 UTC Lockloss
4:44 UTC Nominal_LOW_NOISE reached
5:05 UTC OBSERVING reached
6:02 UTC Incoming 5.5M Earthquake from Timor-Leste
6:57 UTC Seismic to CALM, we made it.

Current H1 Status: Locked in NOMINAL_LOW_NOISE and OBSERVING.

LOG:
None

H1 General (Lockloss)
anthony.sanchez@LIGO.ORG - posted 20:55, Wednesday 25 October 2023 (73752)
Lockloss 1382327323

Lockloss from 5.4M Earthquake from Tonga from ISC_LOCK STATE : INJECT SQUEEZING.
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1382327323

Images attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 20:35, Wednesday 25 October 2023 (73751)
Wednesday Mid Eve shift report.

Aquired H1 while it was in comissioning and had been locked for 20.5 hrs.
Comissioning finished at 23:32 UTC.


00:29 UTC Dropped out of observing and back in comissioning due to: 
CAMERA_SERVO Guardian log has the following message:

USERMSG 0: ASC-CAM_PIT1_INMON is stuck! Going back to ADS
2023-10-26_00:34:24.014687Z
CAMERA_SERVO [TURN_CAMERA_SERVO_ON.run]
USERMSG 1: ASC-CAM_YAW1_INMON is stuck! Going back to ADS

Naioki Patrick and I got on to team speak to try and restart the camera service on h1digivideo2.
At first using the monit system h1digivideo2:2812/h1cam26
Which didn't seem to be benificial.
And again by opening a ssh console to h1digivideo2 and manually restarting it.
And also trying to Kill the process using top commands.
We are now trying to powercycle the camera via removal of POE on its port
Contacting Dave  to power cycle switch sw-lvea-aux port 0/35

Lockloss at 01:51 UTC https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=73750

Dave was able to get the camera to reboot and I can now see a black camera image instead of blue screen.  Link to his alog.

Relocking had ALS-Y arm alignment issues. Once that was taken care of by green arms manual and touchin up Y arm, I ended up in Check Mich Fringes twice and couldn't get DRMI locked.
So I started an Initial_Alignment. Which completed at 3:03 UTC.

3:19 UTC During Prep_ASC_FOR_FULL_IFO, there were saturations signaled by verbal's IFO out call out.
I dont usually hear saturations during this stage of locking. So I made a note of it.

3:22 UTC Incoming 5.4 Earthquake from Tonga...

Current status: Relocking at ISC_LOCK_STATE: MOVE_SPOTS.

 

 

H1 General (Lockloss)
anthony.sanchez@LIGO.ORG - posted 20:27, Wednesday 25 October 2023 (73750)
Lockloss 1382320306

Lockloss from NOMINAL_LOW_NOISE
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1382320306
This happened while Dave , Patrick , And Nioki were trying to resolve the camera issue that was preventing H! from going into OBSERVING.
We did get a small Earthquake roll through at the time, though I'm not sure if the earthquake was what took us down, as the earthquake was very small and wind was mildly elevated as well.
 

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 19:11, Wednesday 25 October 2023 (73749)
h1cam26 (BS) stopped responding at 17:28, recovered by power cycling the camera

Tony, Dave:

The EPICS channels for cam26 froze at their last values from 17:28 PDT onwards this evening. The camera was recovered by:

1. power cycling the camera via its POE port on sw-lvea-aux (port 0/35)

2. attempting to kill the camera server process on h1digivideo2 using monit, and when that did not work I killed the process by hand as root.

3. started the camera server process via monit, which did work.

Unfortunately H1 had lost lock, so I can only confirm the pixel sum channel went from its stuck value to zero. We will verify the camera is working when we get light back on it.

H1 SQZ
camilla.compton@LIGO.ORG - posted 17:39, Wednesday 25 October 2023 - last comment - 15:00, Monday 20 November 2023(73747)
NLG Sweep with IFO

Sheila, Naoki, Camilla

We took FDS, Anti-SQZ and Mean SQZ data at different NLGs: 14, 17, 43, 82 and 123. We think we see evidence of frequency noise. We see less squeezing at high NLGs: around 4.5dB of SQZ at NLG < 43.1 but at NLG 81.9 and 122.8, squeezing at 1kHz reduced to 3.6 and 3.1dB. Attached Plot.

Each time we optimized SQZ angle around 1kHz. Because of this, the low frequency increased noise at high NLGs could be due to incorrect rotation, rather than phase noise. 

 
Time (UTC)
Demod phase
DTT ref#
NLG
SQZ dB at 900Hz
FDS
21:23:40-21:26:00
152.25
3
13.9
-4.3
FDAS
21:27:30- 21:32:30
228.10
6
13.9
15.2
Mean
21:33:47- 21:38:00
-
7
13.9
12.7
No SQZ
21:40:00 -21:44:50
-
0
-
 
FDS (not optimized) 
21:51:20 -21:54:30
164.57
Deleted
43.1
-4
FDAS (Left ASC off) 
21:56:00 -21:59:45
226.2
5
43.1
19.1
FDS (retake)
22:03:00 -22:06:13
167.42
4
43.1
-4.3
Mean
22:06:45 -22:09:52
-
8
43.1
16.9
FDS
22:37:50- 22:41:00
172.16
9
122.8
-3.1
FDAS
22:42:43-22:45:45
217.67
10
122.8
24.7
Mean
22:46:35 - 22:49:55
-
11
122.8
 
FDS
22:57:30- 22:59:40
169.31
12
81.9
-3.6
FDAS
23:01:20 - 23:02:55
219.56
13
81.9
22.7
Mean sqz
23:03:26 - 23:05:45
-
14
81.9
20
FDS (left IFO here)
23:19:38
154.14
15
17.1
-4.5

Data saved in /camilla.compton/Documents/sqz/templates/dtt/20231025_GDS_CALIB_STRAIN.xml

Time (UTC)
Unamplified OPO OPO_IR_PD_LF
(Scan Seed)
 
OPO trans (uW)
OPO Temp (degC)
Amplified (maxium) H1:OPO_IR_PD_LF
(Scan OPO PZT)
NLG 
(Amplified / (Unamplified Peak Max - Unamplified Dark Offset))
Peak Maximum Dark Offset
21:15
786e-6
-16e-6
80.54 uW
31.446
0.0112
13.9
21:44
 
 
100.52
31.414
0.0346
43.1
22:17
 
 
120.56
31.402
0.160
199.5 (SQZ loops went unstable) 
22:30
 
 
110.5
31.407
0.06617
82 (didn't use) 
22:36
 
 
115.46
31.405
0.09853
122.8
22:52
 
 
110.5
31.407
0.0657
81.9
22:09
769e-6
-15e-6
80.5
31.424
0.0137
17.1

Vicky and Naoki did an NLG sweep on the Homodyne in 73562.

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

Edits to NLG table in above alog: Last measurement was at 22:09 23:09 UTC. For measuring unamplified we scanned OPO PZT and for amplified we scanned SEED PZT. 

Setup for each SQZ Measurement:

For FDS: Took SQZ_MANAGER guardian to FREQ_DEP_SQZ and rotate SQZ angle to give best squeezing at 900Hz. 
For ASQZ: Turn off IFO ASC and FC ASC, rotate SQZ angle to give worst squeezing at 900Hz. 
For Mean SQZ: Took SQZ_MANAGER guardian to FREQ_INDEP_SQZ and SQZ_LO_LR to DOWN. 
 
To measure unampilifed signal for NLG:
  • SQZ_MANAGER to NO_SQUEEZING and SQZ_OPO to DOWN
  • Scan the OPO PZT with PZT_1 Enable, Use trigger: No (via SQZ Overview > HAM7 > OPO IR > OPO PZT1)
  • Should see mode scan on H1: SQZ-OPO_IR_PD_LF_OUT. Measure the highest peak as "Unamplified" and the zero level as "Unamplified Dark Offset".
  • Only need to this once (we did at start and end)
To change to another NLG:
  • SQZ_MANAGER to NO_SQUEEZING
  • Change opo_grTrans_setpoint_uW in sqzparams.py (higher power = higher NLG)
  • Reload SQZ_OPO
  • SQZ_OPO to LOCKED_CLF_DUAL_NO_ISS  then LOCKED_CLF_DUAL
    • Check it locks with correct OPO TRANS power, may need to adjust SHG power with waveplate
  • SQZ_OPO to LOCKED_SEED_NLG
  • SQZ_CLF to DOWN
  • Adjust temperature to maximize SQZ-OPO_IR_PD_LF_OUT (with SEED_PZT scanning enabled)
  • Record SQZ-OPO_IR_PD_LF_OUT maximum it is "Amplified" signal.
    • Can now calculate NLG = Amplified / (Unamplified - Unamplified Dark Offset).
  • SQZ_MANAGER to SQZ_READY_IFO (with swap back from SEED to CLF)
victoriaa.xu@LIGO.ORG - 15:00, Monday 20 November 2023 (74318)

Attached are fits of squeezing loss, phase noise, and technical noise to this NLG sweep on DARM: we can infer 25-30% total SQZ losses, ~25 mrad rms phase noise, with technical noise almost -12 dB below shot noise.

Losses are tracked in the SQZ wiki and gsheet. Of the 30% total inferred loss, we expect 20%: that is 7.5% injection loss, and 13.7% readout loss.

Remaining ~10% mystery loss is compatible with mode-mismatch: in sqz-omc single bounce mode scans, LHO:73696, we estimate 8-15% mismatch, and we observe the frequency-dependence of the mismatch as we vary squeezer beam profile using PSAMS: 73400, 73621.

In the fits, [loss, phase noise, technical noise] are fit to the measured SQZ and Anti-SQZ, given the measured NLG, using equations from the aoki paper. "Loss from mean sqz" is the calculated loss from the measured NLG and measured mean-sqz dB; it is not a fit, but depends on the calibration from NLG to generated SQZ dB.

Some summary slides here show the progression of our loss hunting, which are so far lining up with Sheila's projections from 73395.

Images attached to this comment
Non-image files attached to this comment
H1 SUS
anthony.sanchez@LIGO.ORG - posted 17:30, Wednesday 25 October 2023 (73748)
In Lock Charge Measurement

Famis 26063

In Lock charge measurements ran yesterday, and everything went smoothly up until the the line python3 coeffiencentplots.py . Ryan has an ALOG 73432 which Camilla pointed me to, This worked out well!
 

Images attached to this report
H1 ISC
vladimir.bossilkov@LIGO.ORG - posted 16:29, Wednesday 25 October 2023 (73746)
80.3 kHz PI Mechanical Q

I made measurements of ringdown constants of the of this mechanical mode to get a measurement of the Q factor.

The measurements were admittendly quite ratty, and often the PLL would lock to some oscillation that it itself creates, giving many occasions where the oscillation vanishes immidiately as the injectoin ends.
This is largely due to the mechancial mode not being significantly larger than the noisefloor, causing PLL to lock to garbage.

Of the times I was able to excite the mechanical mode itself, I measured Q-factors of through the locked PLL amplitude signal:

So the Q-factor is approximately 1.7 million.

At the time of measurement, the frequency difference between the optical mode and the mechanical mode was 14.55 Hz.
Given the optical linewidth is roughly 1 Hz, this is "far" enough away to neglect optomechanical coupling and trust this as a true estimate of mechanical Q.

Images attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 16:08, Wednesday 25 October 2023 (73742)
Wednesday Eve Shift Start

TITLE: 10/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 11mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.20 μm/s 
QUICK SUMMARY: 
H1 is in NOMINAL_LOW_NOISE, but ....
Comissioning is still in progress for a few more minutes so the SQueeZrs can do some Anti-SQZin with different Non Linear Gains(NLG). 

H1 General
oli.patane@LIGO.ORG - posted 16:04, Wednesday 25 October 2023 (73743)
Ops DAY Shift End

TITLE: 10/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Now Locked for 20.5 hours. Had commissioning today starting at 19:07UTC and is ongoing but wrapping up soon.
LOG:

15:00UTC Detector Locked for 12.5hours

--Commissioning Start--
19:07 Out of Observing for Commissioning
19:09 To NLN_CAL_MEAS for Calibration measurements
    - bb measurements: 1382296233 - 1382296559
    - simulines measurements: 1382296585 - 1382297917
19:39 Back to NOMINAL_LOW_NOISE
19:44 - 20:05 DARM Boost
20:08 COMM Gain
    12: 20:08:17 - 20:10:17
     6: 20:10:29 - 20:12:29
    12: 20:12:44 - 20:14:44
     6: 20:14:58 - 20:16:58
    
20:20 - PRESENT SQZ ASQZ w/different NLG      

Start Time System Name Location Lazer_Haz Task Time End
15:04 FAC Karen OpticLab/VacPrep n Tech clean 15:32
15:09 FAC Randy EY/EX n Moving boxes from EY to EX 17:09
15:32 FAC Karen MY n Tech clean 16:48
19:10 CAL Louis, Oli CR n Running calibration 19:38
19:49 OPT Jason OpticsLab y(local) Oplev work 20:15
19:44 ISC Camilla, Sheila CR n DARM Boost 20:06
20:07 ISC Oli CR n CARM gain 20:17
19:10 PI Vlad, Naoki CR n 80k PI work 21:34
20:29 FAC Eric, Tyler MX n Looking at air handler 21:59
20:20 SQZ Sheila, Camilla CR n SQZ ASQZ w/different NLG ongoing
21:23 OPT Jason, Austin Optics Lab n Oplevs 22:37
H1 CAL
oli.patane@LIGO.ORG - posted 14:26, Wednesday 25 October 2023 (73741)
Calibration BB and Simulines Measurements 2023-10-25

Ran a BB measurement followed by Simulines:

    - bb measurements: 1382296233 - 1382296559 (2023-10-25 19:10:15 - 19:15:41)
    - simulines measurements: 1382296585 - 1382297917 (2023-10-25 19:16:09 - 19:38:19)

Output files:

BB:
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20231025T191015Z.xml

Simulines:
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20231025T191609Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20231025T191609Z.hdf5

Images attached to this report
H1 ISC
gabriele.vajente@LIGO.ORG - posted 13:52, Wednesday 25 October 2023 - last comment - 16:40, Wednesday 25 October 2023(73740)
Improving DARM RMS with resonant gains

Today we tested the effect on DARM of additional resonant gains at 2.8 and 3.4 Hz, as described in 73698.

DARM RMS was reduced as expected from 1.6e-9 to 1.2e-9.

Looking at DARM spectrograms, there is no evident difference in the level of non-stationary noise.

Comapring the DARM PSD during two times, there seems to be a small improvement, but that might be a fluctuation.

In summary: the resonant gains improve the DARM RMS, but we don't see a clear improvement in noise; they don't hurt though 

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 16:40, Wednesday 25 October 2023 (73745)

I've created a low frequency boost that generally gives more gain at low freq, rather than just having the resGs. I turned it on starting at 23:11:00 UTC.  Until 23:19:38, the squeezers were working.  Then around 23:26:00 I changed the CARM gain.  So, maybe this isn't such great 'quiet time' to evaluate whether we've improved our nonstationarity, but it certainly does seem fine, and it also does nicely reduce the low frequency DARM_IN1 and its RMS.  The filter was back off around 23:31:00 UTC so we could go back to Obsering.

In the first plot, the blue filter is the one that Gabriele had created, and we tried early in the commissioning period today.  Red is my new proposed filter.

In the second plot, the blue is DARM_IN1 under nominal circumstances (so, no resG or boost), and red is with my version of the boost filter.  As noted in my 'timeline' above, there isn't really a lot of good quiet time to evaluate its effect on the nonstationarity, but the significant reduction in RMS seems like a good thing.  If we want to leave this filter on, Louis will need to do some work to prepare the calibration pipeline, and we'll need to restart the GDS pipeline during the same commissioning window that we turn on the new boost.

EDIT: please disregard the y-axis label on the DARM_IN1 specra plot.  I don't think that should be there.

Images attached to this comment
H1 ISC
oli.patane@LIGO.ORG - posted 13:27, Wednesday 25 October 2023 - last comment - 16:26, Wednesday 25 October 2023(73738)
Alternating CARM Gain

In a follow-up to what TJ did yesterday(73685), I alternated the CARM gains (H1:LSC-REFL_SERVO_IN{1, 2}GAIN) between 6 (what it was nominally at) and 12 every two minutes.

Times when we were at each gain setting (in UTC):

   12: 20:08:17 - 20:10:17
    6: 20:10:29 - 20:12:29
   12: 20:12:44 - 20:14:44
    6: 20:14:58 - 20:16:58

Attached is an ndscope over this timeframe looking at the CARM gain and SQZ BLRMS channels (same as the channels that TJ and Camilla had been looking at yesterday(73682)).

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 13:50, Wednesday 25 October 2023 (73739)

Attached is our very high frequency monitor of the DCPDs. (Since this channel is not saved, I also upload the DTT file).

The red / pink traces are at our nominal CARM gains of 6dB on each slider (H1:LSC-REFL_SERVO_IN1GAIN and IN2GAIN), and the blue / teal traces are the higher values of 12dB on each slider.  All data is 10 avgs at 1 Hz BW, 25th Oct 2023.  Times of the data are in the legend for each trace. 

It seems that increasing the CARM gain is beneficial to our noise between 6 kHz to about 25 kHz.  From about 25 kHz to a little above 100 kHz it increase our noise a bit.  Above 100 kHz we're limited by some other noise, and so not seeing the effect of frequency noise.

I think it seems fine to leave CARM with the higher gain.

Images attached to this comment
Non-image files attached to this comment
jenne.driggers@LIGO.ORG - 16:26, Wednesday 25 October 2023 (73744)

I've just modified LASER_NOISE_SUPRESSION to increase the sliders to 12dB (it used to increase them up to the previous nominal of 6dB at the end of the state).  I've just increased the sliders before we go back to Observe, so we'll have lower frequency noise for all our upcoming locks.

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 12741-12760 of 84342.Go to page Start 634 635 636 637 638 639 640 641 642 End