Displaying reports 421-440 of 77237.Go to page Start 18 19 20 21 22 23 24 25 26 End
Reports until 15:36, Sunday 14 July 2024
H1 AOS
neil.doerksen@LIGO.ORG - posted 15:36, Sunday 14 July 2024 (79110)
High Dust Count

High dust count.

Images attached to this report
LHO VE
david.barker@LIGO.ORG - posted 09:15, Sunday 14 July 2024 - last comment - 09:33, Monday 15 July 2024(79108)
Pressure glitch on PT100B HAM1 at 07:25:15 Sun 14 July 2024

There was a pressure glitch on PT100B HAM1 cold-cathode at 07:25:15 PDT this morning. There was no corresponding glitch on any other corner station gauge as far as I can tell.

Pressure increased from 3.3e-08 to 4.0e-08 Torr, recovered in 4 minutes.

Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 11:31, Sunday 14 July 2024 (79109)

This is clearly very concerning. 

Attached is a trend of the pressure in the top right, along with several other channels (IMC power in, ISC_LOCK guardian state, RM alignments, DC power levels on all 4 PDs in that chamber), and I don't see anything in any of these channels that looks suspicious.

EDIT to add second screenshot, of in-vac tabletop L4C seismic sensors.  Again, nothing suspicious-looking to me that I see yet.

Images attached to this comment
michael.zucker@LIGO.ORG - 07:41, Monday 15 July 2024 (79112)

Given no lockloss correlation, may not be significant; ~3 orders of magnitude less PV than the June event(s).   Maybe an ion pump burped up some argon.

jordan.vanosky@LIGO.ORG - 09:33, Monday 15 July 2024 (79121)

IP13 ion current/pressure spiked up ~1 second before the PT100B gauge did, see attached. Likely argon instability of the pump

Images attached to this comment
LHO VE
david.barker@LIGO.ORG - posted 08:13, Sunday 14 July 2024 (79107)
Sun CP1 Fill

Sun Jul 14 08:04:08 2024 INFO: Fill completed in 4min 5secs

 

Images attached to this report
LHO General
ryan.short@LIGO.ORG - posted 01:09, Sunday 14 July 2024 (79106)
Ops Eve Shift Summary

TITLE: 07/14 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
SHIFT SUMMARY: H1 remained down again for this whole shift, and we will not be attempting to lock until further discussion can be had on the recent alignment changes. This is planned for Monday morning, which means H1 will not be observing until at least then.

The main activities of the shift were in pursuit of diagnosing the output alignment changes seen in the IFO recently, including my SR3 moves looking for good power spots (alog79103), further diagnosis of abnormal fast shutter behavior from last night (alog79102), and Sheila's comments on this situation being similar to that of the output change in late April (alog79101).

H1 General (ISC, OpsInfo)
ryan.short@LIGO.ORG - posted 01:04, Sunday 14 July 2024 - last comment - 08:42, Monday 15 July 2024(79105)
Comparisons before/after alignment changes

I've gathered several trends comparing the before and after of the alignment shift the IFO saw in the past couple of days, likely on Friday the 12th.

On all of these plots, I use y-cursors to indicate the levels each signal was at the appropriate time leading up to the last lock H1 had fully up to Nominal Low Noise, which lasted from 10:14 to 16:45 UTC on July 12th, in order to compare to what was likely the last time H1 was behaving "well."

DRMI signals with OM1/2 OSEMs:

The last DRMI acquisition before NLN, POP18 was around 66 counts while POP90 was around 11 counts.

The most recent DRMI acquisition, POP18 has dropped to 42 counts while POP90 has risen to 16 counts. The only significant alignment difference I see is with OM1 Y being about 70 counts different.

Optic alignments during 10W single-bounce: (times all taken from when ALIGN_IFO was in the state SR2_ALIGN [58])

The last SR2 alignment before NLN (P/SRC optics; large optics), AS_C_NSUM signal was at 0.0227 counts.

The next time in this configuration (P/SRC optics; large optics), AS_C_NSUM signal had dropped to 0.018 counts. The most obvious alignment changes are with PR2Y, PRM, some SR2, and SRM.

The most recent time in this configuration (P/SRC optics; large optics), AS_C_NSUM signal had dropped again to 0.014 counts. The same optics are off in alignment as before, but PRM has now flipped to being off in the opposite directions for both pitch and yaw.

OFI and KAPPA_C:

I recreated trends like Camilla did in alog78399 to check the behavior of the OFI. See attached for multi-day trend, zoomed in on shakes during high-state locklosses, and zoom in on one of these shakes.

HAM6 vacuum pressure:

Out of an abundance of caution, I trended the pressure gauge on HAM6 since we've seen pressure spikes somewhat recently, and I don't see anything that hasn't been previously noted on a 21-day timescale (the pressure rise ~20 days ago was noted to be because of the OM2 thermistor in alog78829).

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 08:42, Monday 15 July 2024 (79117)ISC

Looking more at the OFI TEC/temperature sensor, it seems like the alignment through the OFI changed, into probably a worse alignment that clipped somewhere (requiring more OFI temperature control as we powered up), at a time between the 2024/07/12 16:45UTC IFO unlock (looked normal, maybe 10-20% larger than normal temp swings) and the Power up at 17:45UTC. See attached. This is before we explicitly changed the SRC alignment.

Images attached to this comment
H1 ISC
ryan.short@LIGO.ORG - posted 21:16, Saturday 13 July 2024 - last comment - 21:14, Monday 15 July 2024(79103)
Moved SR3 with SR2 following to find spots with good AS port power

To help characterize the recent issues we've seen with IFO alignment that are familiar to the output change in late April, I moved SR3 in 10W single-bounce configuration with the SRC2 ASC loop on so that SR2 would follow (ALIGN_IFO's SR2_ALIGN state), much like in alog77694. I moved SR3 far enough in each direction (+/- pitch and yaw) to bring the ASC-AS_C_NSUM signal back up to our target value of 0.022, which I was successful doing in every direction except -Y, where I could only bring AS_C up to 0.018. In the three directions where I was successful, the beam spot on the AS AIR camera looked much more like the clear circle we're used to seeing and less like the upside-down apostrophe we have now.

It seems that our old output spot (starting place in TJ's alog) is still bad (-Y direction with SR3 from current place) since that was the only direction where I couldn't get the AS_C power back up.

Slider values of SR3 after each move:

  Start +P move -P move +Y move -Y move
SR3 P slider 438.7 651.1 138.7 438.7 438.7
SR3 Y slider 122.2 122.2 122.2 322.2 -167.8

Attachment 1 is the starting AS AIR camera image (and our current spot), attachment 2 is after the +P move, attachment 3 is after the -P move, and attachment 4 is after the +Y move.

Images attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 15:15, Monday 15 July 2024 (79135)
 
Before
+P move
-P move
+Y move
-Y move
Time
1404952764
2024/07/14 00:39:06 UTC
1404955465
2024/07/14 01:24:07 UTC
1404958133
2024/07/14 02:08:35 UTC
1404959716
2024/07/14 02:34:58 UTC
1404963518
2024/07/14 03:38:20 UTC
H1:SUS-SR3_M1_OPTICALIGN_P_OFFSET
438.7
651.1
138.7
438.7
438.7
H1:SUS-SR3_M1_OPTICALIGN_Y_OFFSET
438.7
122.2
122.2
322.2
-167.8
H1:SUS-SRM_M1_DAMP_P_INMON
-1033.7
-1035.2
-1036.3
-1036.1
-1037.1
H1:SUS-SRM_M1_DAMP_Y_INMON 
913.7
914.0
914.1
914.1
914.2
H1:SUS-SR2_M1_DAMP_P_INMON
597.7
-871.6
2660.2
614.7
566.2
H1:SUS-SR2_M1_DAMP_Y_INMON 
1125.3
1179.9
1069.3
1878.8
-72.4
H1:SUS-SR3_M1_DAMP_P_INMON 
-290.2
-57.7
-619.4
-297.9
-279.1
H1:SUS-SR3_M1_DAMP_Y_INMON
-411.0
-425.2
-390.4
-256.9
-633.7

Here are the OSEM values, so that Alena can cotinine her 78268 analysis of the OFI beam spot position.

sheila.dwyer@LIGO.ORG - 21:14, Monday 15 July 2024 (79154)

Adding a screenshot of sliders for the -P alignment above, after initial alignment.

Images attached to this comment
H1 SYS
daniel.sigg@LIGO.ORG - posted 20:27, Saturday 13 July 2024 - last comment - 12:00, Tuesday 16 July 2024(79102)
Fast shutter is OK

Yesterday, the fast shutter test failed due to dark offsets in the AS WFS DC NSUM channels.

The guardian started running the TwinCAT testing code, which works as intended: it sends a close command to the trigger logic, which in turn fires the fast shutter. The fast shutter works fine as can be seen on the HAM6 geophones. The slow controls readbacks also indicate that both fast shutter and PZT shutter are closed no later than 200ms after the trigger. However 0.5sec after the guardians started the test, it checks the AS WFS DC NSUM outputs and compares them against dark offset limits of ±15. Since the dark offset on WFS B was over 30, the guardian then sent an abort command to the TwinCAT code and reported a failure.

Comments related to this report
keita.kawabe@LIGO.ORG - 23:35, Saturday 13 July 2024 (79104)

That story agrees with my observation on Friday night when I started looking at the FS after 11:15 PM.

Sheila reported (79092) that the Fast Shutter reopened only after ~50ms or so. It seems that the low voltage drive to keep the shutter closed was not working. 1st attachment shows the last time that happened at around 23:10 local time. Daniel points out that the shutter was in an error state at that time but that was after Ryan power cycled the FS driver. We don't know exactly what kind of state the fast shutter was in here.

The next time the HV firing was tested was at 23:23 local time (2nd attachment), the shutter was kept shut (i.e. low voltage thing was somehow working) but there are two things to note.

  1. H1:ASC-AS_B_NSUM_OUT_DQ was about 25 or so, i.e. larger than the dark offset threshold of +-15. The FS guardian go to failed state.
  2. Bouncing was worse than I've ever seen. It bounced multiple times with 40 to 50ms period and eventually settles to the "closed" posotion. (Before Friday I only saw single bounce and that was it.)

The last FS test I've done was 00:12 local time on Jul/13 when the error was cleared, with the smaller power than nominal (3rd attachment). Bouncing was as bad but the power coming to HAM6 was smaller (see the trigger power at the top left). AS_B_NSUM was somewhat smaller (more like 10).

The reason why AS_B_NSUM is worse is because I reduced the analog DC gain by a factor of 10 and compensated for that by digital gain. The effect of analog offset as well as ADC/electronics noise are 10x worse than AS_A. I adjusted the dark offset while IMC was unlocked but we can probably increase the threshold to 30 or so if it continues to bother us.

Bouncing behavior might be more serious as it could mean that the beam was close to the end of the travel of the FS mirror (and it was bad on Friday because of funny alignment), or low voltage drive was somehow still funny. I suspect the former.

Images attached to this comment
ryan.short@LIGO.ORG - 17:25, Monday 15 July 2024 (79126)

Here is my attempt at recreating the (rough) timeline of events related to the fast shutter Friday night (all times in UTC):

  • 04:55:41 - While locking, ISC_LOCK gets to CHECK_AS_SHUTTERS and has the FAST_SHUTTER Guardian go to its TEST_SHUTTER state
    • The fast shutter test runs. Shutter closes, but due to improper dark offsets in the AS WFS DC NSUM channels (noted by Daniel above), Guardian thinks the test failed
      • Guardian sets AS_PROTECTION error code
      • Guardian reports "Fast shutter failed tests!! Downrange light does not disapear properly!" and jumps to SHUTTER_FAILURE
  • 04:55:43 - The fast shutter shows its error code
  • 04:55:46 - Fast shutter error code clears
  • ~05:20 - I power cycle the fast shutter driver chassis
  • 05:21:46 - Shutter opens
  • 05:28:00 - Next shutter close test; only closes for 65ms
  • ~05:45 - I power cycle the shutter logic chassis
    • No change in behavior is seen
  • 06:10 - There have been several attempts at running the shutter test at this point, all of them the shutter only was closed for 60-70ms at a time
  • 06:20 - The shutter finally closes and stays closed
  • 06:53 - Keita fixes the dark offset on AS WFS
  • 07:10 - Keita uses the Guardian to test the shutter; it works and stays open
  • 07:12 - Beckhoff errors clear after another full cycle using the Guardian
Images attached to this comment
keita.kawabe@LIGO.ORG - 14:53, Monday 15 July 2024 (79131)

Seems like ASC-AS_B_DC gain was probably a red herring, important thing is that the beam got uglier/bigger at some point, therefore a part of the beam was not blocked by the fast shutter.

First attachment shows when ASC-AS_B_DC gain switch was flipped from x10 to x1 on Tuesday. You can see that the Fast Shutter has been firing OK until Friday evening.

The rest of the plots show the FAST Shutter test done by the Beckhoff at three different points in time, i.e. the last test before my AS_B_DC change ("happy" Monday July/08 ~16:37 UTC or 9:37 local), the first one after my AS_B_DC change ("happy" July/11 4:43 UTC or Wed July/10 21:43 local time), and the first time the FAST shutter went into the error mode ("sad" Jul/13 4:56 UTC or Fri Jul/12 21:56 local time). The last one is when Sheila and Ryan started having problem.

Important points are:

  1. The two "happy" plots are quite similar. Especially, even though I see bouncing action, the power measured by both AS_A and AS_B more or less settle to the minimum value. Ratio of closed/open is about 230ppm in both cases. This is compatible with the specification of Fast Shutter mirror (which is <1000ppm).
  2. The "sad" plot looks nothing like the happy ones. Right after the shutter was closed the light level went down to less than 1000ppm, but bounced back and eventually settled down to ~6500ppm. You can also see that the light level when FS was open (~2200 cts) is about 50% of what it used to be in happy plots.
  3. ASC-AS_C was pretty close to center in all of the three plots.

From these, my conclusion is that the beam position on the fast shutter mirror was pretty much the same in all three tests, but the beam was pretty ugly for the "sad" plot as was witnessed by many of us on AS port camera. Because of this a part of the lobe was missed by the Fast Shutter. Centering an ugly beam on AS_C might have complicated the matter.

Later, when I forced the test with much lower power, the error was cleared because even though the ugly beam was still there the power went lower than the "shutter closed" threshold of the guardian.

I don't fully understand who did what when during the time the shutter was in the error state (it includes people pressing buttons and power cycling the driver and then pressing buttons again, and I certainly pressed buttons too).

Looking at this, and since Daniel agrees that the Fast Shutter has been working fine, my only concerns about locking the IFO are:

  1. The beam should be properly attenuated by the fast shutter. Not thousands of ppm, but more like ~230ppm.
  2. The beam should not clip on ASC-AS_C. If it's not clipped there, the chances of thing getting clipped downstream is very small.
Images attached to this comment
keita.kawabe@LIGO.ORG - 12:00, Tuesday 16 July 2024 (79148)

FYI, fast shutter has never failed to fire up and never failed to keep shutter closed when the trigger voltage crossed the threshold of 2V since I connected the ASC-AS_C analog sum  to the PEM ADC to monitor the trigger voltage at 2kHz at around Jul/11 2024 18:30 UTC, i.e. in the past 5 days.

In other words, FS has never failed when we actually needed it to protect AS port.

In the 1st attachment, top is the trigger voltage monitored by the ADC. Red circles indicate the time when the trigger crossed the threshold. We've had 12 such events, including 4 that happened after Friday midnight local time.

Middle plot shows when the fast shutter was driven with high voltage (sensed by GS13). Bottom shows the AS_A_DC_NSUM and B_DC_NSUM.

The reason why it looks as if the trigger level changed before and after t=0 on the plot is because a 1:11 resistive divider with a total resistance of 10kOhm was installed at t=0. Before that, the 2V threshold was 32k counts, 2980 counts after.

The rest of plots show that each and every time the shutter was triggered by the trigger voltage rather than a test, it always fired up and kept the shutter closed.

Images attached to this comment
H1 ISC
sheila.dwyer@LIGO.ORG - posted 17:19, Saturday 13 July 2024 (79101)
some symptoms that seem similar to April 22nd/23rd output change

For a summary of links related to the 22nd/23rd incidents, see

The first two screenshots show the AS air camera with 2W out of the PSL in single bounce, reflecting off ITMY.  This seems very similar to what happened on April 22nd/23rd, where the as camera image looked bad when we were centered on AS_C, but looks sort of normal when we were way off center.

The single bounce throughput is also low, similar to what we saw on April 23rd.  Jenne looked at some times when the initial alignment guardian did SR2 offload, and narrowed down when the single bounce throughput changed to sometime between 9:23 and 23:22 UTC yesterday. 

  IMC-PWR_IN (Watts out of PSL) IMC-IM4_TRANS_NSUM (has had clipping at some of these times) in Watts onto PRM AS_C NSUM (Watts into HAM6)
April 16 77204 10.01 9.14 0.0229
April 24th 77441 10.005 9.62 0.023
12 July 2024 09:23:57 (SR2 align time Jenne found) 10.0 8.7 (clipped) 0.0227
12 July 23:22:55 (SR2 align time that Jenne found) 10.01 8.7 (clipped) 0.0185
now July 13 23:35:51 UTC 10.0 8.67 0.0148

 

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 16:31, Saturday 13 July 2024 (79095)
OPS Saturday day shift summary

TITLE: 07/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

Images attached to this report
LHO General
ryan.short@LIGO.ORG - posted 15:56, Saturday 13 July 2024 (79099)
Ops Eve Shift Start

TITLE: 07/13 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 11mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: Work on our IFO alignment issues have continued today; Ryan has just finished an initial alignment and Sheila is supporting remotely.

H1 General
ryan.crouch@LIGO.ORG - posted 12:02, Saturday 13 July 2024 - last comment - 13:54, Saturday 13 July 2024(79096)
OPS Saturday day shift update

STATE of H1: Corrective Maintenance

We're getting shaken by an earthquake right now, once it calms down I'm trying to lock DRMI in PREP_ASC to check on the AS_SHUTTER. My IA efforts seemed to have helped as AS AIR doesn't look so strange anymore and DRMI flashes looked good. I'm going to try to keep moving up the locking sequence.

 

Comments related to this report
ryan.crouch@LIGO.ORG - 13:32, Saturday 13 July 2024 (79097)

RyanC, Sheila D.

I got up to PREP_ASC twice and ran the shutter test each time, It looks good.

Images attached to this comment
ryan.crouch@LIGO.ORG - 13:54, Saturday 13 July 2024 (79098)

The loops are unstable and keep killing DRMI, SRM is shaking the most.

Images attached to this comment
LHO VE
david.barker@LIGO.ORG - posted 08:15, Saturday 13 July 2024 (79093)
Sat CP1 Fill

Sat Jul 13 08:09:15 2024 INFO: Fill completed in 9min 11secs

Images attached to this report
H1 SYS
sheila.dwyer@LIGO.ORG - posted 08:12, Saturday 13 July 2024 (79092)
AS shutter really wasn't working normally last night

The first attached screenshot shows a time when the fast shutter was tested on July 11th, and seemed to be working fine and passed the tests.  In that case, the light on AS_A and AS_B was blocked for almost 10 seconds during the test. 

The second screenshot shows one of the many times that we tried to manually hit the run test button last night while sitting in ISC_LOCK state 120 (check as shutter). The light on AS_A and AS_B were only blocked for 10ms. 

So, this wasn't a false alarm, something about the shutter really wasn't working correctly last night. 

I've placed an ndscope template people can use to check on the fast shutter in /ligo/home/sheila.dwyer/ndscope/SYS/check_fast_shutter.yam The fast shutter full tests only run if it has been 48 hours since it last ran, so I think that Ryan should rerun the test manually this morning and check this template to convince ourselves that the shutter is really working now, before we continue with locking.

 

 

Images attached to this report
H1 General
ryan.crouch@LIGO.ORG - posted 07:39, Saturday 13 July 2024 - last comment - 08:59, Saturday 13 July 2024(79091)
OPS Saturday day shift start

TITLE: 07/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 08:59, Saturday 13 July 2024 (79094)

I'm trying to get up to CHECK_AS_SHUTTERS to run the tests, PRMI can lock ok but DRMI struggles. I'm starting an IA at 16:00 UTC, mostly to try to help SRC which is definetly misaligned from DRMIs AS AIR. 

H1 ISC
sheila.dwyer@LIGO.ORG - posted 16:27, Thursday 25 April 2024 - last comment - 16:08, Saturday 13 July 2024(77427)
Summary of alogs related to changes in our output arm this week

In the observing stretch that started Monday around 8 pm, there was a drop in optical gain (by 4%), and power at AS port PDs (4% drop in AS_A sum, AS_B sum, AS_C sum, and OMC REFL).  There not at that time any change in circulating power in the arms, PRG, coupled cavity pole, or alignment of suspensions (shown are SR2, SRM, OM1+2, but we have also looked at many other suspension, ISI and HEPI related channels for this time 77382 ).  This time is shown by the first vertical cursor in the attachment. 

We were unable to relock the interferometer after that Monday evening lock (a new lockloss type appeared early Tuesday morning, 77359), and after the maintence window we were uable to lock with difficulties powering up (77363) and an AS camera imagine that had lobes whenever the beam was well centered on AS_C.  We locked that evening by adding large offsets to AS_C's set point, (77368).  This is the cause of the large alignment shifts seen in the screenshot on Tuesday evening to Wed morning, which allowed us to lock the IFO but created a large scatter shelf and resulted in a lower coupled cavity pole, and lower optical gain, and we did not have much squeezing that night. 

We do not think that Tuesday maintence activities are the cause of our problems, although some of the Tuesday work has been reverted (77350 77369).

Yesterday we spent much of the day with SRY locked, single bounce or using the squeezer beam reflected off SRM to investigate our AS port alignment.  77392, We are able to recover the same throughput of a single bounce beam to HAM6 by moving the alignment of SR2 + SR3 by a huge amount 77388, which also produced a round looking beam on the AS camera.  We haven't since tried to explore this aperture, to see if we could have also recovered this thoughput with a pitch move, for example.  We also saw that the squeezer beam does not arrive in HAM6 with a good transmission when injected with the alignment used previously, but that we could recover good transmission to HAM6 by moving ZM5 by 150-200 urad, in pitch or yaw.   With this shift in SRC axis, and squeezer alignment we were able to relock and not have the large scattering issues we had Tuesday night.

Today's time was spent recovering from a seemingly unrelated problem in the SQZ racks, and some commissoning aimed at recovering our previous (165Mpc) sensitivity with this new alignment.  This will continue during tomorow's commissoning time.


additional related information:

 

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 13:58, Wednesday 08 May 2024 (77718)

Adding some trends, which have otherwise been mentioned.  The optiocal levers and top mass osems suggest that there hasn't been any shift in the PRC, Michelson, or arms.  There was also not a shift in alignment of the SRC in the first low optical gain lock on the 22nd, that alignment didn't shift until the manual move of the SRC in the recovery effort.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 10:45, Saturday 15 June 2024 (78456)

Camilla notes that the OFI temperature controler had unusual behavoir in the Tuesday relocking attempts: 78399

 

sheila.dwyer@LIGO.ORG - 16:08, Saturday 13 July 2024 (79100)

comparisons of single bounce throughputs: 77441

Displaying reports 421-440 of 77237.Go to page Start 18 19 20 21 22 23 24 25 26 End