Displaying reports 1-20 of 86324.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 18:49, Thursday 22 January 2026
H1 ISC (ISC, SYS)
keita.kawabe@LIGO.ORG - posted 18:49, Thursday 22 January 2026 (88862)
JAC EOM mechanical problems (Elenna, Keita, with a help from Masayuki, MichaelL and StephenA)

We have identified two mechanical issues with the JAC EOM and its mount.

Issue 1. Crystal isn't captured in the EOM assembly when we install it in a certain way, but installing it in another way to capture it might (or might not) put overly strong force on the crystal.

No I haven't dropped the real crystal, I did drop alumina piece with the same outer dimensions as the RTP crystal while testing the installation procedure.

It's probably hard for you to understand this issue if you're not familiar with the EOM assembly (D2500130) and the assembly/test procedure (google doc), look at my super-simplified cartoon (ideal.png).

EOM comprises the face plate, RTP crystal and everything else. Everything else is already assembled. The task is to sandwich the RTP between the electrode board (which is a part of "everything else") and the face plate. You'll put the face plate on a table, put RTP on top of the face plate, carefully lower everything else until the board touches the RTP along its entire length, and you bolt the face plate to the side panels. Simple.

It can be much different from that if the board is not orthogonal to the side panels, look at the second attachment. Here, the board is crooked, the distance to the face plate on the output side is smaller than on the input side (this cartoon).

Suppose that I choose to make the face plate contact with the output side plate, and bolt the face plate down. The face plate is squared up relative to the side plate, not the board, and the "everything else" part will rotate away from the face plate (or face plate rotates away from everything else) and RTP is free to move. I think this is what happened consistently (10 or so trials) in the lab today, no matter what we did, the alumina piece (i.e. fake RTP for excercize) slid out of the assembly but only after tightening the screws.

On the other hand, if I choose to make the face plate contact with the input side plate (notsoideal.png), the rotation will be in the opposite direction, the face plate is not reqlly squared up but will put a pressure on the RTP, securely captureing it. After switching the side where the face panel contacts in the lab, the alumina piece (fake RTP) never dropped (3 trials so not much statistics but 3/3 success is much better than 10/10 failure).

The problems are that we don't have any control over how much force is applied to the crystal. Moreover, in our "successful" trials, the board might not be touching the alumina piece along its entire length. Look at the picture, this is after the last (3rd) "successful" attempt with the alumina piece still in, the board and the face plate are not parallel with each other, we might be pinching the alumina thing at the corner closest to the output side. Not sure if it's always like this but it's likely.

Stephen and Michael suggest that instead of bolting the face plate firmly to the input side, there could be a gap on each side, the face plate is supported by the tension of the screws, making sure that the face is parallel to the board. I'm not necessarily a fan of the idea but we'll try.

Issue 2. One of the bolts for the EOM base is blocked by another screw head.

See the last picture. One 1/4-20 screw cannot be tightened because the 10-32 bolt head just above that blocks access. We might replace the offending bolt with 10-32x0.375" pan head screw AND use the ball head Allen key for 1/4-20, that might work.

Other issues.

We can move the mount in PIT/ROLL and YAW, but somehow it's very difficult to cause pure PIT motion, it always couples to ROLL.

When we use set screws to tilt the base and then back them off, the mount won't return to the original position, I have to push down the pivot plate toward the base plate firmly, then there's a metal clicking sound and the mount goes back. This might be related to the fact that, as of now, the dowel pin (part #14 of the assembly drawing) is a REALLY tight fit for the pivot plate as of now. 

Finally, the cable strain relief post could not be set at a desired angle using the supplied slotted washer (the only difference I was able to make is either bad angle or 180 degrees off of the bad angle). But using other washers on top of the slotted one(s) I was able to manage good-ish angle.

Images attached to this report
H1 IOO
jennifer.wright@LIGO.ORG - posted 18:38, Thursday 22 January 2026 (88863)
Alignment to IOT2L through JAC

Jennie W, Jenne D, Masayuki N

 

Today Jenne and I went into HAM1 and onto IOT2L.

Our first priority was to check the input alignment to the JAC after alignment efforts yesterday to check we were not locking to a HOM mode. We locked the JAC with a power of 0.1 on the TRANS_A_LF_OUT channel.

I checked after lens JAC_L3 which is right before the steering mirror into the HAM1 output periscope. Here the beam looked like a 10 mode (two lobes in the horizontal axis). Further upstream (just after JAC cavity this was not obvious due to the beam size.

We used the steering mirror between the input periscope and JAC + the PSL periscope PZT mirror to improve the alignment. To do this we changed yaw in the closer mirror and pitch in the PSL PZT mirror as the input periscope switches the P and Y around.

We recovered a value of 0.22 on TRANS_A_LF_OUT which matches with the values we got on friday the last time we had a good TM00 lock on the JAC cavity.


After this Jenne went to the table to look at the beam we found yesterday which is at the edge of the MC REFL periscope mirrors in yaw and clips on the BS1 optic.

I started changing the tilt of the beam through HAM2 by changing the pitch of the mirror right before the HAM1 output periscope. This did not really change the beam position so we moved to a further away mirror (JM2) to translate the beam.

During this process we also became unable to lock the JAC using the guardian. More details at the end.

After some iteration we were able to see a beam on the MC REFL PD but have not been able to walk the beam to see any signals on the MC REFL WFS orflashing from the IMC on the MC TRANS PD.


After a break we went to the control room and did some checking of the MC sus alignments. We found problems with the alignment of MC3 - Dave and Ollie debugged this.

Jenne then did some walking of the MC mirrors and by moving MC1 she could get a larger signal on MC REFL. We might be able to use this tomorrow by moving MC1 to this 'wrong' ( ie. not consistent with the nominal IMC alignment before JAC was installed) place and walking MC1 back while changing the in-vac fixed mirrors in HAM1 to reover the beam on MC REFL PD.


During the day an electronics chassis was swapped that does the whitening for the TRANS PD A. The signal stopped getting to the diode so Daniel gave us the go-ahead to bypass this - this might need to be fixed properly at some point, it is level 10 on the rack closest to HAM1, next to the PSL enclosure. I took put IN3 and OUT 3 cables and connected them with a TNC connector.


This afternoon and evening we tried to trouble-shoot the JAC locking.

There was also an incorrect gain that got reset by the model restart for h1lsc earlier today but fixing this (JAC_DITHER_PD_IN gain was set to 200 and should be 4) did not allow us to lock.

After changing the servo gain in the dither lock Jenne noticed that this had no effect on the lock level/noise on the TRANS PD.

After checking with Masayuki the problem seems to be that the fast channel to drive the PZT is not connected somehow at the racks but the Beckhoff controller can be used to drive the PZT - will consult with Daniel/Marc tomorrow.

H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 17:42, Thursday 22 January 2026 (88861)
Summary of Conversion from SUSB123 & SUSH34 to SUSB13 & SUSB2H34 ('No QOSEMs/BBSS' Configuration)

Here is the summary with all the relavant alogs for the conversion from SUSB123 and SUSH34 to SUSB13 and SUSB2H34*.

*Our current configuration, specifically for SUSB2H34, is an interim state ("No QOSEMs/BBSS" config) on the way to the final O5 configuration, so SUSB2H34 doesn't fully match the cabling diagrams seen in D2300383. We can't fully upgrade to this O5 version yet because we don't have the BBSS, LO1, or LO2 installed yet, and need to be able to actuate the BSFM for the February commissioning period. To see what still needs to be done to get from this interim period to the final O5 configuration, see 88860 and google slides.

SUSB13 wiring diagram: D2300401
SUSB2H34 wiring diagram: D2300383

CER hardware changes88765
    AI chassis upgrades: 88766
    New power rail in SUS-C1: 88850
    Fix for failed untouched chassis: 88849
    BIO cable naming convention: 88852
    Renaming of SR3 OPLEV cable: 88837
    Updated SUS-C1/C2/C5/C6 rack photos: 88848
    Current status of SUS-C1/C2 racks vs Final O5 build: 88860
SUS Model Updates:
    ITMX: 88812
    ITMY: 88813
    ITMPI: 88818
    BS: 88814
    MC2: 88815
    PR2: 88816
    SR2: 88817
    AUXB123 -> AUXB13: 88819
    AUXH34 -> AUXB2H34: 88820
SUS Model Installation: 88781

H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 17:34, Thursday 22 January 2026 (88860)
Current Status of SUS-C1/C2 Racks vs Final O5 Build

J. Kissel, O. Patane, D. Barker, F. Clara, M. Pirello

Our big SUSB123 and SUSH34 to SUSB13 and SUSB2H34 upgrade last week wasn't the full upgrade for O5.
SUSB13 is fully upgraded to its O5 configuration, but for SUSB2H34, we can't fully upgrade to the final O5 build yet because we still need full control of the BSFM for the February commissioning period, whereas O5 will have the BSFM replaced with the BBSS (with QOSEMs instead of BOSEMs), requiring different electronics. The final O5 build will also include the electronics for the new suspensions LO1 and LO2. Going from the current configuration, which we call the "No QOSEMs/BBSS" configuration, to our final O5 build will require eight new chassis and two new ADC cards.

Since we will be needing to add/change things on the racks, that future upgrade will also come with user model additions/changes.

Table showing comparison diagrams

  Current “No QOSEMs/BBSS” Config Final O5 Config
Rack overviews slide31 slide33
DACs slide10 (excluding BS BOT/LO1/LO2 and AI in U13) slide10 (everything)
ADCs slide15 slide16
BIOs slide21 (excluding BS BOT chans) slide21 (everything)
AUX ADCs slide26 (excluding pink) slide26 (everything)

I've also attached the slides above in pdf form here. The full slides outlining all the changes O4 -> now -> O5 can be found here.

Changes needed to go from current configuration to final O5 configuration:
SUS-C1
    U33:: Remove cable inputs for (BSFM) BS M1 OSEM sensors, re-arrange cable inputs for BS M3 Oplev to make room for (BBSS) BS M3 OSEM sensors, and bring in PR3 M3 Oplev because we can
    U14:: Add (BBSS) BS M3 input for Binary Output
    U13:: Add (BBSS) BS M3 input for Binary Input
    U5 :: New D090006 TACQ Driver for (BBSS) BS M3

SUS-C2
    U22:: Add (BBSS) BS M3 Noisemon and (BBSS) BS M3 SFVmon inputs
    U20:: New D0902783 AA Chassis for LO1 M1 and LO2 M1 HAM-A Coil Driver Volt Monitors
    U16:: New D1300282 AA Chassis for (BBSS) BS M1 QOSEM sensors and LO1 M1 and LO2 M1 OSEM sensors
    U14:: Add (BBSS) BS M3 input to AI chassis
    U13:: New D2500353 AI Chassis for LO1 and LO2 Coil Actuation
    U9 :: New D1100687-v1 (100 Ohm Output Impedance) HAMA Coil Driver for LO1 M1 F1F2F3SD
    U8 :: New D1100687-v1 (100 Ohm Output Impedance) HAMA Coil Driver for LO1 M1 LFRTxxxx
    U6 :: New D1100687-v1 (100 Ohm Output Impedance) HAMA Coil Driver for LO2 M1 F1F2F3SD
    U5 :: New D1100687-v1 (100 Ohm Output Impedance) HAMA Coil Driver for LO1 M1 LFRTxxxx
    
susb2h34 IO Chassis
    Needs an additional ADC Card (and adapter card and internal SCSI cable)

susauxb2h34 IO Chassis
    Needs an additional ADC Card (and adapter card and internal SCSI Cable)

Images attached to this report
Non-image files attached to this report
H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 17:24, Thursday 22 January 2026 (88819)
SUS Model Updates: h1susauxb13

Jeff, Oli

We made several updates to multiple SUS simulink models as a continuation of our work converting SUSB123 and SUSH34 into SUSB13 and SUSB2H34 (88765). Our changes were based on our updated G2301306-v10_PARTII - for the conversion from SUSB123 into SUSB13 for SUSAUXB13, we referenced slides 23 and 24. These changes were svn'd as r34396 and were installed and started last week (88781).

These are the changes we had to made for h1susauxb13 (previously called h1susauxb123):

CDS Parameter Block:
- Changed hostname from h1susauxb123 to h1susauxb13
- Removed specific_cpu

Input (before, after):
- Removed BS block
- Removed ADC6 and ADC7
- ADC0 flag going into ITMY block is now in ADC5
- ADC7 flag going into ITMY block is now in ADC0

ITMY block (before, after):
- Removed ADC7
- Everything that was previously ADC0 is now in ADC5
- Everything that was previously ADC7 is now in ADC0

Images attached to this report
Non-image files attached to this report
H1 SQZ (SQZ)
karmeng.kwan@LIGO.ORG - posted 16:38, Thursday 22 January 2026 - last comment - 22:20, Thursday 22 January 2026(88847)
HAM7 progress

[Sheila, Karmeng]

We offloaded the saturation on ZM4 and ZM6 while maintaining the alignment to HAM6 QPDs.

Power budget: we measured 0.75mW at the OPO output, after SFI1, and after thin film polarizer. The power dropped to 0.74mW after BM3. And further to 0.71mW at the viewport/SQZT7 periscope and HD.

Scanned the IR and green transmission of the OPO, the green transmision (orange trace) will need further adjustmnet.

Images attached to this report
Comments related to this report
sheila.dwyer@LIGO.ORG - 22:20, Thursday 22 January 2026 (88864)SQZ

We spent most of yesterday and this morning recovering from the alignment shift that resulted from unlocking the VIP.  

Yesterday Ryan Short joined us and we worked on the path from the VIP to FC.  We now have the osems of FC1 and ZM2 (and ZM1yaw) back as they were in O4, and the beam centered on the iris right after ZM3.  The beam should be aligned to the filter cavity since it is retroreflecting off FC1 and FC1 should be pointing to FC2.  Since we only have the -Y door removed, we can't easily check the centering on ZM2 with a card; we set the alignment of ZM2 to match what it was in O4 and since the beam is centered on the ZM3 iris it should be at the position on ZM2 that it was in O4 (centered we believe).  We also had to spend some time to make sure that none of the suspensions were close to saturation.  While doing this we adjusted the pointing off the VIP using A:M1 and A:M2 (see VIP layout), which is why we had to readjust the co-alingment today, we also used A:M3.

This morning I made the final adjustments to get the beam centered on the ZM3 iris, and adjusted B:M4 to center the spot on the Z:M4 iris, and first iris on SQZT7, then also adjusted Zm4 and ZM5 to get the beam well centered on the SQZT7 irises.  Kar Meng and I sent the beam into HAM6 and we were able to run centering servos to adjust ZM4 + ZM5 to center AS_A and AS_B, but this saturated ZM4.  We then walked the beam using B:M4 so that it was a little high on the ZM4 iris (KarMeng has a photo 88859 to estimate how above center), but no suspensions are close to saturation.

Ryan Crouch ran OPO health checks, 88851, but wants to retake them with purge air turned down. 

After lunch we readjsuted the co-alignment of the green and IR (photos in 88859), and re-alinged the seed beam onto the RLF QPDs, which was needed because of the shift when unlocking the VIP.  With the seed beam we saturate the QPDs so we will need to revisit this and center using the CLF.  We then took photos of various things in chamber as Kar Meng has added in 88859.  

After all this we took one last peak at the beam going into HAM6, it was well centered on the AS_A, AS_B, and AS_C with our final alignment for about 30 seconds at 22:29:45, as shown in Kar Meng's screenshot.  This means that we are done using the viewport.

Things left to do in HAM7:

  • fine adjust alignment onto RLF QPDs (in laser hazard)
  • get a good cavity scan to show alignment of IR and green into OPO (in laser hazard)
  • dump beam going to OFI PDA
  • remove irises
  • unlock ISI + balancing
  • repeat OPO suspension checks

 

 

H1 General
ryan.crouch@LIGO.ORG - posted 16:33, Thursday 22 January 2026 (88858)
OPS Thursday Day shift summary

TITLE: 01/23 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: HAM7 OPO Laser Hazard work, EOM in the Optics lab, and HAM1 JAC/ISCT1 table work all continued today. VAC start working on the relay tube, they're just waiting on a work permit to remove the viewport from HAM5. 
LOG:                                                                                                                                                                           

Start Time System Name Location Lazer_Haz Task Time End
22:49 SAF LVEA IS LASER HAZARD LVEA YES LVEA IS LASER HAZARD \u0d26\u0d4d\u0d26\u0d3f(\u239a_\u239a) 16:49
16:01 FAC Nellie LVEA Y Tech clean 17:06
16:05 FAC Kim LVEA Y Tech clean 17:06
16:32 SQZ Sheila LVEA Y HAM7 work cont, OPO 19:55
16:53 FAC Randy LVEA Y Plug in Scissor lift and forklift 17:11
17:11 PEM Robert LVEA Y Laser vibrometer work, MCT baffles in and out 19:38
17:16 JOTE Matt, Sophie PREP lab N JOAT work 19:01
17:43 FAC Kim EndX N Tech clean 18:24
17:43 SQZ Kar Meng LVEA Y HAM7 OPO work 19:55
17:46 ISC Keita, Elenna Optics lab LOCAL EOM work 20:14
18:25 FAC Kim Midx N Tech clean 18:52
18:33 OPS Ryans LVEA Y Check with HAM7 crew 18:33
18:34 ISC Jenne, Jennie LVEA Y HAM1 JAC and ISCT1 work 20:41
18:57 VAC Jordan LVEA Y Grab some parts 19:05
19:14 EE Marc LVEA Y PSL racks, power supply swap 19:21
19:14 EE Daniel LVEA Y HAM6 rack surverying 20:41
19:34 SUS Jeff CER Y Take rack pictures, upper mezz 19:50
20:49 EE Marc LVEA Y PZT power supply swap 21:05
20:45 SUS Jeff CER Y Rack pictures 20:55
21:37 SQZ Sheila, Kar Meng LVEA Y HAM7 OPO work 22:55
21:58 ISC Jennie LVEA Y Check on laser 22:07
22:12 JOTE Matt PREP lab N JOTE work 22:42
22:19 ISC Jennie LVEA Y Add a connector 22:25
22:23 ISC Keita, Elenna Optics lab LOCAL EOM work 00:06
22:35 PEM Robert LVEA Y Laser vibrometry 23:01
23:11 VAC Jordan LVEA Y Relay tube work, HAM7 area 23:55
00:10 PEM Robert LVEA Y Laser vibrometer measurments 00:20
H1 SQZ (SQZ)
karmeng.kwan@LIGO.ORG - posted 16:33, Thursday 22 January 2026 (88859)
HAM7 and SQZT7 iris photos

[Sheila, Karmeng]

We took a bunch of photos on HAM7 and SQZT7 today, the IR-green coalignment is fixed. 

IR-green coalignment: on the iris between ZM3 and FC1 (before and after) and after AM3 (green and red overlap)

Beam position for all 3 irises placed in HAM7:

Iris 1 IR position on the iris placed between ZM1 and ZM2.

Iris 2 IR+green position on the iris placed between ZM3 and FC1.

Iris 3 IR position on the iris placed between BM4 and ZM4, with "RL" on the Thorlabs IR card placed on the iris as a reference to estimate the deviation from the center of the iris.

For 2 irises placed on SQZT7 HD path:

Iris 1 IR position on iris1 on SQZT7.

Iris 2 IR position on iris2 on SQZT7.

We also checked the IR on HAM7 QPDs path, the IR is off centered on the lens (seen from both front and back). This was roughly centered, and will be fine tuned with the picos.

Images attached to this report
H1 SUS
ryan.crouch@LIGO.ORG - posted 14:23, Thursday 22 January 2026 (88851)
OPO health check TFs

I ran some TFs on the OPO to do a health check, some things to note... The ISI was locked and tripped, we were in air, and the suspension's damping loops were on. I left its CD state as 2 as this SUS has its coil driver jumpered. 

Things look pretty noisy overall so its hard to say, I was struggling a bit to get good coherence without causing overflows, maybe due to the purge air? Especially with my L measurement, the next worse coherence was in T. I also noticed that H3s counts dropped quite a lot 2 days ago, over 10k counts.

I'd like to retake the whole measurment with the purge air turned down.

/ligo/svncommon/SusSVN/sus/trunk/OPOS/H1/OPO/SAGM1/Data
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_L_0p02to50Hz.xml
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_P_0p02to50Hz.xml
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_R_0p02to50Hz.xml
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_T_0p02to50Hz.xml
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_V_0p02to50Hz.xml
2026-01-22_2000_H1SUSOPO_M1_WhiteNoise_Y_0p02to50Hz.xml

Images attached to this report
Non-image files attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 13:27, Thursday 22 January 2026 - last comment - 13:35, Thursday 22 January 2026(88854)
h1lsc model and DAQ restart

Jennie, Jonathan, Erik, Dave:

The h1lsc model was edited by Jennie to add a fast DQ channel to the DAQ at 2kHz (H1:JAC-TRANS_A_LF_IN1_DQ).

DAQ and EDC were then restarted for:

1. New H1LSC.ini

2. New H1EPICS_CP1.ini (add plotting thermocouple channels)

3. New H1EPICS_ENV.ini (remove MY channels)

4. New daqd code to install duplicate channel checking

The DAQ was restarted in several stages because of the daqd code change.

Comments related to this report
david.barker@LIGO.ORG - 13:35, Thursday 22 January 2026 (88855)

Thu22Jan2026
LOC TIME HOSTNAME     MODEL/REBOOT
11:34:19 h1lsc0       h1lsc       <<< LSC restart


11:35:13 h1daqdc1     [DAQ] <<< 1-leg first restart
11:35:25 h1daqfw1     [DAQ]
11:35:26 h1daqtw1     [DAQ]
11:35:28 h1daqnds1    [DAQ]
11:35:36 h1daqgds1    [DAQ]


11:36:06 h1susauxh56 h1edc[DAQ] <<< EDC restart
11:37:53 h1daqgds1    [DAQ] <<< GDS1 needed a second restart


11:39:39 h1daqnds0    [DAQ] <<< 0-leg manual restart out-of-order
11:39:44 h1daqnds0    [DAQ]
11:40:53 h1daqtw0     [DAQ]
11:41:39 h1daqfw0     [DAQ]
11:43:02 h1daqgds0    [DAQ]


11:43:15 h1daqgds0    [DAQ] <<< 0-leg regular restart
11:43:21 h1daqfw0     [DAQ]
11:43:22 h1daqnds0    [DAQ]
11:43:22 h1daqtw0     [DAQ]


11:50:46 h1daqdc1     [DAQ] <<< second 1-leg restart to sync run-number
11:50:57 h1daqfw1     [DAQ]
11:50:57 h1daqtw1     [DAQ]
11:51:00 h1daqnds1    [DAQ]
11:51:10 h1daqgds1    [DAQ]
 

H1 SUS (CDS)
jeffrey.kissel@LIGO.ORG - posted 13:21, Thursday 22 January 2026 (88852)
Cable Label Convention for SUS BIO Cables; Re-labeled susb13's cables and Labeled susb2h34's cables
J. Kissel, O. Patane

In support of last week's CER / Electronics / Rack changes to move the Beam Splitter electronics over from the susb123 / SUS-C5 & C6 system to become a part of the expanded susb2h34 / SUS-C1 & C2 system (LHO:88765) we were re-mapping the beam splitters Binary IO Card system from the former susb123 to the new susb2h34 system.

In the susb123 system, the Beam Splitter shared it's BIO system with the ITMs' TST/L3 stage ESD Drivers. That meant that we couldn't migrate the electronics and cards to susb2h34 like the other parts of the beam splitter control system. So, a new BI and BO chassis were installed in SUS-C1, and a new BIO card was installed into the susb2h34 IO chassis. The 2x PCB100WS (HDRA100 to 2xD37 pigtail) cables that connect to/from the BIO card from/to the BI and BO chassis were also new.

However, the SUS wiring diagrams have never really depicted these BIO cables well, and thus didn't establish a cable naming convention. Worse, even though the PCB100WS pigtail cables connect into different places with different orientations w.r.t. the BIO card (which has two HDRA100 100-pin outputs), the cables themselves are identical. Further, the BIO card ends are in one rack (with the IO chassis) and the BI / BO chassis ends are in an (adjacent, but) different rack. These facts makes it really tough to follow or connect new additions if the existing system is poorly labeled and there's no written-down convention established.

Thankfully, there were hints of a convention on a few cables of the susb123 system, namely 
    SUS_${BI/BO_DestinationRack}_${BI/BO_DestinationUHieght}_${OUT/IN}
BUT -- 
    (1) The labels that were there only labeled one of the two pigtails so which was "CNA" connecting to the Lower 32 Bit BO/BI chassis input and which was"CNB" connecting to the Upper 32 Bits was very unclear, and 
    (2) at some point in their history the BI/BO destination u-heights for the BIO0 and BIO2 cards were flip-flopped.

So, I improved the convention to include the _CNA and _CNB, such that the cable naming convention is now 
    SUS_${BI/BO_DestinationRack}_${BI/BO_DestinationUHieght}_${OUT/IN}_${CNA/CNB}
and drew it up in an Altium-like set of google slides -- see attached "after" BIO diagrams that represent the susb13 and susb2h34 systems now after the 2026-01-13 rack work.

Oli's going to work on adding this convention to all the actual Altium wiring diagrams, D2300401 for susb13 and D2300383 fr susb2h34.

In in the mean time, I spent some quality time with a label maker and re-labeled all the susb13 cables and labeled all the susb2h34 cables. Note -- for the susb13 system, I didn't move any cables, but since I had to relabel the cables anyways to add the CNA/CNB extension, I just relabeled all the cables. As such, the unchanged susb13's BIO cables now match convention again, where the BO/BI chassis destination U-height is correctly assigned to the cable name.

Pictures attached:
susb13:
    SUS-C5_BIOCables_Labeled.jpg # IO Chassis End in SUS-C5
    SUS-C6_BIOCables_Labeled.jpg # BO/BI Chassis End in SUS-C6

susb2h34:
    SUS-C2_BIOCables_Labeled.jpg # IO Chassis End in SUS-C2
    SUS-C1_BIOCables_Labeled.jpg # BO/BI Chassis End in SUS-C1
Images attached to this report
Non-image files attached to this report
H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 12:22, Thursday 22 January 2026 (88818)
SUS Model Updates: h1susitmpi

Jeff, Oli

We made several updates to multiple SUS simulink models as a continuation of our work converting SUSB123 and SUSH34 into SUSB13 and SUSB2H34 (88765). Our changes were based on our updated G2301306-v10_PARTII - for the conversion from SUSB123 into SUSB13 for the ITM PI's, we referenced slides 5 and 7. These changes were svn'd as r34388 and were installed and started last week (88781).

These are the changes we had to make for h1susitmpi:

CDS Parameter Block:
- Changed hostname from h1susb123 to h1susb13
- Removed specific_cpu

Output (before, after):
- Change 20 bit DAC into a 28 bit DAC
- Wire up ITMX and ITMY PI OSEM outputs to their corresponding DAC channels

Images attached to this report
Non-image files attached to this report
H1 CDS (FMP, SUS)
jeffrey.kissel@LIGO.ORG - posted 12:21, Thursday 22 January 2026 - last comment - 13:04, Thursday 22 January 2026(88850)
Supporting SUS BS Electronics Moving into SUS-C1: Additional +/-18V DC Power Rail Installed, SUS-C2's Power Supply Feeds It
J. Kissel, F. Clara, M. Pirello
D2300167 Record of LHO DC Power Supply System
S1301897 VDC-C1 Rack S-number
S1301868 SUS-C1 Rack S-number
WP:12962

In support of last week's CER / Electronics / Rack changes to move the Beam Splitter electronics over from the susb123 / SUS-C5 & C6 system to become a part of the expanded susb2h34 / SUS-C1 & C2 system (LHO:88765) we needed more +/-18V DC power to support the incoming chassis into SUS-C1. 

We already knew in 2023 that SUS-C1's +/-18V power supplies in VDC-C1 U2 were already supporting a lot of current draw from the existing MC2, PR2, SR2 chassis in SUS-C1. However, the original 2023 plan (see page 10 of Part II of G2301306-v9) involved stretching power cables across from the chassis in SUS-C1 to the empty spigots available in the relatively unpopulated SUS-C2's +/-18V power rail. But, when the day came, we'd not remembered that plan, and the existing chassis power cables weren't long enough to make the rack jump. 

So, we did a "good enough for now" solution: installed a new +/-18V power rail into SUS-C1, and still powered it with the supplies for SUS-C2 in VDC-C1 U6, but connected the new SUS-C1 rail to it by modifying the junction box on top of the SUS-C2 rack. 

In doing so, we identified that the existing power supplies for SUS-C2 were on the list for replacement, so we replaced the U6 power supplies before making the connection.
               +18V           -18V
Removed       S1201904      S1201905
Installed     S1201909      S1201908

I've updated the VDC-C1 rack S-number, and SUS-C1 rack S-number to reflect these changes, but haven't touched the Record of LHO DC Power Supply System (links to these things above).

Prior to replacement, we measured the voltage supplied to be +18.81 [V] and -18.66 [V], and set the new supplies to that voltage after install. The new supplies measure the current draw what it supplies (All of SUS-C2 and the BIO chassis and Coil Drivers for the Beam Splitter) to be ~10 and 8.5 [A].

Ideally -- and what may be necessary -- is to install a new set of power supplies to support these two racks: we still need one more TACQ driver in SUS-C1 (which will use these VDC-C1 U6 supplies), and the planned, fully outfitted SUS-C2 which includes 7x more chassis. I bet those chassis will draw at least, if not more than, 5 [A] worth of current at +/-18V.

Pictures relevant to this install attached.
Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 13:04, Thursday 22 January 2026 (88853)
Labeled picture of SUS-C1 and SUS-C2 Junction Boxes showing the new SUS-C2 junction box's connection to SUS-C1.
Images attached to this comment
H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 12:21, Thursday 22 January 2026 (88820)
SUS Model Updates: h1susauxb2h34

Jeff, Oli

We made several updates to multiple SUS simulink models as a continuation of our work converting SUSB123 and SUSH34 into SUSB13 and SUSB2H34 (88765). Our changes were based on our updated G2301306-v10_PARTII - for the conversion from SUSH34 into SUSB13 for SUSAUXB2H34, we referenced slides 25 and 26. These changes were svn'd as r34398 and were installed and started last week (88781).

These are the changes we had to made for h1susauxb2h34 (previously called h1susauxh34):

CDS Parameter Block:
- Changed hostname from h1susauxh34 to h1susauxb2h34
- Removed specific_cpu

Input (before, after):
- Added ADC6 and ADC7
- Added BS block (taken from susauxb123)
- Connected ADC6 and ADC7 to BS block

BS Block (after):
- Connected up ADCs according to slide 26

Images attached to this report
Non-image files attached to this report
H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 12:20, Thursday 22 January 2026 (88814)
SUS Model Updates: h1susbs

Jeff, Oli

We made several updates to multiple SUS simulink models as a continuation of our work converting SUSB123 and SUSH34 into SUSB13 and SUSB2H34 (88765). Our changes were based on our updated G2301306-v10_PARTII - for the movement of the BS from SUSB123 to SUSB2H34, we referenced slides 5, 10, 12, 15, 18, and 21. These changes were svn'd as r34436 and were installed and started last week (88781).

These are the changes we had to make for h1susbs:

CDS Parameter Block:
- Changed dcuid
- Changed hostname from h1susb123 to h1susb2h34
- Removed specific_cpu

Input (before, after):
- Removed ADC1 since now all OSEM channels are on one ADC (called ADC1 in diagrams)
- Redid ADC to OSEM configuration
- Removed ITMX L3 and ITMY L3 channels from SHMEM that came in for ITM L3 BIO
- Added BS BIO channels for each BS stage (coming in from MC2) to SHMEM since the BS BIO is now on the MC2 model
- Redid BIO MON stage inputs into BS block to now read in values from SHMEM
    - MCDIO_2_BSM3 is terminated since current BS block doesnt have an M3 BIO

Output (before, after):
- Changed DACs from multiple 20 bit DACs to one 28 bit DAC
- Lined up outputs to their corresponding DAC channels
- Removed ITMX and ITMY L3 BIO channels that went out to ITMX and ITMY from SHMEM
- Added BS BIO channels for each BS stage (going out to MC2) to SHMEM since BS BIO is now on the MC2 model
- Redid BIO CTRL OUT outputs from BS block to now go out to SHMEM channels
    - BS M3 has a 0 coming in for now since current BS block doesn't have an M3 BIO

Binary I/O (before, after):
- Removed BIO blocks since BS BIO is now happening in the MC2 model

Images attached to this report
Non-image files attached to this report
H1 SUS (CDS)
oli.patane@LIGO.ORG - posted 12:17, Thursday 22 January 2026 (88816)
SUS Model Updates: h1suspr2

Jeff, Oli

We made several updates to multiple SUS simulink models as a continuation of our work converting SUSB123 and SUSH34 into SUSB13 and SUSB2H34 (88765). Our changes were based on our updated G2301306-v10_PARTII - for the conversion from SUSH34 into SUSB2H34 for PR2, we referenced slides 8, 10, 14, 15, 20, and 21. These changes were svn'd as r34387 and were installed and started last week (88781).

These are the changes we had to make for h1suspr2:

CDS Parameter Block:
- Changed hostname from h1sush34 to h1susb2h34
- Removed specific_cpu

Output (before, after):
- Changed DACs from multiple 18 bit DACs to one 20 bit DAC and one 28 bit DAC
- Lined up outputs to their corresponding DAC channels

Images attached to this report
Non-image files attached to this report
H1 SUS (CDS, IOO, ISC, SUS)
jeffrey.kissel@LIGO.ORG - posted 14:09, Wednesday 14 January 2026 - last comment - 13:58, Thursday 22 January 2026(88765)
CER Hardware/Electronics Changes To Convert SUSB123 and SUSH34 to SUSB13 and SUSH34 Complete; User Model Software Changes Commencing
J. Kissel, F. Clara, O. Patane, M. Pirello, D. Barker
ECR E2500296, E2400409
WP 12962
D2300401 (for susb13) and D2300383 (for susb2h34)
G2301306 -- PARTII 2023 plan, PARTII Update 

We've completed all electronics hardware moves, cabling/recabling and new installations that we plan to do on SUS MC2, PR2, SR2, BS, and the future LO1 and LO2 for now.

Given that this change to the electronics is somewhere in between versions of the D2300401 h1susb13 and D2300383 h1susb2h34 wiring diagrams -- the interim configuration we're in now that 

    Does have
        - susb2h34 and susb13, as well as susauxb13 and susauxb2h34 with all their ADC and DAC cards, as they will be in O5.
        - All of the BS electronics have been moved from SUS-C5/SUS-C6 to SUS-C1/SUS-C2, and their CER cabling dragged along with it
        - all AI chassis driven by 28-bit 32CH DACs (7 in total) have been converted from a pair of D1000305 2x8CH DAC AIs to a pair of D2500353 1/2x32CH DAC AIs.
        - ITM AA chassis inputs (both OSEM sensors, optical levers, and CD monitors) and AI chassis outputs have been re-arranged such that the grouping is far more sensibly arranged and modular per QUAD.
    
    Doesn't have 
        - BBSS-like BS TOP mass converted to QOSEMs
        - BBSS-like BS M3 OSEM sensing and actuation electronics
        - Any LO1 or LO2 electronics
        - The BS optical lever in its final AA chassis position (because the BS TOP mass OSEMs still need that spot)
        
        - Any changes to the field cabling
            - the BS M1 satamps, M2 satamps, and M3 optical lever whitening chassis are all still in SUS-R6)
-- we planned /documented all of this work on google slides -- see PARTII Update -- which is linked in the abstract of G2301306.

We'll add more details, gotchas, and pictures below in the comments.
Comments related to this report
oli.patane@LIGO.ORG - 13:58, Thursday 22 January 2026 (88856)

Here's some overview diagrams of how the racks were set up before (O4 configuration) and how they are set up now. SUSB13 (SUS-C5/C6) is in its final O5 configuration but SUSB2H34 (SUS-C1/C2) is in an interim ("No QOSEMs/BBSS") configuration. These diagrams are also available in the PARTII Update linked in the original post.

SUSB13
O4 Configuration (SUSB123)
Now - O5 Configuration (SUSB13)

SUSB2H34
O4 Configuration (SUSH34)
Now - "No QOSEMs/BBSS" Configuration (SUSB2H34)

Images attached to this comment
Displaying reports 1-20 of 86324.Go to page 1 2 3 4 5 6 7 8 9 10 End