Sometimes it is around 5kHz.

The oscillation frequency seems to be around 2kHz - 2.7kHz. Not a single frequemcy.

When a step down signal is visible in the woofer FB signals (ALS-X_FIB_WOOFER_{OUT/IN1}), we can see a ~ 2.5kHz glowing up chirp signal in ALS-X_FIB_PDA1/2_OUT outputs. Should we inspect some mechanical resonances ?? The resonance fringe width is too large comapred with the Michelson full fringe width.

Or just loop instability due to less fringe width??

With Hirata-san.

After cleaning with First Contact (klog 21281), we released the suspension and found two security stop screws of the recoil mass touching the security structure beneath it (Fig. 1). The two other screws on the other side were not touching.

In order to fix this, we set the suspension in DAMPED state and moved the F0 yaw stepper motor until the oplev came into range. The screws were no longer touching the security structure (Fig. 2). The screws at the opposite side were also free (Fig. 3).

Ushiba, Dan, Nishino

Alignment improvement

We adjusted the alignment of Gr M4 (see POP layout) to maximize the error signal amplitude (Michelson fringe) and it was improved from ~1000 to ~2000 counts.

The lock was stable for ~1 hour in this state (without thermal feedback).

But after that, the lock became unstable and the error signal amplitude has become ~1000 counts again.

GRX DCPD calibration

Count: 1772 counts (bacground=5.5 counts)

Power right after the GR fiber: 9.93(1) mW -> calibration factor = 5.62e-3 [mW/count]

Power in front of the GRX DCPD: 0.71(1) mW -> calibration factor = 4.02e-4 [mW/counts]

Open-loop function of FIB servo

The measured open-loop function of the FIBX servo is below.

UGF is ~7.5 kHz and the phase margin is ~ 43 degrees.

We could see the tweeter's resonance at 58.912 kHz.

Small change; PDA1 the gain 

We noticed that the gain knob of PDA1 in the PSL room was halfway between 30dB to 40dB. We fixed it to 40dB and did not see any significant change in the output signal.

with Hirata-san, Fabian-san and checked by Miyoki-san

We removed four parts of FC on the HR surface and inspected it using green light.

Some FC stains could be cleaned successfully but unfortunately, some FC residues were still on the circumference line of the first FC.

It was not perfect, but we decided to finish this cleaning work.

Please confirm each picture.

https://www.dropbox.com/work/Subsystems/MIR/mirror%20inspection/SR3/20220627

DAQ Error Log Analysis

DAQ Timing Error.
Check the results of countermeasures against this error.

Analyze the DAQ log and check against the DAQ error.

Data
Fig.1 Comparison of Ask for retransmission error and DAQ_OK in 2022
Fig.2 Ask for retransmission error in 2022
Fig.3 K1:GRD-SYS_DAQ_OK in 2022

Fig.4 Comparison of Ask for retransmission error and DAQ_OK in 2021
Fig.5 Ask for retransmission error in 2021
Fig.6 K1:GRD-SYS_DAQ_OK in 2021

Figs. 1 and 4 are composites of 2, 3, 5, and 6, respectively.
Figs. 2 and 5 are graphs of daily totals of the number of "Ask for retransmission XX packet port 7097" errors and the number of packets in the DAQ log file, compiled by a script.
/users/DAQ/daqd_log_analize/daqdlogana.py
Fig.3 and 6 were obtained by specifying the period in ndscope.

Analysis

Fig.1-1
 DAQ and DGS LAN cables were exchanged.
 DAQ_OK seems to improve gradually during this period.

Fig.1-2
 The percentage of DAQ_OK errors increased around the time I removed the VIS dummy channel in K-Log#19981 on 3/3.
 Around 4/9, this was just a test that increased in frequency.

Fig.1-3
 DAQ server setting was changed to FIFO, but "Ask For..." errors occurred frequently.
 Later, the parent of daqd was also changed to FIFO, and the frequency decreased.

Fig.1-4
 The test was performed with DAQ's Swap disabled.
 "Ask For..." Fewer errors, but more error Packets at a time.
 DAQ errors appear to be decreasing.

Result.
What we know so far.

1. "Ask For..." The frequency of errors and the frequency of DAQ_OK errors do not necessarily match.
 However, "Ask For..." The frequency of errors and the frequency of DAQ_OK errors are similar.
 The number of packets has nothing to do with the error frequency of DAQ_OK. 
 
2. If the parent process of daqd is delayed, the frequency of "Ask For..." errors in k1tw0 and k1tw1 increases.
 This also does not necessarily increase the frequency of DAQ_OK errors. 

3. after changing all daqd to FIFO in K-Log#20717+21102.
 "Ask For..." The error situation changed.
 Before the change, fw0 always had an average of 100 errors.
 However, fw0's "Ask For..." errors decreased.
 And fw1 became worse.
 However, the number of packets per time has increased.
 We will see how it goes for about a week.

Date: 2022/6/27

I checked YPcal beam positions on ETMY at 7am today.

The both beams are still on the ETMY with a few cm shift from the designed positions.

DGS Regular maintenance day(6/24)

Stepper motor
 [Checked]
  Check if the power supply can be controlled by BIO
  Check if the script can be started
  Checked that the limit switches installed are green.
 [Check result]
  No problem
  ITMX is suspended for maintenance at other locations.

Release Sensor
 [Checked the Release Sensor.]
 Checked that Release Sensor is 0, 1: Seated.
 [Check result]
 ETMX, ETMY, ITMX, ITMY : No problem

Picomotor
 [Confirmation]
  PingTest is performed.
 [Result]
  Only known

 NG: 
  BS(IM)
   => Hang. Not Recovery.
  
  MCI,STM1,
  AS_WFS,POP_POM,POS_POM,POM1
  MCF(MCO,MCI)
   => Confirmation only, no recovery operation was performed.

 OK:
  ETMX,ETMY,ITMX,ITMY
  BS(BF),SRM(IM,BF),SR2(IM,BF),SR3(IM,BF,STM)
  PRM(IM,BF),PR2(IM,BF),PR3(IM,BF)
  MCE,IMMT1,IMMT2,OMMT1,OMMT2,OSTM
  REFL_WFS,POP,POP2,POS,POS2
  PCAL(EX1,EX2,EY1,EY2):Not checked because it is ON only when used

Temperature controller
 [Checked]
 Is the temperature acquisition working properly?

 [Check result] 
  Is the temperature acquisition working properly?
  => No problem

Precision air Processer
 [Check Contents]
 Is the temperature acquisition working properly?

 [Result]
  No problem

FunctionGenerator
 (Confirmation)
 Is there a ping response?
 Are all EPICS channels alive?
  [sitemap]-[Commissioning]-[ALS FG]-[Xarm],[Yarm].
 [Check result]
 X and Y PLLs are working properly.

HWP control PC
 (Confirmation)
 Check if it is possible to login to the control PC.
 (Result) 
 Both k1hwp0 and 1 are OK.
 

with Hirata-san, Fabian-san

Before removing the FC, we cleaned the floor again, and then we peeled off both FC and inspected the mirror again.

It looks pretty clean around the center of each side, but unfortunately, residues on the FC circumference remain on both sides respectively.

I don't know why this happened because I thought I had applied it the same way I always do...

Furthermore, some line stains, or scratches, on the upper right side of HR still remain. FC couldn't remove them.

https://www.dropbox.com/work/Subsystems/MIR/mirror%20inspection/SR3/20220624

After some discussion, we started to re-apply partially to remove these residues only on HR.

We are going to remove them and inspect the mirror again next Monday.

I offloaded the F2, F3, and BF keystones after the build-up.

I updated suspension models of BF, GAS, IM, and TM stages.
Models are set in FM10 of DAMP filters at each stage.

New models are based on the measurement in klog21260.

This is a continuation of the DAQ Timing Error investigation.

Overview.
The swapfile setting is enabled on each of the DAQ servers.
We believe that the required RAM capacity is sufficient for each server, so we check the situation by eliminating the swapfile.

In k1fw0 and k1fw1, the error packets are generated in daqd.fw*.log, so we check the frequency of occurrence here as well.
Ask for retransmission of 5 packets; port 7097

Work
1. Check existence of swap file
$ free

2. Check swap settings
$ sudo swapon -s
Confirm the output swap partition. 

3. comment out the swap partition in /etc/fstab
 Backup of original file: /etc/fstab.20220624 
 ex.
 #/swapfile none swap sw 0 0
 (do not delete the partition so that it can be recovered)

 Swap partition name :
 k1dc0, k1fw1, k1tw0, k1tw1, k1nds0, k1nds1, k1bcst0: /swapfile
 k1fw0: /dev/sda2

4. Reboot
 $ sudo shutdown -r now

Target
k1dc0, k1fw0, k1fw1, k1tw0, k1tw1, k1nds0, k1nds1, k1bcst0
k1nds2 is not changed.