This could be a bad readback, or real, we are not sure. The signal should be 23dB, but the readback is showing 16.8dB on NDSCOPE and has been trending down for a while, it is throwing an error flag in beckhoff. This signal is located in ISC-R1 slot U16 on the left side. The LO signal is 9MHz and is fed through a delay line chassis, there are also baluns, cabling, etc... We were not able to determine the source of the readback error before noon, so this will have to wait until a maintenance window.
M. Pirello, F. Mera, D. Sigg
This morning I flipped the sign (after talking to the Operator) of the ETMX ESD lock bias voltage from -450V to +450V for 3hrs to reduce the charge build up in the optic.
After 3hrs I reversed the sign and set it to nominal.
ndscope trends are attached below.
Per WP11795 I looked at the EX Accelerometer Power Conditioner based on what Robert said about one of the channels not functioning. Visually, there is no power on channel 8, the power good light is off. We moved the signal to channel 9 and will go back to fix channel 8 when time permits. This channel was working when the chassis was installed.
Lights off, paging system unplugged, WAP stayed off. Some unused extension cords unplugged, genie lift charging block unplugged. Turned off SQZ laptop and monitor.
All else looked good, followed T1500386
WP 11799. Patrick T., Ryan S. The PSL Beckhoff PLC has been updated to match the changes made at LLO to add a watchdog channel. This is the code from 'TwinCAT Projekt_LIGO_240124.zip' in https://dcc.ligo.org/E2100235. The now running version is in git at https://git.ligo.org/cds/ifo/beckhoff/lho-psl and commit 9b6ad86cb26660b136242b334bd4831a683f1c5b. It appears there was also a change to fix a bug where toggling the noise eater tripped the NPRO. Ryan verified that this now appears to be fixed. I also removed the ${IFO}.PSL.LASER.MAIN.SHUTTER alias of the bEnable_Shutter2 variable, which according to LLO is not being used. The channel was not being exported to EPICS. There were two minor issues. The first was that the version of a couple of the terminals found from a scan of the EtherCAT bus did not match what was in the IO configuration, and this appeared to be the cause of an INIT error for a couple of terminals (presumably those) when the system was put into run mode. This was fixed by changing the IO configured versions to match the scanned versions. The other was that I forgot to comment out the inversion of the signal from laser PD1, which was not realized until we started everything and were wondering why the power was reading as negative for that PD. I fixed that in a new commit and restarted the code again.
The new pump diode watchdog will trip off the system in the event any of the diodes drops below a set percentage, much like the already existing watchdogs on the output of the NPRO and both amplifiers. I've set this trip level at 80% and enabled the WD. I also added an indicator to the PSL overview medm screen showing the WD is enabled (H1:PSL-LASER_PDWD).
Tue Apr 02 10:06:37 2024 INFO: Fill completed in 6min 34secs
Jordan confirmed a good fill curbside
Picket Fence was updated. The only major change is that one channel "HLID" was dropped for another, "HWUT".
We have an upgrade slated today for the PSL Beckhoff computer; I captured a screenshot of the settings table in case it gets overwritten and am posting it here for posterity.
Camilla, Vicky
Screenshot of how we found the SQZ_FC and SQZ_OPO this AM. Two separate issues.
Only to-do might be fixing the SQZ_FC issue in FIND_IR. I hope the SQZ_OPO_LR issue is solved, but we will watch out for it.
More description of the issues from this morning/last night and how to fix it:
From it being STALLED and MANAGED, I took SQZ_OPO_LR to AUTO. This worked to un-stall it, and let it continue locking. If the scan is fixed, this should be enough to solve the problem.
--> Not sure why OPO guardian was "STALLED" when it jumped to "IDLE" state, but I think this is related to the guardian "jump" to IDLE. I'm not sure if we even want to fix this -- leaving the SQZ_OPO_LR guardian in STALLED was probably the correct move, otherwise it would have spent hours scanning the PZT without finding co-resonance. Better to fix issues with not finding co-resonance, maybe not much to do here.
OPO couldn't lock on co-resonance b/c that was at 104V, but PZT1 was only scanning up until 100V -- I changed the scan offset.
OPO did not find co-resonance within its scan range, then it timed out, jumped into IDLE, and the guardian STALLED. See sqz locking screenshot -- increasing the scan range let it find co-resonance at 104V, and then SQZ_MANAGER easily went back up to FDS.
I increased H1:SQZ-OPO_PZT_1_OFFSET from 0V to 15V, and saved this 15V offset in SDF. We cannot increase H1:SQZ-OPO_PZT_1_SCAN_STOP above 100V in slowcontrols, so we have to increase the scan offset to get the PZT there.
Note, back when OPO_PZT2 was at 0V (before 76688), I think the OPO would often find co-resonance between 100-110 V during O4a.
Based on a previous opo co-resonance issue, 76642 seemed to want to the scan starting around ~50V. Today's issue shows we want to scan beyond 105V, probably up to 110V or even 115V (the max). Based on OPO cavity scans (e.g. screenshot from LHO:75285), I think OPO PZT1 is not super effective (in terms of um/V scanning) below 50V or so.
Let's try scanning from 55V - 115V to guarentee we find co-resonance. This is how it's currently set. This corresponds to the first screenshot, where H1:SQZ-OPO_PZT_1_OFFSET = 15V (saved in SDF), H1:SQZ-OPO_PZT_1_SCAN_START = 40, H1:SQZ-OPO_PZT_1_SCAN_START = 100V.
Conveniently there are some nicer glitch-free NO SQZ and FDS times:
NO SQZ: 1396084368 - 1396087119 (~46 min)
FDS: 1396072807 - 1396075570 (~46 min)
Eric, Camila
TITLE: 04/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 5mph Gusts, 3mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.25 μm/s
QUICK SUMMARY:
H1 lost lock 1458 (Camilla thinks the in-lock charge measurement might have run...but caused the lockloss due to New-DARM.).
MAINTENANCE has begun!
Paused TCS_ITM_CO2_PWR guardians so that when the IFO unlocks the CO2s will stay on so we can take absorption measurements of the ITMs using HWS (need ITMs and SR2 to stay aligned for 1 hour after lockloss).
Un-paused at 16:01UTC, CO2s are back to 0W output.
Last done in 71400.
Using Dan's /ligo/gitcommon/labutils/hws_absorption_fit/april2024/fit_absprtion_v2.py with lockloss time 1396105132, edited P_y and P_x values to adjust the fit and old and new origin values (ours are correct, checked in 76385).
This is an interesting data set as you can see when the CO2's were turned back to 0W after an hour, ndscope attached.
The IFO had only been at full power for ~1hour, this might explain the lower values than previously measured. Plot of fits attached. Fit of ITMY isn't very good. We could try using Cao's clean spherical power channels (single pass) or his 66155 fitting code. LLO also uses a different method LLO69930.
ITMX: 155mW absorbed = 430ppb (155mW / 361kW)
ITMY: 120mW absorbed = 330ppb (120mW / 361kW)
April 2022 (62468, 62782) | Nov 2022 (66036) | April 2023 (71400) | April 2024 | |
ITMX | 430ppb | 490ppb | 475ppb | 430ppb |
ITMY | 370ppb | 385ppb | 375ppb | 330ppb |
Workstations were updated and rebooted. This was an OS package update. No Conda packages were changed.
TITLE: 04/02 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: None
SHIFT SUMMARY:
IFO is in NLN and OBSERVING as of 23:00 UTC (8hr 36 min lock)
Nothing else of note
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
17:26 | OPS | LVEA | corner | YES | LVEA is Laser HAZARD !!!! Alog 76834 | 15:24 |
17:10 | FAC | Karen | Optics Lab | N | Tecnical Cleaning | 19:10 |
17:14 | CDS | Dave, Erik | Remote | N | Troubleshooting Dolphin issues | 19:14 |
20:55 | PCAL | Francisco | PCAL Lab | Yes | Taking Pictures | 21:13 |
23:03 | PEM | Robert | LVEA & EX | Yes | Shutting Down movers and shakers. | 23:37 |
23:07 | HWC | Jenne W | EY | N | Running the Arms and Checking out the Wildlife. | 00:07 |
23:15 | PCAL | Tony, Francisco | PCAL Lab | Local | Measurements | 00:29 |
23:38 | PEM | Robert | EX | N | Turning off injection amp | 23:58 |
Here are the highlights of my data quality shift report for the week of 3/25-3/31.
The full report can be found here: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20240325
IFO is in NLN and OBSERVING as of 23:00 UTC (4hr 45 min lock)
Secondary microseism is steadily decreasing.
J. Kissel ECR E1700387 IIET 9392 WP 11743 Here, this week we tackle the last of the suspension types that need suspension watchdog upgrades after having finished the End Station, Corner BSC, and HAM Triple suspensions this past month (LHO:76269, LHO:76545, and LHO:76712, respectively). WP 11797 While doing so, I'm also going to address the OMC ASC routing bugs found in the h1susifoout top-level model and its OMCS_MASTER library part (which used to live in h1susomc.mdl), and fix those too. As such, I'm doing a linear combination of the following changes: (1) In library part, removed sending watchdog out to top level (2) In library part, removed ODC parts from DAMP and LOCK banks (3) In library part, removed never-usered software shutter system (4) In library part, upgraded watchdog trigger generator to actual functional RMS (5) At top level, removed USER DACKILL (6) At top level, removed wires to ground (i.e. things never used) at top-level for WD, SHUTTER, and ODC outputs and SHUTTER input (7) At top level, cleaned up receiving of ISC ASC signals (see discussion in LHO:76842) Below is the list of models, their respective library parts, and the optics in that model that this impacts, followed by a call out of which of the above changes happened h1susim HSSS_MASTER IM1, IM2, IM3, IM4 (1), (2), (4), (5), (6) h1sushtts HSSS_FF_MASTER RM1, RM2 (1), (2), (3), (4), (6) h1susifoout OMCS_MASTER OMC (1), (2), (4), (5), (6), (7) OFIS_MASTER OFI (1), (2), (4), (6) HSSS_MASTER OM1, OM2, OM3 (1), (2), (4), (5), (6) h1sussqzout HSSS_MASTER ZM4, ZM5, ZM6 (1), (2), (4), (5), (6) h1sussqzin HDDS_MASTER ZM1, ZM3 (1), (4) OPOS_MASTER OPO (1), (2), (4), (6) HSSS_MASTER ZM2 (1), (2), (4), (5), (6) I've test-compiled all of the above listed models, so they're ready for re-compile, install, and restart of the front-end process tomorrow morning. All model changes have been committed to the userapps repo, either under /opt/rtcds/userapps/release/sus/h1/models/ /opt/rtcds/userapps/release/sus/common/models/ where the above mentioned models live. Screenshots describing the changes will be posted in the comments.
To address the removal of the transverse, vertical, and roll possibility and removing the "bad route" of the L, P, and Y OMC ASC control, I've done the following: (1) At the top level of the h1susifoout model, I've removed the ingestion of the T, V, and R IPCs. These still get send out into the dolphin IPC fabric from the h1omc model, because I didn't want to mess with that model. This means that if someone ever tries to use the OMC-ASC_DOF2TT matrix elements for "SUS V, SUS R or SUS T", the output of those elements of that matrix will go into nothing, essentially terminated. See before vs. after screenshots of the bottom left corner of the h1susifoout.mdl top level IPC area. (2) I've modified the OMCS_MASTER model to completely delete the "OMC_M1_ASC" bank, and removed all simulink inputs that landed in that bank from the top level h1susifoout model, to the top level of the OMCS_MASTER model, to the M1 stage of the OMCS_MASTER. See before vs. after area surrounding the call to the OMCS_MASTER.mdl in the h1susifoout.mdl top level model, And then drilling down into the OMCS_MASTER library part, see (i) before and after, the top level of the OMCS_MASTER library part. (ii) before vs. after, the M1 stage of the OMCS_MASTER library part. (3) Because the OMC ASC alignment input channels are stored inthe frames at 256, I had to update the DAQ channel list to switch to using the M1_LOCK banks rather than the M1_ASC banks. Note, there are therefore 3 less channels stored in the frames. This is seen in (2)(i) before vs. after cited above. (4) While there, I also deleted other never-used / impossible to use infrastructure that I installed early on in the 2010s because it was easier to copy and past than to customize. Now that we've gone through 4 observing runs, and there's no hardware to support it, I'm deleting the infrastructure to clean things up (lest it gets copied forward again by some future me). This includes (a) The "LKIN" parts, which are originally designed for demodulating an angular dither signal in order to diagonalize angular drive. But, there are only two OSEMs for both pitch and yaw on the OMCS's OSEM configuration, so the "coil balancing" methods, using the lock-in just will not work, since we can't drive "pringle." DELETED. (b) Many other SUS that have right-cylinders for optics, which have a center of rotational actuation that we're trying to align to a geometric rotational center in order to minimize angle to length coupling by "dithering." Sometimes you might hear the gains applied to the actuation basis called the "A2L" gains. For the OMCS, the beam is coming in at the edge of a square breadboard that's suspended beneath the actuators, of which again, there're only two. This, like the LKIN system, the DITHER system just doesn't make any physical sense. Because of the reasons outlined in (a) and (b), the inputs to the M1 stage of the OMCS_MASTER library part have always been terminated. That means that the inputs from ISC don't even appear at the top level. So, I've ripped both of these out. This is seen in (2)(ii) before vs. after cited above.
J. Kissel, D. Barker, P. Fritschel Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist). After making these changes, the impacted model and library have been committed to the userapps SVN under /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl rev 27374 /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl rev 27375
J. Kissel, [Corroborated by J. Wright and J. Driggers] WP 11797 While upgrading the OMCS_MASTER.mdl library part for the OMC Suspension (which now lives in the h1susifoout.mdl top-level model), I found two distressing things: (1) The OMC ASC signals that are sent from the h1omc.mdl model -- running at 2kHz -- are not anti-imaged at all before being sent to the OMC SUS DAC -- running at 16 kHz. So, we're sending unnecessary imaging noise to the SUS DAC. (2) The OMC ASC L, P, amd Y signals are being sent through a filter bank that does NOT past through the DRIVEALIN matrix, rendering 2019's attempt at diagonalization (LHO:47488) unused. These bugs have been long standing. I see it now as I touch the h1susifoout.mdl and the OMCS_MASTER library part for watchdog upgrades, but I'd previously identified the issue when - I was upgrading the front-end models for O4 (i.e. when the OMC SUS transitioned from the h1susomc.mdl to the h1susifoout.mdl) in 2021 (LHO:59652), and - When we were identifying which SUS models used the broken "TrueRMS" bloick -- there's a preceding note in the simulink model that suggests this has been around since 2015 or earlier. We can fix this tomorrow, with *only* a change to the h1susifoout.mdl and OMCS_MASTER.mdl models, and we're already doing that anyways for the SUS watchdog upgrade. Attached are several series of screenshots showing: (1) The signal path from the h1omc.mdl model where the OMC ASC control signals begin, to where they land in the OMC SUS driving in the EULER basis (again WITHOUT going through the DRIVEALIGN MATRIX) (2) MEDM Screens showing that in practice we only drive L, P, and Y (as one should for an ASC signal) and we don't use T, V, or R drive and likely never will. (3) The existing filters that will need to be copied over, and the DRIVEALIGN gain values that will likely need to be re-addressed -- since effectively we've NOT been using them. Note -- I checked on how this is done at LLO, and they *do* drive through the LOCK banks and DRIVALIGN banks (BUT they don't have any anti-imaging filters in pace either, even though their ISCINF FM1 banks are ON... whoops)... So, when we change the OMCS_MASTER library part, this won't affect them.
The ASC P and Y filters in play during nominal low noise are as follows: Bank Module Name Design String OMC_M1_ASC_P FM0 SUSinvert zpk([0.12+i*3.85;0.12-i*3.85;0.12+i*2.18;0.12-i*2.18],[0.3+i*1.75;0.3-i*1.75],1,"n") FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n") OMC_M1_ASC_Y FM0 FM1 zpk([0.033+i*0.54;0.033-i*0.54;0.25+i*3.95;0.25-i*3.95],[1.6;1.6],1,"n") FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n") These might be from 2015 -- the only aLOG I can find that even vaguely discusses these filters is LHO:16402. (Note, these are distinctly separate from the primary OMC ASC control filters that were simiplified by Dan Brown and Evan Hall in 2022; LHO:65861). Attached are bode plots of these two filters and their products for PITCH (in RED, on the left) and for YAW (in BLUE, on the right). Note, the FM0 plant inversion filters resolve to have notches at Notch Freq 1st (Hz) 2nd (Hz) P DOF 2.21 3.84 Y DOF 0.54 3.94 For comparison, I plotted the M1 [PIT,YAW] to M2 [PIT,YAW] transfer functions from the latest dynamical model from 2021 when I improved the damping loops (LHO:60049) and I get resonances at Notch Freq 1st (Hz) 2nd (Hz) P DOF 1.92 3.98 Y DOF 0.46 4.13 So ... maybe when we fix the infrastructrure, we should also update the plant inversion...
LHO aLOG 76856 describes the model prep for fixes made to the h1susifoout.mdl top level part and OMCS_MASTER.mdl library part in order to fix this bug.
J. Kissel, D. Barker, P. Fritschel Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist). After making these changes, the impacted model and library have been committed to the userapps SVN under /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl rev 27374 /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl rev 27375
Measured RF power at the
The analog readback of the power detector was 5.89V at the front panel. This has been confirmed to be the same as the slow controls readback, which corresponds to 23.3dBm.
Seems like disconnecting and connecting the LO cable" fixed" the problem. Flaky cable and/or connector?