Reports of 27597
VIS (SR3)
ryutaro.takahashi - 9:12 Monday 17 June 2024 (29934) Print this report
Offload of F0 GAS

I offloaded the F0 GAS with the FR.

VIS (SR2)
ryutaro.takahashi - 9:11 Monday 17 June 2024 (29933) Print this report
Offload of F0 GAS

I offloaded the F0 GAS with the FR.

VIS (OMM)
satoru.takano - 1:35 Monday 17 June 2024 (29932) Print this report
Comment to Simulation of OMC Stack (29931)

I did the same simulation with extra 155 kg weights. The results are summarized in the list below:

No. Frequency (+155kg) Frequency (+0kg) Shape
1 2.351 4.718 Common X
2 2.355 4.721 Common Y
3 3.157 4.891 Common Yaw
4 8.116 14.022 (Bottom, Mid)-Top Differential X
5 8.141 14.025 (Bottom, Mid)-Top Differential Y
6 11.135 14.142 (Bottom, Mid)-Top Differential Yaw
7 14.798 38.875 Common Pitch
8 14.823 38.999 Common Roll
9 17.828 20.658 (Bottom, Top)-Mid Differential Yaw
10 19.331 21.503 (Bottom, Top)-Mid Differential X
11 19.332 21.504 (Bottom, Top)-Mid Differential Y
12 26.063 40.128 Common Z
13 79.198 97.361 (Bottom, Mid)-Top Differential Pitch
14 79.733 97.761 (Bottom, Mid)-Top Differential Roll

 

Attached figures show the shape of each resonant mode. The color ndicates the displacement along x axis.

 

Images attached to this comment
VIS (OMM)
satoru.takano - 0:37 Monday 17 June 2024 (29931) Print this report
Simulation of OMC Stack

I simulated the resonant mode of OMC stack with Autodesk Fusion. I used drawings shown in the slides here as a reference of the CAD design. Young modulus of the rubber are estimated from the measured value reported in klog 29651 as 15 MPa. Poisson ratio is assumed to be 0.5, which is a typical values for rubbers. With these values, shear moduls is calculated by 5 MPa. In this simulation no extra load is added.

Here I summarized the resonant frequency and the corresponding mode in the list below:

No. Frequency Shape
1 4.718 Common X
2 4.721 Common Y
3 4.891 Common Yaw
4 14.022 (Bottom, Mid)-Top Differential X
5 14.025 (Bottom, Mid)-Top Differential Y
6 14.142 (Bottom, Mid)-Top Differential Yaw
7 20.658 (Bottom, Top)-Mid Differential Yaw
8 21.503 (Bottom, Top)-Mid Differential X
9 21.504 (Bottom, Top)-Mid Differential Y
10 38.875 Common Pitch
11 38.999 Common Roll
12 40.128 Common Z
13 97.361 (Bottom, Mid)-Top Differential Pitch
14 97.761 (Bottom, Mid)-Top Differential Roll

Attached figures show the shape of each resonant mode. The color ndicates the displacement along x axis.

 

Images attached to this report
Comments to this report:
satoru.takano - 1:35 Monday 17 June 2024 (29932) Print this report

I did the same simulation with extra 155 kg weights. The results are summarized in the list below:

No. Frequency (+155kg) Frequency (+0kg) Shape
1 2.351 4.718 Common X
2 2.355 4.721 Common Y
3 3.157 4.891 Common Yaw
4 8.116 14.022 (Bottom, Mid)-Top Differential X
5 8.141 14.025 (Bottom, Mid)-Top Differential Y
6 11.135 14.142 (Bottom, Mid)-Top Differential Yaw
7 14.798 38.875 Common Pitch
8 14.823 38.999 Common Roll
9 17.828 20.658 (Bottom, Top)-Mid Differential Yaw
10 19.331 21.503 (Bottom, Top)-Mid Differential X
11 19.332 21.504 (Bottom, Top)-Mid Differential Y
12 26.063 40.128 Common Z
13 79.198 97.361 (Bottom, Mid)-Top Differential Pitch
14 79.733 97.761 (Bottom, Mid)-Top Differential Roll

 

Attached figures show the shape of each resonant mode. The color ndicates the displacement along x axis.

 

Images attached to this comment
DGS (General)
takahiro.yamamoto - 18:24 Sunday 16 June 2024 (29930) Print this report
Investigation of the DAC output behavior of 2kHz model

[Ikeda, YamaT]
 

Abstract

After update of k1asc reported in klog#29916, DAC output for POP PZTs doesn't work due to the IOP DAC_KILL.
We found that this was caused by too large CPU_METER of k1asc and the limitation of CPU_METER for 2kHz model was ~122us not ~488us
by both code reading and actual TF measurement from DAC output on 2kHz model to one on 65kHz model.
This fact means that POP PZT and f3 WFS cannot co-exist in the current ASC model
 

Details

After the update for the f3 WFS on k1asc, DACKILL bit in the STATE_WORD and Timing error bit of DAC1 are enabled on k1iopasc. For this reason, k1asc doesn't output signal from DAC1 which is connected to the POP PZTs. CPU meter of k1asc is only ~160us (it's 2kHz model = 488us). So we couldn't understand why timing error occurred and we started to check the source code of RCG.

According to Ikeda-san's investigation, 65kHz IOP model seemed to read shared memory for DAC output with the latency as 8 samples (=122us) for 2kHz user models instead of 32 samples (=488us). In the case of 32kHz and 16kHz user models, IOP model reads with the latency as 2 (=31us) and 4 (=61us) samples which are the same cadence as the timing interval of user models, respectively.

In order to confirm our understanding about RCG code, we measured the actual transfer function from the DAC output on 2kHz model to one on 65kHz model. As the 2kHz model, we used SRM tower model and transfer function from K1:VIS-SRM_F0_COILOUTF_GAS_OUT to K1:IOP-SRM_MDAC0_TP_CH14 with the white gauss injection from K1:VIS-SRM_F0_COILOUTF_GAS_EXC in the READY state. At first, I injected 1 count rms because this measurement is noise less. But some kind of numerical error appeared and finally I increased injection amplitude as 10 count rms. Measured transfer functions and raw spectra of DAC output signals on 2kHz and 65kHz models are shown in Fig.1.

Measured transfer function doesn't have a flat (0dB, 0deg.) response because the digital Anti-Imaging on RCG (feCoeff32x in LIGO-T1500075), shared memory delay, and the digital Anti-Aliasing filter by diaggui for measuring TF with two channels that sampling rate are different each other (42-order least square filter in Table.1 of LIGO-T990013) are applied. These digital AA/AIs are shown in Fig.2. Figure 3 is an overplot of measured TF (blue), TF model with 488us delay (green curve) and one with 122us delay (red). As you can see, the model with 122us delay is better matched with measured TF than one with 488us. And also, a residual plot between the measurement and models (see Fig.4) shows that the 122us delay model well matches with measurement.

From these results, we can conclude that shared memory delay for 2kHz is 122us not 488us. Because writing DAC output value on memory is not a final process in the user model, CPU_METER value slightly larger than 122us is acceptable. But it must be much smaller than 488us. In fact, CPU meter value of k1asc was ~142us before the update of k1asc model as shown in the bottom panel of Fig.5 (see before t=-8d). But there was no error (DAC error bit shown on the top panel of Fig.5 shows 15). After the update of model, CPU meter increased to ~156us and DAC error appeared (value is changed as 15->13). So This fact seems to mean that post process of DAC value writing takes ~20-30us in the user model.

Anyway, we need to reduce much CPU load to enable the output for the POP PZT and it seems to be difficult to co-exist of POP PZT and WFS 3f in the current ASC model. Possible solutions at this time are as follows.
1. Preparation of a new dedicated model for f3 WFS
- I have no info. to evaluate the difficulty in this solution.

2. Change sampling rate of ASC model as 4kHz
- Though I'm not sure the reason why, delay of 4kHz model is 244us which is larger than 2kHz model according to the code inspection.
- Some decimation filters are optimized only for 16kHz and 2kHz models, so performance may become worse on models with other sampling rate.
- At least _OUT16 works properly only on 16kHz and 2kHz model.

3. Send POP PZT signal to other model (ADS, BPC, etc.) via shared memory and DAC output is done on these models
- The 488us delay is added for the output of POP PZT.
- CPU load of model itself increases.

4. Code hack of RCG
- All other 2kHz model is also affected and the delay as 366us is added for each control loop on 2kHz model.
- I'm not sure a same hack works well also on the future version of RCG.

Images attached to this report
VAC (General)
takahiro.yamamoto - 15:13 Sunday 16 June 2024 (29929) Print this report
log-log plotter for vacuum monitors

For the future evacuation and vacuum breaking, a log-log plot tool on MEDM was prepared.
This tool is available on the VAC_OVERVIEW screen as shown in Fig.1.
Scripts are in /opt/rtcds/userapps/release/vac/common/scripts/

-----
In the case that "gps time 2" is lager than "gps time 1", plot was made with data from "gps time 1" to "gps time 2".
Otherwise, a value in "gps time 2" works as duration since "gps time 1" for a positive value, and lookback time from "gps time 1" for a negative value.

Images attached to this report
VIS (IMM)
takafumi.ushiba - 14:54 Sunday 16 June 2024 (29928) Print this report
In-vac health check of IMMT2

I performed health check of IMMT2 (fig1-7).
All TFs have no significant change from the n-air health check, so they seem healthy.

Note:

TFs from each DoF EXC to Y have low coherence at 2-4 Hz.
It probably comes from the non-linearity of OpLev due to the large excitations.
Figure 8 shows the TFs when I introduced a notch at 1.5 Hz.
In that case, coherence at 2-4 Hz was recovered, so this low coherence is not a problem.

Images attached to this report
VIS (IMM)
takafumi.ushiba - 14:32 Sunday 16 June 2024 (29927) Print this report
In-vac health check of IMMT1

I performed health check of IMMT1 (fig1-7).
All TFs have no significant change from the n-air health check, so they seem healthy.

Images attached to this report
MIF (General)
takafumi.ushiba - 14:20 Sunday 16 June 2024 (29926) Print this report
Modification of INITIAL_ALIGNMENT guardian

I modified INITIAL_ALIGNMENT guardian so that it can be used in the current situation.
Now, XARM alignment seems working well.

The changes are as follows:
1. Change request to IMMT1 from LOCK_ACQUISITION to ALIGNED
2. Skip to request MISALIGNED state to ETMY.
3. Skip engaging ISS

Note:

I'm not so sure the reason but PR2 good OpLev value moves a lot (more than 100 urad) from Thursday. Is it due to the change of the height due to PR2 work (klog29918)?
Also, POPFORWARD QPD2 signals are far from the center in vertical.
GRX transmission is also slightly worse, so I moved POP PICO to recover the GRX alignment.

FCL (Air)
shinji.miyoki - 11:17 Sunday 16 June 2024 (29925) Print this report
Precision cooler (near SR2) temp setting change

Because the temp in the corner station seems to increase by ~ 0.6C from 11th June, I set the temp of the precision cooler near SR2 from 21.00 to 19.00 around 11am today.

By the way, the PSL PT data was lost in the PEM SEM page.

MIF (General)
takafumi.ushiba - 11:07 Sunday 16 June 2024 (29924) Print this report
Comment to IFO work 240615 (29921)

Sorry, it is my mistake.
I forgot to LOAD the corresponding guardians after changing the saturation check.
I loaded the guardians, and it seems working corerctly.

IOO (IMC)
takahiro.yamamoto - 19:23 Saturday 15 June 2024 (29923) Print this report
Comment to Modeling IMC Open loop transfer function (29752)
The analysis script used in the previous post in this thread is put in /users/Commissioning/scripts/NPRO_PZT_calibration/ (see also README in same directory).

I'm not sure same measurement will be done in the future, this script probably helps future calibration of IMC/CARM.
If the injection waveform including frequency, amplitude, etc. is changed, we may need to rewrite some parameters for the peak detection.
But it should work robustly with same injection parameters in README (10Vpp, 1Hz, triangle from K1:IMC-SERVO_OFS_SLOWOUT_CALI_EXC).
MIF (General)
takahiro.yamamoto - 14:12 Saturday 15 June 2024 (29922) Print this report
Comment to IFO work 240615 (29921)

Guardian log of SR3 from entering ISOLATING to requesting TWR_DAMPED is as follows.
2024-06-14_23:37:20.588149Z VIS_SR3 new target: ISOLATED
2024-06-14_23:37:20.592504Z VIS_SR3 executing state: ISOLATING (390)
2024-06-14_23:37:20.593021Z VIS_SR3 [ISOLATING.enter]
2024-06-14_23:37:20.803851Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS F1_DAMP_GAS BF_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:40.903045Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS F1_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:43.513733Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:45.148265Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T
2024-06-14_23:39:17.014395Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L
2024-06-14_23:39:43.405557Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS
2024-06-14_23:46:23.209870Z VIS_SR3 REQUEST: TWR_DAMPED
2024-06-14_23:46:23.224804Z VIS_SR3 calculating path: ISOLATING->TWR_DAMPED


As you can see, F0_DAMP_GAS wasn't calmed down. And then, checking error and feedback signals of SR3_F0 tell us F0_GAS_OUT was saturated before error signal reached around 0 (see also Fig.1).

-----
side story
Yesterday, Ushiba-kun enabled gas_notification for suspensions in the corner station. So this saturation should be informed on guardian and slack notification. VIS_params was surely modified. I doubt remaining bugs of gas_notification function at first. But I couldn't find a bug yet. And also, I couldn't find log of guardian load. Ushiba-kun might not load guardian after modifying parameters. If so, after loading guardian code, notifications will be enabled.

Images attached to this comment
MIF (General)
takaaki.yokozawa - 9:14 Saturday 15 June 2024 (29921) Print this report
IFO work 240615
I tried to check the GRY flash from the request of the ETMY closing acceptance check meeting.
But, SR3 cannot be ALIGNED state, I gave up today.
SR3 guardian stopped the isolating state and F0 GAS control cannot be performed stably. Should we set the stable temperature control in center area or some offload?

1. Before the GRY flash trial, I performed the Xarm alignment.
- Tweak the PR3 and PR2 manually to see the TEM00 lights in TMSX GigEs.
- Performed the ADS (IMMT2, PR2 and PR3) using guardian
- Tweak the ITMX and ETMX with checking the TCam image.
- Both GRX_norm and IR_norm value became almost 1 now and Fig.1. showed the TCam image.
- PR2 moved a lot
IMMT2 P : 50.6 -> 50.6
IMMT2 Y : -17.65 -> -17.6
PR2 P : -151.5 -> -178.6
PR2 Y : -85.8 -> -71.6
PR3 P : 9.0 -> 12.2
PR3 Y : -1.0 -> 1.1
ITMX P : 0.5 -> 3.5
ITMX Y : 1.5 -> -5.0
ETMX P : 12.0 -> 17.0
ETMX Y : -11.0 -> -9.6

2. GRY flash trial
- When I requested the ALIGNED state to SR3, SR3 guardian stopped the isolated state and found F0 gas control cannot be succeeded.
- I gave up the GRY flash trial today

[Homework]
- Check the status of the SR3 suspension
- Trial of (relatively) stable temperature control in center area
- GAS offload ITMX(F0)
- SR3 alignment check using TCam and single GRY light
- ETMY alignment check using GRY refl PD
- ITMY alignment check using GRY refl PD flash
- Check other Type-B suspensions for the future MICH lock trial
- Should we set the PDA again for the BS alignment or BS alignment using the IR reflection beam from ITMY?
Anyway, first step for processing the IFO commissioning, the commissioning for the Type-B suspension would be necessary.
Images attached to this report
Comments to this report:
takahiro.yamamoto - 14:12 Saturday 15 June 2024 (29922) Print this report

Guardian log of SR3 from entering ISOLATING to requesting TWR_DAMPED is as follows.
2024-06-14_23:37:20.588149Z VIS_SR3 new target: ISOLATED
2024-06-14_23:37:20.592504Z VIS_SR3 executing state: ISOLATING (390)
2024-06-14_23:37:20.593021Z VIS_SR3 [ISOLATING.enter]
2024-06-14_23:37:20.803851Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS F1_DAMP_GAS BF_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:40.903045Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS F1_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:43.513733Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T IP_DCCTRL_Y
2024-06-14_23:37:45.148265Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L IP_DCCTRL_T
2024-06-14_23:39:17.014395Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS IP_DCCTRL_L
2024-06-14_23:39:43.405557Z VIS_SR3 [ISOLATING.run] USERMSG 0: Now waiting RMS < 5: F0_DAMP_GAS
2024-06-14_23:46:23.209870Z VIS_SR3 REQUEST: TWR_DAMPED
2024-06-14_23:46:23.224804Z VIS_SR3 calculating path: ISOLATING->TWR_DAMPED


As you can see, F0_DAMP_GAS wasn't calmed down. And then, checking error and feedback signals of SR3_F0 tell us F0_GAS_OUT was saturated before error signal reached around 0 (see also Fig.1).

-----
side story
Yesterday, Ushiba-kun enabled gas_notification for suspensions in the corner station. So this saturation should be informed on guardian and slack notification. VIS_params was surely modified. I doubt remaining bugs of gas_notification function at first. But I couldn't find a bug yet. And also, I couldn't find log of guardian load. Ushiba-kun might not load guardian after modifying parameters. If so, after loading guardian code, notifications will be enabled.

Images attached to this comment
takafumi.ushiba - 11:07 Sunday 16 June 2024 (29924) Print this report

Sorry, it is my mistake.
I forgot to LOAD the corresponding guardians after changing the saturation check.
I loaded the guardians, and it seems working corerctly.

DGS (General)
takahiro.yamamoto - 0:06 Saturday 15 June 2024 (29920) Print this report
Update of cds workstations
I updated of some packages including security fixes.
Though a new version of ndscope is not distributed as deb binary package yet, I made a patch file from git codes and applied it.
Update of ndscope includes a function to enable t-cursor on all plots at the same time (see also Fig.1).

-----
Memo for maintainers
A patch file was made by the difference between two commits as 7a8748b8 (v0.18.0) and 554cdb87 (v0.19.3) in LIGO git. This patch file is save in /users/DGS/debian12/patches/.

For updating ndscope on Debian12 system, following commands are requires.
> cd /usr/lib/python3/dist-packages/ndscope/
> patch [--dry-run] -d ./ < /users/DGS/debian12/patches/ndscope_v0.18.0_v0.19.3.patch


Reverting version can be done by following commands.
> cd /usr/lib/python3/dist-packages/ndscope/
> patch [--dry-run] -R -d ./ < /users/DGS/debian12/patches/ndscope_v0.18.0_v0.19.3.patch


When a new version will be distributed as the deb binary package, it may be better to revert patched version before installing it by apt-get.
Images attached to this report
VIS (OMM)
tatsuki.washimi - 23:51 Friday 14 June 2024 (29914) Print this report
Comment to Stack TF measurement setup @ OMC booth (29778)

We performed the TF measurements for the OMC Stack3 (new) with vertical shaking before and after loading the additional weight (+155kg). The gaps between each stage were large enough and no
screw heads were touched (see pictures). 
After that, the TFs from vertical to the other DoF were also measured with the weight.
These data are uploaded on JGW-T2415845.

The TF of the new Stack3 without additional weight was a simple structure and good for comparing theoretical models.
The TF of the new Stack3 with +155kg weight had some peaks over 100 Hz. They might be couplings or mixing from the other DoF, caused because the position and angle of the weights were not perfect.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 20:34 Friday 14 June 2024 (29919) Print this report
Comment to Model file update (29916)
Latest situation of data streams are shown in the attachment.
It's better to move ~1MB/s from the primary NIC to the secondary NIC to take a balance among two ports.
Non-image files attached to this comment
VIS (PR2)
ryutaro.takahashi - 19:16 Friday 14 June 2024 (29918) Print this report
Comment to PR2 vertical OSEM is almost out of range. (29881)

I adjusted the height of the SF and BF keystone so that the IM V1 OSEM could be in the linear range. Though the BF setpoint was changed by -1500, the IM V OSEMs were changed by only 176~275. The deviation of the BFD V (+910) was also inconsistent with the SF setpoint change (+1500).

  Before [um] After [um]
IM V1 -461 -186
IM V2 -271 -95
IM V3 -254 -24
SF setpoint -3000 -1500
BF setpoint 862.8 -637.2
BFD V 154 1064

 

VIS (OMM)
ryutaro.takahashi - 18:51 Friday 14 June 2024 (29917) Print this report
Recovery of OSTM suspension

[Takahashi, Washimi, Ito]

We started the recovery of the OSTM suspension.

  1. Moved the OSTM suspension from the optical bench for the OMC to the workbench.
  2. Removed two shield plates (X+ and Y+) from the suspension frame. The plates were stored in the OMMT chamber.
  3. Removed the OSEMs with the support plates.
  4. Removed the mirror (TM). The mirror was stored on the small table with the table KOACHs.
  5. Removed the IM block and attached it to the hanging jig.
Images attached to this report
DGS (General)
satoru.ikeda - 17:46 Friday 14 June 2024 (29916) Print this report
Model file update

k1visetmxp, k1visetmynb k1visitmxp, k1visitmyp:.
k1visetmxnb, k1visetmynb, k1visitmxnb, k1visitmynb:

 Request from ushiba-san.
 Continued from K-Log#29795

 => Change 10 DOF to 5 each of 6 DOF

k1asc:.
 Request from Hirose-san (K-Log#29910)
 Only install & restart performed

 After the update, the DK of k1iopasc0 was red (error) from last week's update.
 There is no DAC1, so I tried to fix it, but it did not improve.
 k1asc_20240614_Final.mdl:NG
 k1asc_20230720.mdl:OK
 Delete PDA3 and 4 processing from k1asc_20240614_Final.mdl:OK
  => Time is running out today, will check next time

k1pemmanage: request from Yokozawa-san
 Only installation & reboot performed.

k1tmsx, k1tmsy:
 Only installation & reboot performed.
 

Non-image files attached to this report
Comments to this report:
takahiro.yamamoto - 20:34 Friday 14 June 2024 (29919) Print this report
Latest situation of data streams are shown in the attachment.
It's better to move ~1MB/s from the primary NIC to the secondary NIC to take a balance among two ports.
Non-image files attached to this comment
DGS (General)
shoichi.oshino - 17:20 Friday 14 June 2024 (29915) Print this report
Compressed log files of Ondotori
I compressed Ondotori logs through May for the following folders.
center, Front2f, px, mozumi, Xend1f
DGS (General)
Haoyu Wang - 14:35 Friday 14 June 2024 (29912) Print this report
Updates of RT model on k1tmsx and k1tmsy

[Yuta Michimura, Haoyu]

The Simulink RT models of k1tmsx and k1tmsy have been modified to add outputs and filters for the polarization monitoring PDs at end stations.

We added filters for the s-pol and p-pol PDs (the filter banks are modified from the tms library file). See Fig 1, Fig 2 and Fig 3. The models were built and compiled successfuly yesterday (not installed yet). They were supposed to be installed today.

Channel assignments for PDs at TMSX/TMSY are:

EX0_MADC0_EPICS_CH28: TRX s-pol
EX0_MADC0_EPICS_CH29: TRX p-pol
EX0_MADC1_EPICS_CH28: TRX IR
EX0_MADC1_EPICS_CH29: TRX GR

EY0_MADC1_EPICS_CH28: TRY IR
EY0_MADC1_EPICS_CH29: TRY GR
EY0_MADC1_EPICS_CH30: TRY s-pol
EY0_MADC1_EPICS_CH31: TRY p-pol

Images attached to this report
VIS (OMM)
tatsuki.washimi - 14:33 Friday 14 June 2024 (29913) Print this report
Comment to Preparation for hanging of optical bench (29837)

[Takahashi, Washimi, Ito]

In this morning, we performed the weight test for the new stacks:

  1. Measured the gaps for each rubber (top, middle)
  2. Loaded the weight: 153kg for the Stack1, 159kg for the Stack2, and 155kg for the Stack3
  3. Measured the gaps for each rubber (top, middle) again
  4. Constructed the safety jigs

The measured gaps and spring constants are plotted here.
The spring constant's mean and standard error(σ/√N) is 533±26 N/mm. (see also the Mitaka test: klog29651)

Images attached to this comment
DGS (General)
hirose.chiaki - 14:08 Friday 14 June 2024 (29910) Print this report
Changed the sampling frequency of channels for IQ demodulation and repaired the

As indicated in klog29820, the channel format in the DAQ block for IQ demodulation-related in REFL was html format, so it was repaired. 
Also, due to the increase in DAQ channels in the model update, the number of TRATE on the MEDM screen was 4179 and higher than 4096(Fig1), so the sample frequency for IQ demodulation-related channels was changed from 2048 to 512. It's now 2049.(Fig2, Fig3, Fig4)

Detail

  • One way to check the text format of a DAQ block is to check the Properties of the DAQ block. If it is not in HTML format, a field called ClickFcn will appear in Properties. This editing was done by editing the channel in the ClickFcn field.(Fig5)
    In my case, I used the klog draft function as a memo, created the channels all together and copied and pasted them from there into the DAQ block. It should be very careful because of the possibility of being HTML format.
Images attached to this report
DGS (General)
shoichi.oshino - 13:45 Friday 14 June 2024 (29911) Print this report
Fixed Ondotori scripts
Fixed a script that reads Ondotori data files and writes them to the EPICS channels.
Commented out lines related to digital racks.
Search Help
×

Warning

×