This daqd restart was used as a test of h1daqfw2's ability to adjust on the fly. It went well. As expected the new code saw the changes and adjusted.

Amoung the changes were additions to the system monitoring channels.  We did the restart towards the end of the hour.  Normally that would mean losing close to an hours worth of trend data.  In this case the framewriter adjusts its channel list on the fly.  Below you can see two channels dumped from a 1hr minute trend frame.  The ...H1DAQFW1... was an old pre-existing channel, ...H1DAQFW2... channel was new.  You can see that the new channel was added midway with a zero fill of the data before it existed, while the older channel was not impact (or thrown away with the daqd restart).

In addition, over the weekend I figured it wouldn't take too much work to put a minimal nds1 interface onto the framewriter.  So both Erik and I were able to take some simple measurements through the daqd restart without interruption.  I did have some issues with streaming the data from the edc (the bit we restarted).  This functionality is very much not ready for control room use, but did work as a proof of principle.

Dump of a old and a new channel from a frame generated while the other frame writers were being restarted:

root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf
Frame file: H-H1_M-1430589600-3600.gwf
DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW1_CPU_LOAD_PERCENT.mean
DEBUG: Trying as ADC
DEBUG: Is a ADC
Name:     
Compress: 266 (Endianness: Little Scheme: 10)
Type:     2
NData:    60
NBytes:   416
Data: 6.28729164004326, 4.17406255081296, 3.57833329414328, 3.60958333561818, 3.66750004241864, 3.67500002260009, 3.71916669532657, 3.74739585369825, 3.8817708991468, 3.82260420769453, 5.55906248788039, 3.87937504226963, 3.93562503432234, 3.91968751251698, 3.82739583849907, 3.62052083040277, 3.62010418747862, 3.69833336497347, 3.68625002404054, 3.66718753005068, 5.32447914779186, 3.67375002975265, 3.71656252965331, 3.73489584351579, 3.89322916989525, 3.90125003928939, 3.93125004768372, 3.86749999498328, 3.91406253824631, 3.71927081222336, 5.44343745956818, 3.61781248822808, 3.68937503372629, 3.71395837391416, 3.7930208645761, 3.76812503834565, 3.7355208667616, 3.62187499354283, 3.70145832026998, 3.80020837162932, 5.48312501261632, 3.90666671544313, 3.92562501778205, 3.9627083795766, 3.95802086566885, 3.92802087018887, 3.80010416110357, 3.63791664664944, 3.62510419090589, 3.62989583437641, 5.31531244814396, 2.30302085528771, 0.95135415866971, 3.71520840749145, 3.72906252816319, 3.93354169155161, 4.05625004221996, 2.55833331122994, 2.94218750347694, 4.27510416905085
root@h1daqfw2:/frames/trend/minute/14305#
root@h1daqfw2:/frames/trend/minute/14305# framecpp_dump_channel --channel H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean H-H1_M-1430589600-3600.gwf 
Frame file: H-H1_M-1430589600-3600.gwf
DEBUG: Processing channel: H1:CDS-MONITOR_H1DAQFW2_CPU_LOAD_PERCENT.mean
DEBUG: Trying as ADC
DEBUG: Is a ADC
Name:     
Compress: 266 (Endianness: Little Scheme: 10)
Type:     2
NData:    60
NBytes:   96
Data: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1.34916668335597, 4.81020835687717, 4.67812503005068, 4.78708336452643, 4.95833332886299, 4.98052083601554, 4.76249999230107, 4.90572916567326
root@h1daqfw2:/frames/trend/minute/14305#

The DR dust monitor counts did not look correct, its was only reading zero for over 2 weeks, I went out and power cycled it and made some counts which I was not able to see on epics. I then tried to restart the IOC, and it struggled to come back. After a little over 5 minutes it did come back and started showing counts again.

The DR is having network issues again, ~an hour after the restart. I'll try swapping this one with one of our 2 pumpless spares.

2025/05/06 11:09:20.443023 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: No reply from device within 1000 ms
2025/05/06 11:09:21.444241 gt521s1 H1:PEM-CS_DUST_DR1_STATE: No reply from device within 1000 ms
2025/05/06 11:09:21.787891 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "SH 600*00337" mismatch after 0 bytes
2025/05/06 11:09:21.787919 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "SH 600*00337" where "OP " was expected
2025/05/06 11:09:22.344822 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: Input "OP H 58*00404" mismatch after 0 bytes
2025/05/06 11:09:22.344838 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIMEMON: got "OP H 58*00404" where "SH " was expected
2025/05/06 11:09:22.394988 gt521s1 H1:PEM-CS_DUST_DR1_STATE: Input "H 57*00403" mismatch after 0 bytes
2025/05/06 11:09:22.395020 gt521s1 H1:PEM-CS_DUST_DR1_STATE: got "H 57*00403" where "OP " was expected
2025/05/06 11:09:22.445131 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: Input "P H 57*00403<8d>OP H 57" mismatch after 0 bytes
2025/05/06 11:09:22.445164 gt521s1 H1:PEM-CS_DUST_DR1_OPSTATUS: got "P H 57*00403<8d>OP H 57" where "OP " was expected

Swapped the dust monitor and now it won't come back and the IOC can't connect to/see the DM.

2025/05/06 11:42:20.506771 gt521s1 H1:PEM-CS_DUST_DR1_HOLDTIME: No reply from device within 1000 ms
2025/05/06 11:42:20.507000 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: @init handler failed
2025/05/06 11:42:20.507100 _main_ H1:PEM-CS_DUST_DR1_HOLDTIME: Record initialization failed
Bad init_rec return value  PV: H1:PEM-CS_DUST_DR1_HOLDTIME ao: init_record

2025/05/06 11:42:21.508499 gt521s1 H1:PEM-CS_DUST_DR1_SAMPLETIME: No reply from device within 1000 ms
2025/05/06 11:42:21.508670 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: @init handler failed
2025/05/06 11:42:21.508762 _main_ H1:PEM-CS_DUST_DR1_SAMPLETIME: Record initialization failed
Bad init_rec return value  PV: H1:PEM-CS_DUST_DR1_SAMPLETIME ao: init_record

Tagging EPO for photos.

Note that the same glitches we had in the original installation (alog 8934) were still there. Quoting my alog from 2013,

it was still difficult to obtain good data because of some kind of glitches. It's not clear if it was due to NanoScan or the beam, the beam was well damped and was not moving on the viewer card, there was no noticable intensity glitch either. But the symptom was that the statistics window shows nice steady data for anywhere from one second to 30 seconds, then there's some kind of glitch and the scan/fit image looked noticably different (not necessarily ugly), the diameter mean becomes larger and the stddev jumps to a big number (like 10% or more of the mean, VS up to a couple % when it's behaving nice), and the goodness of fit also becomes large. Somehow no glitch made the beam diameter number smaller. I just kept waiting for a good period and cherry-picked.

We measured the beam radius using NanoScan at four points around the WFS sled (roughly WFSA position, roughly WFSB position, far field 1, far field 2). We used D4sigma numbers instead of 1/e**2 numbers. NanoScan outputs diameter not the radius, and the table below shows the raw number.

We assumed that the WFS position would be ~0.5" from the +Y edge of the WFS sled for both A and B. Distances were measured using stainless steel rulers and are relative to the 50:50 splitter on the WFS sled that also acts as the steering mirror for WFSa.

In all of the above measurements, "Profile averages" was 10, "Rolling profile Averages" was 3.

We also measured between M5 and 50:50 splitter for ASC-LSC split as well as between M2 and RM1. Numbers will be added to this alog.

We'll also measure the beam size at LSC REFL_B location on Monday before proceeding to POP path.

Here are some comments about the measurement process:

The beam profiler is difficult to use because the profiler head easily swivels once it is place. The swivel seems to be driven by the fact that the cable is very stiff and made stiffer by the addition of the foil so it is cleanroom safe. Several times today, I would pick up or set down the profiler and the head would swivel. I tried tightening the screw holding the post to the base, and I tried tightening the screw that holds the post to the head, but it is not tight enough to prevent swiveling. I found the best method was to line up the profiler in the designed location, and hold the head and cable in place while someone else ran the measurement. That makes this a minimum two person job, but there was enough juggling that having a third person was sometimes helpful.

When we went in around 3 pm to do the final measurement of the day I measured the particle count: 0.3u was 10 and 0.5u was 0. I used the standing particle counter on the +Y side of the HAM1 chamber- briefly unplugged to carry it over to the -Y side for the measurement. I didn't measure when closing up because Keita is heading out to do a few more tasks on HAM1. The handhelp particle counter isn't working, so we have to carry this large one on a stand around to use.

WFS sled is still excellent, 84 to 85 deg Gouy phase separation.

In the attached, four measurement points have error bars both in the position and the beam size but it looks negligible. There's no concern for WFS, it's good to go as is. 

However, just for the record, the astigmatism is bigger now (which is inconsequential in that ASC DOF separation is determined by the Gouy phase even if there's an astigmatism). The waist location difference is ~49mm now VS ~14mm or so before (just eyeballing the old plot from alog 8932) for a beam with the Rayleigh range of ~200mm. Not sure if this is the result of the AOI change or beam position change on curved mirrors and lenses, but I won't fix/correct this.

This morning we entered to do one more beam profile measurement. First Jennie and I refoiled the cable of the nanoscan profiler, since it was very stiff from multiple layers of foil. Then, before opening the cover to the table, I measured the dust counts by carrying the stand particle counter over to our working side like I did on Friday. The read was 0 and 0 for 0.3um and 0.5 um particles. I know it was working however, because as I carried the counter over outside the cleanroom it counted 19 each of 0.3 and 0.5 um particles.

Then, Jennie and I took one more beam profile measurement, this time on the LSC REFL path, after the final beamsplitter (M18). LSC REFL A (on transmission of M18) is placed on the table as in the drawing, but the LSC REFL B sensor (reflection of M18) was further away relative to the splitter. My quick rough measurement showed that LSC REFL B was about 160 mm away from M18.

I measured the distance of LSC REFL A to the front surface of M18 to be 128 mm. Then, I set LSC REFL B off to the side, and placed the profiler about 128 mm away from M18 on reflection of the splitter. We measured the beam profile, and then I re-placed LSC REFL B, this time at a distance of 128 mm to M18.

I have attached a very rough drawing of the REFL path and the locations where we made beam profile measurements. Each X on this drawing marks a beam profile measurement location. I also marked the Xs with letters A-G.

The measurements Keita reports above correspond the measurements C, D, E and F on this drawing. The difference between E and F, which is not depicted in my drawing, is a different placement of the temporary steering mirror relative to the sled.

 We still need to report details on the measurements for locations A, B, and G.

Beam size upstream of the WFS sled

Unfortunately this is preliminary.

We measured the beam size at 4 different location upstream of the WFS sled marked as A, B, C and D. D data cannot be used as there's no data/picture of D locaiton but that's fine as far as position A data is good. Unfortunately, though, the position A horizontal width looks narrower than it really is (2nd attachment). The beam might be clipping in the nanoscan aperture or there might be a ghost beam or bright background light in the Region Of Interest (ROI), or ROI is defined poorly, effectively clipping the beam. Must remeasure.

LSC REFL_B (and therefore REFL_A) beam radius is ~0.1mm, which is tinier than my preference, the diode is 3mm (in diameter) so the beam could be larger.  The diodes are placed close to the focus of the lens upstream (number 18 in a circle in the first attachment) so the beam won't move when the beam position moves on that lens. Moving away from that position will be fine as far as the deviation is much smaller than the focal length (~200mm). Rayleigh range is like 3cm or maybe smaller (0.1mm waist -> RR=10*pi mm),  it should be easy to double the beam size by moving the sensors away from the lens by a couple inches. We'll do this after POP alignment.

After everything is done we'll make a good measurement of distances between everything by either using a long/short ruler (preferred) or counting bolt holes or both.

Yesterday Betsy and I measured the distances between these optics:

• 856mm from RM1 to RM2, measured 827mm between the front D1000767 plate structure of each SUS and Don and Rahul measured on D1001396 the horizontal distance between plate and optic is 14.3mm for each RM1 and RM2.
• 895mm from RM2 to M5: Front of RM2 mirror to HR of M5 mirror
• 758mm from M5 to M6 (BS): HR of M5 mirror to front HR of M6 BS (-X side of M6)
• 468mm from M6 (BS) to 2" Lens on SLED: front HR of M6 BS (-X side of M6) to front side of 2" lens (0.5" thick lens holder, from siskiyou FOH 2", so add 0.25" if you want center of lens).

Camilla and I went back out today to redo the measurements at the locations labeled "A" and "D" in Keita's diagram. This table reports the D4sigma values, like Keita's tables above.

We forgot that we had left ITMX aligned, so the original measurements in this alog are no good. Keita and I remeasured these again today (May 6) and I am updating the table below with the new data. We also got two more measurements in new locations that are not indicated in Keita's diagram.

Leaving this older comment: It is difficult to measure these distances well with the ruler, so I would guesstimate error bars of a few mm on each distance measurement reported here.

Some new notes: when we reduce teh purge air flow, the measurements become much more stable and there is no need to "cherry pick" data as Keita discussed in earlier comments. Also, I think we have finally managed to tighten the screws on the nanoscan posts enough that it doesn't slide around anymore.