The JAC seems to be failing to lock. I'm not sure why, but since it's just scanning I assume it's fine for the night. But, if someone with more JAC experience thinks it's useful to log in and set it to DOWN for the night, that would be good.
TITLE: 03/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
Hard closing GV7 continues (no luck today). New platform craned into place between BSC2+3. Filter Cavity gate valves opened for more Squeezer alignment. Lots of cable/fibers pulled in the LVEA. Optics Lab was busy with Team SPI & Team BHSS work (as well as Team CHETA lab next door).
LOG:
J. Oberling, R. Crouch
In talking with Calum about the upcoming pre-deintall BS measurements, I realized that in the middle of JAC install I completely forgot to write an alog about the WBSC2 support tube FARO survey Ryan and I did at the beginning of February. So, here it is.
Following the same procedure we used to survey the support tubes for WBSC3 and the +X ends of WBSC2 (alog 88620), we surveyed the -X WBSC2 support tube ends. The results are shown in the 3 attachments; the first 2 are in the LHO Global Coordinate system and are the images I will be discussing. The 3rd attachment contains all info from the first 2, but in the Corner Station building Local Coordinate system (included for completeness; for more on LIGO coordinate systems, see T0900340). The first attachment shows the surveyed locations of the support tube ends, while the 2nd shows information regarding the midpoint location of the support tubes and their angles w.r.t. the IFO axes (the line shown represents the centerline of the support tube created from one end point to the other; the Nominal column (Nom) comes directly from the CAD model, while the Measured column (Meas) is our measured data. Some interesting things to note here:
Now keep in mind that the support tube locations may not be indicative of a misalignment of the BS optic itself. When we installed this we only cared about putting the BS where it needed to be, and HEPI (and by extension the support tube ends) was wherever it (they) needed to be to support that. We will be taking measurements of the BS SUS cage and the optic itself once the corner is vented (likely to be one of the 1st activities after the vent), and we'll know more about the location of the BS optic once we have done so.
(Travis S., Jordan V., Richard M., Gerardo M.)
Last Friday we tried to "hard close" GV7, but we only achieved a "soft close" status. After looking at the system that uses instrument air at the gate valve, we did noticed that the solenoid valve to "open" and "close" the gate valve was "leaking" air, lots of instrument air, to fix the air leak we decided to replace the solenoid valve with a new one.
Then when it was time to "hard close" GV7, its pressure regulator broke, we were not able to open the regulator. We ordered a couple of new regulators and should be here on Wednesday. Meanwhile we are going to "hard close" the gate valve using a bottle of nitrogen.
Attached is a photo of the broken regulator, yes the knob is off, but the metal piece within is free floating and not able to do its job.
(Travis S., Jordan V., Richard M., Gerardo M.)
We bypassed the gate valve instrument air regulator and feed bottled air to the gate valve actuation system directly. We continued where we left off, and just continued to apply pressure to the system in an attempt to "hard close" the gate valve, and a second approach was to open the gate valve and close it again.
Leaky sound noted, we did noticed that when we are on the "close" setting, there is lots of hissing sound coming from one of the "relief ports" at the solenoid valve, but when we are on the "open" setting, there is no hissing at the solenoid valve. And if there is is very small.
We previously reported that the wiring to ground on the OMCA DCPD dsub9 cables seemed odd, see 89562. There appears to be two conflicting diagrams of the pin wiring, D2200276 and D2300119. Neither of these diagrams follow the correct pin naming practice either.
Today, Oli and I checked the ground connectivity for the OMCB DCPD dsub9. The case ground is wired to what is labeled pins 6 and 9, according to both of the diagrams above and also proper convention. However, this is different from OMCA, where the case ground is wired to pins 2 and 5 (following the incorrect naming of the diagrams above), or pins 1 and 4 (following correct naming conventions).
So either way, we have two different wiring set ups for OMCA and OMCB. We have only checked the ground pins so far, and it seems like we should confirm the cathode and anode wiring as well.
To summarize:
- we have two different diagrams for pin wiring
- OMCA and OMCB are wired differently from each other
- the diagrams are not following proper pin naming convention which is making this more confusing
Two problems with the drawings.
1. Case grounding.
As for cable and connection drawings, D2200276-v4 wiring diagram specifies that pin1-2 and pin4-5 twisted pairs carry the photocurrent, pin1 and pin4 being cathode, and case grounds are routed to pin6 and pin9, between DCPDs and the in-vac DCPD frontend. See the 1st attachment.
D2300118 DCPD to DB9M cable doesn't agree with the wiring diagram, it routs the case grounds to pin 2 and pin 5. See the 2nd attachment.
D1300369 DB9F-DB9F cable drawing agrees with the wiring diagram in that pin1-2 and pin4-5 are twisted pairs.
D2000592-v3 in-vac DCPD frontend seems to be compatible with the wiring diagram in that it routs the pin6 and 9 to the ground.
So, D2300118 DCPD to DB9M cable drawing is singularly incompatible with others.
Below is a summary table of the above together with reality check of the DCPD-DB9m cable. It seems that there's no way OMCA cable works. Anode/Cathode check wasn't performed (yet).
| pin1 | pin2 | pin6 | pin4 | pin5 | pin9 | |
| D2200276-v4 wiring diagram | Cathode1 | Anode1 | Case1 | Cathode2 | Anode2 | Case2 |
| D2300118 DCPD to DB9M cable | Cathode1 | Case1 | Anode1 | Cathode2 | Case2 | Anode2 |
| D1300369 DB9F-DB9F cable (pass through) | compatible with the wiring diagram in that pin1-2 and pin4-5 are twisted pairs. | |||||
| D2000592-v3 in-vac DCPD frontend (outside of the enclosure feedthrough) |
Internally routed to PD1 pin1 |
Internally routed to PD1 pin2 |
Internally routed to GND |
Internally routed to PD2 pin1 |
Internally routed to PD2 pin2 |
Internally routed to GND |
| OMCA reality | Case | ? | ? | Case | ? | ? |
| OMCB reality | ? | ? | Case | ? | ? | Case |
2. Polarity of the diode seems to be wrong.
Assuming that the wiring diagram and the in-vac DCPD frontend circuit diagram are both correct, cathode1 and anode1 are routed to "PD1 pin1" and "PD1 pin2" while cathode2 and anode2 are routed to "PD2 pin1" and "PD2 pin2". So, pin1 and pin2 inside the frontend chassis are cathode and anode. Again look at the first attachment.
However, whey you look at the circuit diagram of the frontend (3rd attachment), pin2 is connected to the positive bias and pin1 is grounded (via the huge inductor). This means that the PD is forward-biased and will be unusable. Is this only in the drawings?
What to do.
First thing is to check the diode polarity in reality, i.e. if cathode is routed to pin 1 and 4 (which I expect) or to pin 2 and 5 (which I don't expect). In parallel, check with Ali/Dean that my assessment of the polarity makes sense or not.
Depending on the results of the polarity investigation, we'll determine which cable needs to be reterminated how. If we're lucky we'll just reterminate only one cable, but if the PD polarity is indeed wrong we'll have to reterminate all cables.
Here is a further update. This is based on conversations with Keita and Betsy, and emails to and from CIT and LLO.
At first, it appears one issue here is that I have made a mistake OMC placement, as D2200276 indicates that OMCB should have the DCPD cable labeled D2300119 (and PZT cable D2300121), and OMCA should have D2300118 (and PZT cable D2300120), and I installed them opposite according to the DCPD cables. This doesn't account for the wiring issue; it would only make a cable length difference.
Oli and I went into the lab to swap around OMCA and OMCB, and realized that one OMC has the DCPD cable for A (D2300118) and PZT cable for B (D2300121) and vice versa. So it's not clear which is which.
Keita has further pointed out that this wiring issue with the grounding pins could indicate cathode and anode are swapped, which means that the diode will be forward biased, which is a much bigger issue.
Therefore, we're pausing on all BHSS work for now until we can figure out how to resolve these problems.
LLO has not checked their wiring, but Oli and I did note that they paid attention to the OMC labeling since they knew the cable lengths would be different.
When our OMCs were shipped to us, the ameristat wrapping had OMC A and OMC B labels, but once we took the wrapping off, there was no indication of A and B on the boxes.
Tue Mar 24 10:06:11 2026 INFO: Fill completed in 6min 7secs
Elenna, Oli
Summary: OMCB has its DCPDs installed and most of its stoppers (barring one that needs to be retapped + helicoiled). OMCA has been aligned according to the OMCA / OMCB install template and is ready for laser alignment. Cabling for both OMCs should be good to go.
After last week's issue of the OMCB DCPD A (TRANS) missing a diode hole (89583), we were able to clear up the issue and fix it (89606). Elenna then installed the DCPD B (REFL) diode. Note that once again there were tiny metal shavings below where the DCPD's were installed, which we picked up with a qtip that we wet with iso. Once we had both installed (pic), we installed the rest of the stoppers around OMCB. The only one we didn't install is one of the vertical stops. This is because there was an issue with the helicoil last week, and we ended up having to remove it. We think this might be due to an issue with the threads, so we are waiting on a 3/8"-24 tap to retap the hole before installing a new helicoil. Because we don't have this stop yet, it doesn't really make sense to fasten on the butter dish, but we might just sit it on today to hinder dust accumulation.
We also realized that the PZT cables were going to be way too short to reach the cable pylons for both OMCA and OMCB, so we very carefully opened the peak cable wraps on the OMCs and took out what we think should be enough. On OMCB we noticed that the little copper wrap for one of the PZTs was not right above the PZT as it should be, but instead was on the other side of the peak cable wrap and was only wrapped loosly around one of the cables. Because of this we just removed the wrap. The cables right above the PZT are looking fine and don't look like they need anything to hold them together.
I had been confused about the OMCA / OMCB install template for the past few days, since installing it was putting OMCB further back in its slot than OMCA, but I was able to confirm yesterday in eDrawings that OMCB is actually supposed to be an extra 1 mm away from the front of its slot as compared to OMCA, so we moved OMCA into position and bolted it down.
I also went in and installed the magnet mounts for the OSEM magnets (without the magnets), as well as the big mass on the back of the BHSS.
Installed serial numbers:
OMCB (SN 105)
Yesterday during the cleanroom move, CO2Y tripped off, this is a known issue when people get near the TCS racks, FRS 6639. I turned it back on this morning by pressing the "GATE" button on the chassis.
Corey, Fil, Erik, Jonathan, Dave:
Last night's earthquake caused SWWD trips for ETMY, ITMY, ITMX. It also caused a HWWD trip of ITMY (BSC1) which was concerning.
We were able to untrip the SWWDs, but we kept ITMY DACKILLED while we work on its HWWD.
Jonathan went into the CER and pressed the RESET button on the ITMY HWWD chassis, this did not untrip the power to the ISI coil drivers. We tried a second time, again no restoration of power.
The front panel and the readback by h1susitmy both agree that the only red led is SEI-trip, the input conditions PD=osem-photodiode-rms and LED=osem-led-current are both GOOD, which should have permitted the reset.
But when the reset button was pressed, the PD led went RED and the unit did not reset the SEI trip.
Fil is heading out to reboot the unit and possibly replace with a spare if it is not working correcty.
WP13115 to possibly prevent future HWWD trips by shortening time-to-trip of SWWD to 15 minutes.
Fil got the ITMY HWWD to fully reset by keeping the "fault reset" button pressed for many seconds.
Attached plot shows the suspension started recovery when the SWWD SUS tripped at 22:19:52 and 41 seconds later the HWWD tripped at 22:20:33
Summary of our 3 HWWD trips has been submitted to the DCC T2600092
As was done at the end station test masses, we need to reduce the time-to-trip for the SUS SWWD from 20 minutes to 15 minutes.
TITLE: 03/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 14mph Gusts, 10mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.19 μm/s
QUICK SUMMARY:
Arrived to see lots of tripped Watchdogs. This was due to a M7.5 Tonga earthquake from last night just before 10pm local time (5utc). Dave contacted me to give me the heads up on this and noted that ITMy actually had the Hardware Watchdog trip---this requires someone to go out to the CER to push a button to restore coil drivers. We were hesitant on addressing this without Jim's guidance--not sure how powering things back on would affect the system. Will message Jim with a heads up for BSC1's ITMy/BSC1-ISI/BSC1-HEPI. Will continue bringing everything else back.
Other than that, today is Maintenance Day. The Filter Cavity Tube has light flashing and so its small gate valves must still be open (I had thought the discussion was to close these gate valves to allow craning over the FC Tube, but not certain on this.
Day1 of 2-day CEBEX workshop begins today.
Earthquake Recovery Status:
ITMy Hardware Watchdog continues to be looked at with Fil/Jonathan
UPDATE: Fil was able to restore the ITMy watchdog (he held the RESET for a few seconds and waited for the lights to change on the front panel). ITMy HEPI/ISI are redamping/isolating.
Betsy wanted a look at the last few months of dust trends for BSC2.
(This is Dust Monitor LVEA10 which was moved to BSC2 in Feb [alog89137].)
Calum and I looked over this plot - the counts are not too bad during the many periods of nearby craning and other activity. The platform and dome have not yet been cleaned. I confirmed that the cross flow tent has positive pressure so Calum and I are comfortable with this new "cleanroom" configuration.
R. Crouch, J. Oberling
Yesterday we began measuring the locations of the vacuum chamber support tube ends using the FARO laser tracker. We started with the support tubes for the WBSC3 chamber and the +X ends of the WBSC2 support tubes as these were the most readily accesible. The remaining support tubes in the LVEA (WBSC1, WBSC2 -X ends, and all WHAM chambers except WHAM7) have iLIGO-era PEM Interface Plates on them that block the support tube; some of these plates have undocumented spacers between them and the support tubes they are attached to, meaning we cannot accurately locate the support tube end w.r.t. the PEM interface plate and therefore making an accurate measurement of the support tube location impossible. As an aside, Jim is in the process of removing these plates from the chambers (so far WHAM3 and WHAM4 are complete, WHAM1 and WHAM2 are 75% complete), so we can get at these support tube ends as the opportunity arises (he will then reinstall these plates, as they make for very convient mounts for dial indicators).
Measurement Method
This is a fairly straightforward measurement, but there is a somewhat subtle "gotcha" that needs to be accounted for to get an accurate measurement. But first things first, we aligned the FARO to the LVEA's Building Coordinate system using our red alignment nests, then applied the X and Y axis rotations required to align the FARO to the site global coordinate system (see T0900340 for a brief overview of the coordinate systems in use). We then loaded CAD models of the support tubes, that Ryan downloaded from the SolidWorks vault with each model in the site global coordinate system, into the FARO's control software, PolyWorks. PolyWorks automatically reads the coordinate system information contained in the CAD files and places these models in position w.r.t. to the site global coordinate system. This gives us nominal locations of the support tube ends, a guide for our measurements, and also a nice visual reference for where everything is positioned.
Now for the "gotcha." The physical support tubes have a hole in the center of each end that is not represented in the CAD model, and this hole is large enough that the FARO target (a Spherically Mounted Retroreflector, or SMR, with a 1.5" diameter) sits slightly inside the hole. This means that when you're taking a measurement of the center of the support tube end using this hole the SMR is not measuring the location of the actual support tube end, it is a few mm inside of it. To account for this we did the following:
To take the measurement we used the Build/Inspect mode in PolyWorks. In this mode we have to be sure to select the "Towards Object" compensation method, which automatically compensates for the radius of the SMR (3/4", or 19.05 mm). If "None" is selected the FARO measures to the center of the SMR, but our measurement point is at the edge of the SMR, since that's what is physically touching the support tube, so we need to compensate for that radius. This gives us the deviations of the measurement point, which can then applied to the point representing the center of each support tube end to give their measured location. The results of our measurements are shown in the attachment. Since we had measurements for each end of the WBSC3 support tubes I also added a distance feature representing the measured length of each WBSC3 support tube.
Wrapping Up
Some points for discussion/further thought. Keep in mind that the BSC support tubes are not exact representations of where their respective optics are; we only aligned the optic during aLIGO install, and in the end didn't really care where the support tubes ended up as long as HEPI had enough range to work. This means that any deviation from nominal seen in the support tube ends is not an indication of misalignment of that chamber's optic.
This work was associated with LHO WP 12947, which also included the WBSC1 +X support tube ends. Those support tubes still have PEM interface plates installed, so we are currently unable to measure them (will do in the future once the plates are removed). Since we completed the rest of the measurements involved, I've closed the WP.
I've attached the same centerline picture of the WBSC3 support tubes as I used for the WBSC2 support tubes in alog 89619 (2nd attachment in that alog). This shows that the support tubes are shifted in the +Y direction, with the +X support tube shifted 1.381mm further +Y than the -X support tube is. This again implies a yaw in addition to the +Y shift. As I did for WBSC2, averaging out the shift gives a +Y shift of ~1.7mm and a CCW yaw of ~824 µrad.
Again, this is not indicative of any misaligment in ITMx, as we moved HEPI to place the optic where it needed to be, and the support tube ends ended up where they ended up.
After talking to Keita, I set the JAC to Down.
Betsy reminded me that the IOT table was unplugged in prep for venting, and that's why JAC was failing to lock.