Displaying reports 10921-10940 of 86580.Go to page Start 543 544 545 546 547 548 549 550 551 End
Reports until 16:34, Sunday 19 May 2024
H1 General
ryan.crouch@LIGO.ORG - posted 16:34, Sunday 19 May 2024 (77930)
OPS Sunday DAY shift summary

TITLE: 05/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Tony
SHIFT SUMMARY: More progress than yesterday in terms of the PRMI oscillation as I seem to have solved it for now by adjusting loop gains and ramps and can hold it locked, then I was back to DRMI not being able to lock but after Sheila restored PR3 to a previous spot we were able to lock DRMI no problem. Currently a few minutes away from NLN

15:00 UTC Initial Alignment as there weren't really any flashes on PRMI

After some more fiddling with gains/ramp times and talking to Sheila I was able to stop the PRMI 20ish Hz buzz by reducing PRMI-MICH to 2.2 from 2.8 and increasing PRMI_PRCL to 8 from 6 and set the ramp time sof both to 5 alog77928

20:25 UTC - No matter how much adjusting I did with the sliders (BS, PRM, SRM) I couldn't get AS AIR looking good enough so I thought there must be an alignment issue somewhere after a few mores tries I dropped to do another Initial Alignment, after this I still had DRMI issues.

I further decreased the gain of PRMI-MICH to 2.0 after Sheila looked at my OLG measurement, PRMI locked pretty easily after this. We're not sure why my PRCL OLG measurement looked the way it did alog77929

22:35 UTC Sheila adjusted PR3 to where it used to be, after which I did another Initial Alignment so we could try locking PRMI. I may need to revert my PRMI loop changes? I have not reverted them as of now

After finishing IA we locked DRMI immediately

There were a lot of IFO_OUT saturations during POWER_25W and MOVE_STOPS

H1 AOS
sheila.dwyer@LIGO.ORG - posted 15:52, Sunday 19 May 2024 (77931)
PRMI troubleshooting remotely

After Ryan was able to lock PRMI by adjusting both the MICH and PRCL gains (77926) , he mentioned to me that the build ups didn't look good.  Indeed, POP18 was around 26 counts after PRMI ASC ran, before our PR3 moves this week it would be around 50 counts in PRMI.  I looked back and it hasn't been 50 since I put PR3 back on Friday.  I was able to walk PR2, PRM and BS to improve the build up a little, but decided to move PR3.  We did this at LOCKING_ARM_GREEN, and saw that putting PR3 back according to the slider values (rather than top mass osems), did improve the COMM beatnote from around -10 to around 0dBm. 

Ryan is going to run an initial alignment skipping the green arms, and try to relock PRMI.  Then we will see if this PR3 move solves the low POP18 power, if the PRMI gain changes can be reverted. 

Also note that Ryan posted a PRCL UGF measurement that seems very strange. 

H1 General
ryan.crouch@LIGO.ORG - posted 10:45, Sunday 19 May 2024 - last comment - 12:14, Sunday 19 May 2024(77926)
OPS Sunday day shift update

I spent a bit trying to align everything by hand with ISC_LOCK paused in DRMI, misaligning PRM and SRM to adjust the BS then aligning PRM to adjust it then SRM. Still the same behaviour on PRMI as yesterday even with turning down the MICH and PRCL gains, and despite good flashes on DRMI it wasn't able to lock after my adjustments, I had to move SRM a lot. The wind is also picking up which is not helping ALS.

Images attached to this report
Comments related to this report
ryan.crouch@LIGO.ORG - 11:30, Sunday 19 May 2024 (77927)

I talked with Sheila who had some more suggestions, gain lowering/raising and a template to run if I'm able to get PRMI locked, She's on her way back into town and might be able to help more in an hour or two.

ryan.crouch@LIGO.ORG - 11:52, Sunday 19 May 2024 (77928)

Increasing the ramp times of MICH and PRCL and reducing the gain even more of MICH (2.8 to 2.5) and raising the gain of PRCL (6 to 8) has allowed us to survive longer. After this we keep losing lock at different points in the ISC_DRMI  PRMI code, the furthest I've made it was PRMI_WFS_CENTERING.

ryan.crouch@LIGO.ORG - 12:14, Sunday 19 May 2024 (77929)

I was able to lock PRMI finally and go through ASC by increasing the ramp times of both MICH and PRCL from 2 to 5, further decreasing the gain of MICH from 2.5 to 2.2 with als and 2.8 to 2.6 without arms and with PRCLs als gain being raised from 6 to 8. DRMI still wasn't able to catch after 1 round of PRMI, I'm holding in PRMI_ASC to take a quick OLG measurement of PRCL and MICH.

Images attached to this comment
LHO VE
david.barker@LIGO.ORG - posted 10:31, Sunday 19 May 2024 (77925)
Sun CP1 Fill

Sun May 19 10:09:59 2024 INFO: Fill completed in 9min 56secs

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 07:38, Sunday 19 May 2024 - last comment - 08:22, Sunday 19 May 2024(77921)
OPS Sunday day shift start

TITLE: 05/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 2mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 07:57, Sunday 19 May 2024 (77923)

I'm not getting any flashes on DRMI or even PRMI so I'm going to do an initial alignment

ryan.crouch@LIGO.ORG - 08:22, Sunday 19 May 2024 (77924)

I have reached out to everyone (Jenne and Sheila) on the call list that are not on travel or otherwise listed as unavailable, Jenne is helping over text.

H1 General
oli.patane@LIGO.ORG - posted 04:16, Sunday 19 May 2024 - last comment - 07:43, Sunday 19 May 2024(77919)
Ops OWL Assistance Status

Tony and I have been troubleshooting the relocking issues since 08:00UTC, and have had no luck. We have been stuck not able to get past ACQUIRE_PRMI due to the ~10-30Hz wiggle that starts a few seconds into PRMI catching. So far:

08:05 Got on to Tony trying to lock the ifo but having trouble getting past PRMI

08:29 Took us to DOWN to revert to previous alignment values that Ryan C used earlier (1400036418 aka 05/18/24 03:00 UTC)

08:30 Started an Initial Alignment

08:55 Initial Alignment finished
    - lscparams:
        - PRMI_MICH W_ALS changed 3.2 -> 2.6 and NO_ARMS changed 2.8 -> 2.6 (didn't help)
        - PRMI_PRCL W_ALS changed 6 -> 2 (didn't help)
    - ISC_LOCK and ISC_DRMI reloaded, starting relocking
- Couldn't get DRMI, went straight down to MICH instead of trying PRMI first
- Couldn't get PRMI to lock for more than ~3 seconds, then we get the wiggle between 10 and 30 Hz and lose it

09:47 Earthquake mode activated due to incoming earthquake from Alaska
10:33 Ground mostly settled after earthquake

The oscillations seem to start a couple of seconds after getting PRMI, right before ISC_DRMI's PRMI_LOCKED gets into .run. We wanted to see if it was related to the ramp times and/or value changes happening at the same time, so we have increased the gain ramp times for lines 518 (LSC_MICH1) and 519 (LSC_PRCL1) in ISC_DRMI from 2 to 4 seconds for each, and if that doesn't work I'll be adding in timers between these lines and around the other value changes and gain ramps between those lines and the end of PRMI_LOCKED .main in ISC_DRMI.

Comments related to this report
oli.patane@LIGO.ORG - 05:13, Sunday 19 May 2024 (77920)

11:18 Lines 518 and 519 in ISC_DRMI gain ramp time was increased from 2 to 4 seconds, reloaded, relocking
    - didn't work, still lost lock at same place

I added 5 second sleep timers after each line where a filter value or ramp time was changed between ACQUIRE_PRMI LSC_MICH1 gain ramp time (line 518) to the end of .main in PRMI_LOCKED, and the oscillations started 3 seconds after LSC_MICH1 (this is still with ramp time set to 4s instead of 2s).

Then I changed LSC_MICH1 ramp time back to 2
- Not sure what happened this time - didn't seem to oscillate, just a short lock

Putting the detector in DOWN for the next hour until I can wake people up

oli.patane@LIGO.ORG - 07:43, Sunday 19 May 2024 (77922)

Ryan C has come in for his shift this morning, so right before he came in I reverted all changes made to lscparams and the ISC_DRMI script during our troubleshooting this past night and reloaded both ISC_DRMI and ISC_LOCK. This means that the PRMI_MICH and PRMI_PRCL gains in lscparams are back to where they were at the beginning of my shift (and I believe should also match what they were at the beginning of Tony's shift, since he said he also reverted everything back to how it was originally?).

H1 General (Lockloss)
anthony.sanchez@LIGO.ORG - posted 01:22, Sunday 19 May 2024 - last comment - 01:33, Sunday 19 May 2024(77916)
Saturday Ops Eve Shift End

TITLE: 05/19 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
Lockloss @ 2:37 UTC
https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1400121463
I'm fairly confident that a strong wind gust may have unlocked us.

5.5 Mag Earthquake from the top of the world: https://earthquake.usgs.gov/earthquakes/eventpage/us6000mzkf/

I'm Having a reall dificult time getting DRMI & PRMI to lock for some reason. very similar to Ryan's Alog:
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=77906
Touched the beam splitter a nudge in a few directions to try and lock PRMI.

Check mich fringes is also saying the Beam splitter too far misaligned!

This seems like just a bad alignment and may be related to the fact that the Last Initial Alignment, was done during an earthquake.

GRB-Short E484987

Took alignment back to GPS time: 1400035904 ( the tail end of Initial Alignment before the last good long lock stretch.)

Can now certainly rule out bad alignment. Took PRMI-MICH to 2.6 and the PRMI lock lasts a little longer but still ultimately doesnt stay locked.

I'm now trying the PRMI-PRCL at 4 like Ryan suggested. As I too am seeing the PRMI 20 Hz wiggle Ryan was speaking about.

GRB-Short E484996

I tried to Manual ISC lock through PRMI to test diffent settings so see if they would actually lock PRMI for any longer. I cannot keep PRMI Locked for more than 3 seconds.

Trending PRM Slide values I see that pitch is higher by 11ish  and Yaw is higher by 3 ish since the last long lock.

 

Comments related to this report
anthony.sanchez@LIGO.ORG - 01:28, Sunday 19 May 2024 (77917)

The way I have been editing lsc params is clicking the edit button on ISC_DRMI guardian. This for me opens Pycharm, which also opens lscparams file.
I have been editing line 191and line 193 and the load the Guardian.

 

anthony.sanchez@LIGO.ORG - 01:33, Sunday 19 May 2024 (77918)

20 hz wiggle became a 30 hz wiggle.
When I could get PRMI to Lock the lock would immdiately lose lock right afterwards.

Images attached to this comment
H1 General
anthony.sanchez@LIGO.ORG - posted 18:57, Saturday 18 May 2024 (77915)
Mid Eve Shift Update

TITLE: 05/19 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 22mph Gusts, 19mph 5min avg
    Primary useism: 0.12 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

Took the IMC OFFLINE

heading to the CER> HAM3 ISI Interface chassis, on the back of those 2 chassis , power cycling both the interface chassis.  

After Power cycling and getting approval from Jim I starting relocking, which was failing to get past PRMI. I then did an Initial_ALignment. This is when an earthquake struck.
https://earthquake.usgs.gov/earthquakes/eventpage/us6000mzjx/

Initial Alignment did finish. I waited a few minutes for the peak of the earthquake to go down before starting to lock again.
Locking went well after this, even with wind speed rising and earthquakin.

Observing Reached @ 1:45 UTC

We are now Locked and in Observing, Range is slight low though, once thermalized I'll do a SQZ Scan. 

H1 General (SEI)
anthony.sanchez@LIGO.ORG - posted 16:51, Saturday 18 May 2024 (77913)
Saturday Ops Eve Shift Start

TITLE: 05/18 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 11mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

Relocking the IFO,  After HAM3 SEI ISI Watchdog tripped. Wind is starting to kinda
2 more ISI Watch dog trips while relocking.
I have called Jim to help troubleshoot this issue, and Holding in IDLE until I can get a green light from Jim.

 

H1 General (SEI)
ryan.crouch@LIGO.ORG - posted 16:35, Saturday 18 May 2024 - last comment - 10:09, Monday 20 May 2024(77906)
OPS Saturday day shift update

TITLE: 05/18 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Lost lock at the end of the shift, DRMI alignment issues and PRMI was plagued by a ~20Hz buzz that kept killing it after 2 seconds, the mode cleaner was slow to lock in each attempt today. After the 3rd IA DRMI was finally in the mood to lock and I didn't have to go through PRMI and I returned to Observing at 21:15UTC. I was not able to take the calibration measurement this afternoon as planned.

15:25 UTC HAM3 ISI CPS trip while doing green arms in IA. I could not finish SRC align, as SRM was continually saturating. There was also a couple of IY saturations, and there was an earthquake shaking everything at the time.

16:02 UTC HAM3 ISI CPS trip during FIND_IR? I couldn't get PRMI to stay locked for more than 2 seconds.

17:00 UTC I restored the alignments to 05/18/24 03:00 UTC which was right before we locked last night for the 11 hour lock. After locking ALS I could immediately see the beatnotes were better, but DRMI only had small flashes. A few rounds of CHECK_MICH and still bad flashes, 13:31 I started a 2nd IA skipping GREEN_ARMs, there were no saturations during this IA and I was able to finish SRC_ALIGN.

I'm still not able to get PRMI to stay locked for more than 2 seconds, theres a 20ish Hz oscillation that kills it when the MICH1 filter is ramped on? I tried lowering the PRMI-MICH gain from 3.2 to 2.8 in lscparams as Sheila suggested the other day. It lasted longer but was still ultimately killed by the 20Hz buzzing, I lowered it more to 2.6 and it lasted even longer but was killed when PRCL1 turned on? AS AIR was still clearly misaligned so I went through CHECK_MICH which made things worse?  I now had worse PRMI flashes and still a clearly misaligned AS AIR. During this I was also trying to help adjust PRM/BS while in PRMI to fix AS AIR.

19:37UTC After some more seemingly fruitless adjusting of PRM and BS I started a 3rd IA... it looks centered on AS-AS_C during SRC and PRC alignment?

Same behavior as before, bad DRMI then PRMI gets killed after a few seconds from the 20Hz, its also always right after the BS_M1_L filter is turned on. Lockloss after a few rounds of PRMI.

For the next attempt I tried turning down the PRMI-PRCL gain from 6 to 4 but then it was able to lock DRMI all of a sudden and we didn't even go through PRMI... so I'll revert these changes. I have no idea whats different this attempt from the last or why it decided now it wants to work but I'll take it. The alignment was just finally good enough, even though it wasn't on the first attempt after the IA finished?

21:15 UTC back to Observing

23:21 UTC lockloss from a HAM3 ISI trip, same as before, CPS sensor tagging SEI

Images attached to this report
Comments related to this report
jim.warner@LIGO.ORG - 17:34, Saturday 18 May 2024 (77914)SEI

Looking at trends, there were four trips today from HAM3 CPS glitches, none of which can be attributed to earthquakes, as far as I can tell. HAMs are usually not the first to get tripped, and the glitches Ryan posts don't look physical, they look like typical CPS glitches. Tony went out and power cycled the CPS parts of the HAM ISI interface chassis for HAM3, we'll just have to wait and see if that fixes it or if more invasive work is needed.

First attached trends are the high frequency blrms we have for monitoring for glitches, they seem like they would have provided some warning for this, there were glitches an hour or so before the first trip. I think we have some tests for this in DIAG_MAIN? We should think about how to get this  to get some more attention.

 

Images attached to this comment
ryan.crouch@LIGO.ORG - 10:09, Monday 20 May 2024 (77943)SEI

There is indeed a test in DIAG_MAIN for noisy CPS sensors called "SEI_CPS_NOISEMON" and it was going off last night during the glitches and 2 trips (marked by the T cursors at 02:37 and 02:47 UTC), doing a "guardctrl log -n1000 -a "1400207700" -b "1400210000" DIAG_MAIN" of a time where the CPS was glitching last night yielded the following trace back. Maybe there should be verbal_alarms check for this as well?

2024-05-20_02:34:59.601882Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'V2')]
2024-05-20_02:36:49.102804Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'V2')]
2024-05-20_02:37:01.099752Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V2')]
2024-05-20_02:37:01.353280Z DIAG_MAIN [RUN_TESTS.run] USERMSG 1: SEI_STATE: ['HAM3'] is not nominal
2024-05-20_02:37:05.341046Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: FAST_SHUTTER_HV: Fast Shutter HV not Ready
2024-05-20_02:37:05.353980Z DIAG_MAIN [RUN_TESTS.run] USERMSG 3: SEISMON_EQ: LSC-REFL_SERVO_SPLITMON > 8V
2024-05-20_02:37:05.354500Z DIAG_MAIN [RUN_TESTS.run] USERMSG 4: SHUTTERS: AS beam shutter open (nominal: closed)
2024-05-20_02:37:05.478436Z DIAG_MAIN [RUN_TESTS.run] USERMSG 3: SEISMON_EQ: IMC-REFL_SERVO_SPLITMON > 8V
2024-05-20_02:37:05.478660Z DIAG_MAIN [RUN_TESTS.run] USERMSG 4: SHUTTERS: Shutter A closed (nominal: open)
2024-05-20_02:37:05.605105Z DIAG_MAIN [RUN_TESTS.run] USERMSG 6: SQUEEZING: SQZ_MANAGER is not in the nominal state. Check we are Squeezing.
2024-05-20_02:37:05.907983Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: ESD_DRIVER: ESD X driver OFF
2024-05-20_02:37:08.857117Z DIAG_MAIN [RUN_TESTS.run] USERMSG 2: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'V2')]
2024-05-20_02:37:09.471870Z DIAG_MAIN [RUN_TESTS.run] USERMSG 2: PSL_FSS: PZT MON is high, may be oscillating
2024-05-20_02:38:30.391003Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:40:33.387179Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:40:41.389505Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:40:54.382921Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:41:06.394464Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:41:11.386640Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:41:34.390778Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:43:51.602046Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V2')]
2024-05-20_02:44:18.387630Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:47:24.388026Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:47:37.597677Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V2')]
2024-05-20_02:47:37.854048Z DIAG_MAIN [RUN_TESTS.run] USERMSG 1: SEI_STATE: ['HAM3'] is not nominal
2024-05-20_02:47:42.394967Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:48:21.393532Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:48:33.387284Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:50:27.386254Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:51:25.216172Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_FSS: PZT MON is high, may be oscillating
2024-05-20_02:52:30.383231Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:53:48.383839Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:54:03.858072Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V2')]
2024-05-20_02:54:04.477258Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1'), ('HAM3', 'H2'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V2'), ('HAM3', 'V3')]
2024-05-20_02:54:05.232099Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1'), ('HAM3', 'H2'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V3')]
2024-05-20_02:54:05.475537Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V3')]
2024-05-20_02:54:10.853656Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1')]
2024-05-20_02:54:27.392176Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:54:47.394045Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:54:57.724598Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V3')]
2024-05-20_02:55:00.292951Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H1'), ('HAM3', 'H2'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V2'), ('HAM3', 'V3')]
2024-05-20_02:55:06.224234Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'H3'), ('HAM3', 'V1'), ('HAM3', 'V2'), ('HAM3', 'V3')]
2024-05-20_02:55:06.356844Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V1'), ('HAM3', 'V2')]
2024-05-20_02:55:06.482500Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2'), ('HAM3', 'V2')]
2024-05-20_02:55:08.976174Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: SEI_CPS_NOISEMON: Noisy HAM CPS(s): [('HAM3', 'H2')]
2024-05-20_02:56:27.394588Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low
2024-05-20_02:56:56.390876Z DIAG_MAIN [RUN_TESTS.run] USERMSG 0: PSL_ISS: Diffracted power is low

Related: alog75134

Images attached to this comment
Displaying reports 10921-10940 of 86580.Go to page Start 543 544 545 546 547 548 549 550 551 End