Yehonathan's list does include C1:AUX-GREEN_Y_Shutter and I copied its definition from /cvs/cds/caltech/target/c1aux/ShutterInterlock.db into the new ETMYaux.db file.

I noticed ShutterInterlock.db still contains about a dozen channels. Some of them appear to be ghosts (like the C1:AUX-PSL_Shutter[...] set, which has since become C1:PSL-PSL_Shutter[...] hosted on c1psl) but others like C1:AUX-GREEN_X_Shutter appear to still be in active use.

We want to migrate the end shutter controls from c1aux to the end acromags. Could you include them to the list if not yet?

This will let us remove c1aux from the rack, I believe.

I used Yehonathan's wiring assignments to lay the rest of groundwork for the final slow controls machine upgrade, c1auxey. Actions completed:

• Created an internal wiring diagram for assembling the Acromag chassis (log in with LIGO.ORG credentials to view/edit)
• Created a new target directory on the network drive:

The "1" will be dropped after the new system is permanently installed.

• Populated the target directory with files:
  • modbusIOC.service - wraps the EPICS IOC as a systemd service
  • ETMYaux.env - defines the EPICS environment variables
  • ETMYaux.cmd - command file to set up the EPICS IOC
  • ETMYaux.sh - enables DAC outputs to the suspension (executed lastly)
• Created the EPICS channel databases:
  • ETMYaux.db - migration of the existing database
  • c1auxey_state.db - contains logic for loopback monitoring of the IOC "alive" state (visible from Sitemap > CDS > Slow Controls Status)

Hardware-wise, this system will require:

• 2 Acromag XT-1221 units (ADC)
• 1 Acromag XT-1541 unit (DAC)
• 1 Acromag XT-1111 unit (sinking BIO)

I know that we do have these quantities left on hand. The next steps are to set up the Supermicro host and begin assembling the Acromag chassis. Both of these activities require an in-person presence, so I think this is as far as we can advance this project for now.

This afternoon, I kept the PRM locked for ~1hour and then measured transfer functions from the PRM angular actuators to the POP QPD spot motion for pitch and yaw between ~1pm and 4pm. After this work, the PRM was misaligned again. I will now work on the feedforward filter design.

Summary:

Retraining the MCL filters resulted in a slight improvement in the performance. Compared to no FF, the RMS in the 0.5-5 Hz range is reduced by approximately a factor of 3. 

Details:

Attachment #1 shows my re-measurement of the MC2 position drive to MCL transfer function.

• The measurement was made using DTT swept sine, with the amplitude enveloped appropriately to avoid knocking the IMC out of lock.
• Coherence was >0.97 for all datapoints.
• Fitting was done using Lee's IIRrational, with the weighting being the coherence. I think there are some features of the fitting I don't fully understand, but I wanted to try and do everything in python and for this simple fit, it came out nicely I think. 

Attachment #2 shows the IIR fits to the FIR filters calculated here. 

• Again, IIRrational was used. 
• In the frequency band where subtraction is possible, the fit is good.
• But there is definitely room for improvement in the way this is done, for now, I did quite a bit "by eye" and tweaked the order of the filter and the minimum number of excess poles relative to zeros to get the AC coupling, but it'd be nice to make all of this iterative and quantitative (e.g. by minimizing a cost function).
• One nice feature of IIRrational is that it directly gives me a formatted string I can paste into foton. The order of these fits were 22, so I split them into two 19+3 order filters to be compatible with the realtime system before loading the coefficients (the overall gain was allocated to a single filter arbitrarily, with the other filter in the pair set to have unity gain in the zpk representation).

Attachment #3 shows several MCL spectra.

• Blue trace is the unsubtracted test dataset.
• Red is the performance of the calculated FIR filter, but the filtering is done offline.
• Gold is the performance of the IIR fit to the FIR filter, as shown in Attachment #2, applied offline to the test dataset.
• Green is the calculated ASD of MCL from a ~1 hour stretch from earlier tonight, when I left the feedforward loop on. So this is an actual measurement of the online performacne of the filter.
• Grey is the performance of the old filter loaded in the CDS system - the filtering is done using scipy, and the sos coefficients from the C1OAF.txt file.

Conclusions + next steps

1. Retraining the filters has resulted in a slight improvement, especially at ~3 Hz.
2. More tests need to be done to confirm that noise isn't being reinjected in the frequency bands where subtraction isn't possible (e.g. using arm cavities as OOL sensors).
3. The online filter isn't quite as good as what we would expect from calculations (green trace is noisier than gold). Need to think about why this is.
4. Why can't we get more subtraction at 1 Hz?
5. Now that I have the infrastructure ready, I will attempt to revive the PRC angular FF loops, which was the whole point of this exercise. 

The problem is that foton does not inherit the model sample rate when launched from DTT/awggui. This is likely some shared/linked/dynamic library issue, the binaries we are running are precompiled presumably for some other OS. I've never gotten this to work since we changed to SL7 (but I did use it successfully in 2017 with the Ubuntu12 install).

do you really mean awggui cannot make shaped noise injections via its foton text box ? That has always worked for me in the past.

If this is broken I'm suspicious there's been some package installs to the shared dirs by someone.

I'd like to re-measure the transfer function from driving MC2 position to the MC_L_DQ channel (for feedforward purposes). Swept sine would be one option, but I can't get the "Envelope" feature of DTT to work, the excitation amplitude isn't getting scaled as specified in the envelope, and so I'm unable to make the measurement near 1 Hz (which is where the FF is effective). I see some scattered mentions of such an issue in past elogs but no mention of a fix (I also feel like I have gotten the envelope function to work for some other loop measurement templates). So then I thought I'd try broadband noise injection, since that seems to have been the approach followed in the past. Again, the noise injection needs to be shaped around ~1 Hz to avoid knocking the IMC out of lock, but I can't get Foton to do shaped noise injections because it doesn't inherit the sample rate when launched from inside DTT/awggui - this is not a new issue, does anyone know the fix?

Note that we are using the gds2.15 install of foton, but the pre-packaged foton that comes with the SL7 installation doesn't work either.

Update:

The envelope feature for swept-sine wasn't working because i specified the frequency grid in the wrong order apparently. Eric von Reis has been notified to include a sorting algorithm in future DTT so that this can be in arbitrary order. fixing that allows me to run a swept sine with enveloped excitation amplitude and hence get the TF I want, but still no shaped noise injections via foton 😢 

Yesterday evening I took nearly all of the masks, gloves, gowns, alcohol wipes, hats, and shoe covers. These were the ones in the cleanroom cabinets at the east end of the Y-arm, as well as the many boxes under the yarm near those cabinets.

This photo album shows the stuff, plus some other random photos I took around the same time (6-7 PM) of the state of parts of the lab.

I have made a wiring + channel list that need to be included in the new C!AUXEY Acromag.

It was mostly copied from C1AUXEX. 

I ignored the IPANG channels since it is going to be removed from the table.

Since there has been a proliferation of BHD Google docs recently, I've linked them all from the BHD wiki page. Let's continue adding any new docs to this central list.

The email address in the N2 checking script wasn't right - I now updated it to email the 40m list if the sum of reserve tank pressures fall below 800 PSI. The checker itself is only run every 3 hours (via cron on c1vac).

Summary:

I think the feedforward filters used for stabilizing MCL with vertex seismometers would benefit from a retraining (last trained in Sep 2015). 

Details:

I wanted to re-familiarize myself with the seismic feedforward methodology. Getting good stabilization of the PRC angular motion as we have been able to in the past will be a big help for lock acquisition. But remotely, it is easier to work with the IMC length feedforward (IMC is locked more often than the PRC). So I collected 2 hours of data from early Sunday morning and went through the set of steps (partially).

Attachment #1 shows the performance of a first attempt.

• 1 hour of data was used as a training set, and another hour to validate the trained filter.
• All the data was downsampled to 64 Hz.
• The number of FIR filter taps was 32 seconds * 64 Hz. 
• Going through some old elogs, there were a number of suggestions from various people about how the training should be done
  • There was a suggestion that pre-filtering the target signal by the (inverse) actuator TF (i.e. TF from MC2 drive to MCL) is beneficial, presumably because it gives the Wiener filter fitting fewer parameters to fit.
  • There was also suggestions that some frequency-dependent weighting of the target signal should be done (e.g. by bandpassing MCL between 0.1 Hz - 10 Hz) to emphasize subtraction in this band.
  • For this particular example, in my limited paramter space exploration, I found that neither of these measures had particularly significant impact.
• In any case, the time-domain FIR filtering seems to approach the theoretical best possible performance (based on coherence information). 
• I have not yet checked what the theoretical limit on subtraction will be based on the seismometer noise ASD.

Attachment #2 shows a comparison between the filter used in Attachment #1 and the filters currently loaded into the OAF system. 

• In the band where significant subtraction is possible, there is some difference in the shape of the filter.
• Why should this have changed? I guess there are multiple possibilities - seismometer recentering, signal chain changes, ...

Attachment #3 is the asd after implementing a time domain Wiener filter, while Attachment #4 is an actual measurement from earlier today - it's not quite as good as Attachment #3 would have me expect but that might also be due to the time of the day. 

Conclusions and next steps:

On the basis of Attachments #3 and #4, I'd say it's worth it to complete the remaining steps for online implementation: FIR to IIR fitting and conversion to sos coefficients that Foton likes (prefereably all in python). Once I've verified that this works, I'll see if I can get some data for the motion on the POP QPD with the PRMI locked on carrier. That'll be the target signal for the PRC angular FF training. Probably can't hurt to have this implemented for the arms as well.

While this set of steps follows the traditional approach, it'd be interesting if someone wants to try Gabriele's code which I think directly gives a z-domain representation and has been very successful at the sites.

* The y-axes on the spectra are labelled in um/rtHz but I don't actually know if the calibration has been updated anytime recently. As I type this, I'm also reminded that I have to check what the whitening situation is on the Pentek board that digitizes MCL.

Some short notes, more details tomorrow.

1. I was able to make it to CARM on RF only ~10 times tonight.
2. Highest stable circulating power was ~200 (recycling gain ~10) but the control scheme is still not finalized in terms of offsets etc.
3. DARM to RF transition was never fully engaged - I got to a point where the ALS gain was reduced to <half its nominal value, but IMC always lost lock.
4. CARM loop UGF of ~5 kHz was realized. I was also able to turn on a regular boost. But couldn't push the gain up much more than this. Should probably modify the boosts on this board, their corner frequencies are pretty high.
5. The increased FSS flakiness post c1psl upgrade is definitely hurting this effort, there are periods of ~20-30mins when the IMC just wont lock.

Attachment #1 shows time series of some signals, from the time I ramp of ALS CARM control to a lockloss. With this limited set of signals, I don't see any clear indication of the cause of lockloss, but I was never able to keep the lock going for > a couple of mins.

Attachment #2 shows the CARM OLTF. Compared to last week, I was able to get the UGF a little higher. This particular measurement doesn't show it, but I was also able to engage the regular boost. I did a zeroth order test looking at the CM_SLOW input to make sure that I wasn't increasing the gain so much that the ADC was getting saturated. However, I did notice that the pk-to-pk error signal in this locked, 5kHz UGF state was still ~1000 cts, which seems large?

Attachment #3 shows the DTT measurement of the relative gains of DARM A and B paths. This measurement was taken when the DARM_A gain was 1, and DARM_B gain was 0.015. On the basis of this measurement, DARM_B (=AS55) sees the excitation injected 16dB above the ALS signal, and so the gain of the DARM_B path should be ~0.16 for the same UGF. But I was never able to get the DARM_B gain above 0.02 without breaking the lock (admittedly the lockloss may have been due to something else).

Attachment #4 shows a zoomed in version of Attachment #1 around the time when the lock was lost. Maybe POP_YAW experienced too large an excursion?

Some other misc points:

• It was much quicker to acquire the PRMI lock with CARM held off resonance using the 1f signals rather than 3f - so I did that and then once the lock is acquired, transfer control to 3f signals (using CDS ramptime) before zeroing the CARM offset.
• The whole process is pretty speedy - it takes <5mins to get to the CARM on RF only stage provided the PRMI lock doesn't take too long (the transition from POX/POY to ALS sequence takes <1min).
• I am wondering what the correct way to set the offsets for the 3f error signals is? 
• The arm buildup is strongly dependent on the DC alignment of the PRMI - the best buildups I got were when I tweaked the BS alignment after the CARM offset was zeroed.

I was in the lab at the time. But did not notice anything (like turbo sound etc). I was around ETMX/Y (1X9, 1Y4) rack and SUS rack (1X4/5), but did not go into the Vac region.

There was a jump in the main volume pressure at ~6pm PDT yesterday. The cause is unknown, but the pressure doesn't seem to be coming back down (but also isn't increasing alarmingly).

I wanted to look at the RGA scans to see if there were any clues as to what changed, but looks like the daily RGA scans stopped updating on Dec 24 2019. The c0rga machine responsible for running these scans doesn't respond to ssh. Not much to be done until the lockdown is over i guess...

Summary:

No real progress tonight - I made it a bunch of times to the point where CARM was RF only, but I never got to run a measurement to determine what the DARM_B loop gain should be to make the control fully RF.

Details:

• Touched up PMC alignment.
• There were very few BNC cables available at the rack near SW corner of the PSL table - the short BNC cables are NOT meant to be daisy chained to make long cables to run along the arm, I removed all those.
• Restored SR785 at LSC rack for CARM TF measurements.
• I was able to get the CARM UGF ~5 kHz, but everytime I was trying to run a DTT swept sine to measure the ratio of DARM_B_IN1 / DARM_A_IN1, the lock was lost - not sure if this is because of the excitation injected or something else.
• I'll probably give this another shot Wednesday eve.

I measured the cross-calibration of the two PDs on the PSL table.

I used the existing flip mounted BS that routes the beam into a PDA255, the same as in the IMC transmission.

I placed a PDA520, the same as the one measuring TRY_OUT on the ETMY table,  on the transmission of the BS (Attachment 1).

I used the SR785 to measure the frequency response of PDA520 with reference to PDA255 (Attachment 2). Indeed, calibration is quite significant.

I calibrated the Y arm frequency response measurement.

However, the data seem to fit well to 1/sqrt(f^2+fp^2) - electric field response - but not to 1/(f^2+fp^2) - intensity response. (Attachment 3).

Also, the extracted fp is 3.8KHz (Finesse ~ 500) in the good fit -> too small.

When I did this measurement for the IMC in the past I fitted the response to 1/sqrt(f^2+fp^2) by mistake but I didn't notice it because I got a pole frequency that was consistent with ringdown measurements.

I also cross calibrated the PDs participating in the IMC measurement but found that the calibration amounted for distortions no bigger than 1db.

Summary

Today I finished implementing loopback monitors of the up/down state of the slow controls machines. They are visible on a new MEDM screen accessible from Sitemap > CDS > Slow Machine Status (pictured in attachment 1). Each monitor is a single EPICS binary channel hosted by the slow machine, which toggles its state at 1 Hz (an alive "blinker"). For each machine, the monitor is defined by a separate database file named c1[machine]_state.db located in the target directory.

This is implemented for all upgraded machines, which includes every slow machine except for c1auxey. This is the next and final one slated for replacement.

Implementation

The blinkers are currently implemented as soft channels, but I'd like to ultimately convert them to hard channels using two sinking/sourcing BIO units. This will require new wiring inside each Acromag chassis, however. For now, as soft channels, the monitors are sensitive to a failure of the host machine or a failure of the EPICS IOC. As hard channels, they will additionally be sensitive to a failure of the secondary network interface, as has been known to happen.

Each slow machine's IOC had to be restarted this afternoon to pick up the new channels. The IOCs were restarted according to the following procedure.

c1auxex

• Disabled OPLEV servos on ETMX
• Zeroed slow biases
• Disabled watchdog
• Restarted IOC
• Reverted 1-3

​c1vac

• Closed V1, VM1
• Restarted IOC
• Returned valves to original state

c1psl

• Disabled IMC autolocker
• Closed PSL shutter
• Restarted IOC
• Reverted 1-2

c1iscaux

• ​Restarted IOC

c1susaux

• Disabled IMC autolocker
• Closed shutter
• Disabled OPLEV servos on: MC1, MC2, MC3, BS, ITMX, ITMX, PRM, SRM
• Zeroed slow biases
• Disabled watchdogs
• Restarted IOC
• Reverted 1-5

The intial recovery of c1susaux did not succeed. Most visibly, the alignment state of the IFO was not restored. After some debugging, we found that the restart of the modbus service was partially failing at the final burt-restore stage. The latest snapshot file /opt/rtcds/caltech/c1/burt/autoburt/latest/c1susaux.snap was not found. I manually restored a known good snapshot from earlier in the day (15:19) and we were able to relock the IMC and XARM. GV and I were just talking earlier today about eliminating these burt-restores from the systemd files. I think we should.

I want to monitor the PMC TRANS and REFL levels on the PSL table - previously there were some cables going to the oscilloscope on the shelf but someone had removed these. I re-installed them just now. While there, I disconnected the drive to the AOM - there must've been some DC signal going to it because when I removed the cable, the PMC and IMC transmission were recovered to their nominal levels.

Updated the cert in /etc/httpd/ssl. The new cert is good until March 12, 2022.

Finally, some RF only CARM, see Attachment #1. During this time, DARM was also on a blend of IR and ALS control, but I couldn't turn the ALS path off in ~4-5 attempts tonight (mostly me pressing a wrong button). Attachment #2 shows the CARM OLTF, with ~2kHz UGF - for now, I didn't bother turning any boosts on. PRCL and MICH are still on 3f signals.

The recycling gain is ~7-8 (so losses >200ppm), but there may be some offset in some loop. I'll look at REFL DC tomorrow.

Can we please make an effort to keep the IFO in this state for the next week or two
- it really helped tonight I didn't have to spend 2 hours fixing some random stuff and could focus on the task at hand.

[jordan, gautam]

the long DB25 cable to connect the Acromag chassis to the temperature sensor interface box arrived. We laid it out today. This cable does the following:

1. Supply the box with +/- 24 V DC from the chassis. The pin arrangement here is rather unfortunate (the +/-24 V DC and GND pins are in close proximity), so if you're not careful, you'll create a short as you plug this cable in (as we found out today). So the best practise is to power down the crate before connecting/disconnecting this cable. Jordan will label this accordingly tomorrow.
2. Pipe the "TAMB" and "TCAV" signals, corresponding to temperature sensors mounted to the PSL table-top and reference cavity exterior respectively, to the Acromags. We found during some initial testing that the "TAMB" signal was reaching the DB25 connector on the Acromag chassis, but wasn't going to any ADC channel - this was rectified.

Both signals now show up in the EPICS channels, but are noisy - I suspect this is because the return pin of the Acromag is not shorted to ground (this is a problem I've seen on the bench before). We will rectify this tomorrow as well.

We took this opportunity to remvoe the bench supply and temporary Acromag crate (formerly known as c1psl2) from under the PSL table. While trying to find some space to store the bench supply, we came across a damaged Oscilloscope in the second "Electronics" cabinet along the Y-arm, see Attachment #1. 

After this work, I found that the IMC autolocker was reliably failing to run the mcup script at the stage where the FSS gains are ramped up to their final values. I was, however, able to smoothly transition to the low-noise locked state if I was manipulating the EPICS sliders by hand. So I added an extra 2 seconds of sleep time between the increasing of the VCO gain to the final value and the ramping of the FSS gains in the mcup script (where previously there was none). Now the autolocker performs reliably.

Of course the reboot wiped any logs we could have used for clues as to what happened. Next time it'll be good to preserve this info. I suspect the local subnet went down.

P.S. for some reason the system logs are priveleged now - I ran sudo sysctl kernel.dmesg_restrict=0 on c1psl to make it readable by any user. This change won't persist on reboot.

Came this morning to find the PMC was unlocked since 6AM. Laser is still on, but PMC REFL PD DC shows dead white constant 0V on PMC screen. All the controls on the PMC screen show constant 0V actually except for the PMC_ERR_OUTPUT which is a fast channel.

Is PSL Acromag already failing?

I restarted the IOC but it didn't help.

I am now rebooting c1psl... That seemed to help. PMC screen seem to be working again. I am able to lock the PMC now.

IMC was locking easily once some switches on the MC servo screen were put to normal states.

TTs were grossly misaligned. Onces they where aligned, arm cavities were locking easily. Dither align for the X arm is very slow though...

                               when doing the AM sweeps of cavities

make sure to cross-calibrate the detectors

                       else you'll make of science much frivolities

            much like the U.S. elections electors

It's been a while since I've attempted any locking, so tonight was mostly getting the various subsystems back together.

• Reconnected SR785 at 1Y3 to CM board for TF measurements.
• POX/POY locking work fine
• Locked PRMI (no ETMs) with carrier resonant, fixed PRM and BS alignment.
• ALS-X noise is still elevated - disconnected it from the switchable delay line and now I'm directly piping the 3dB coupled part of the beat to the LO input of the demod board. But the high freq contribution to the RMS is still ~x2-x3 of what it was in November 2019. But the noise should only depend on the other (delayed) part of the beat (the discriminant is set thus).
• With arms POX/POY locked, checked that there was no elevated coherence between POX_I/POY_I signals between 800 Hz - 1.2 kHz, which is where I see the excess noise in the laser frequency control signal (see Attachment #1). So this suggests that the IMC locking loop suppresses the noise to a level that the arm cavities don't witness it. It's probably still worth checking this out and fixing it, but it wasn't a show stopper.
• Transition from POX/POY lock to ALS lock was smooth - I forgot to use the POX/POY photodiodes as OOL sensors to measure the noise in this config to see if it was elevated, but anyway, I was able to push on.
• PRMI 3f locking worked okay.
• Main thing I wanted to check today is to try the AO transition with a bit more IN1 gain on the CM board - hypothesis being the high frequency part of the CARM signal is buried in the noise if we run with -32dB of IN1 gain. 
  • Set IN1 gain to -10dB instead.
  • In this config, I checked that with the CARM offset at 0 (CARM still under purely ALS control), the CM_SLOW path was registering ~4000 cts pk-pk, which is healthily within the ADC's range.
  • I was able to engage the CARM_B path and semi-stabilize the arm powers (after compensating for the increased IN1 gain by decreasing the CARM_B gain) and turn on the integrator.
  • However, before I could try any AO path action, the IMC loses lock - too tired to try more tonight, I'll try again tomrrow.

I opened the packages send from Syracuse.

- The components are not vacuum clean. We need C&B.
- Some large parts are there, but many parts are missing to build complete SOSs.

- No OSEMs.
- Left and right panels for 6 towers
- 3 base blocks
- 1 suspension block
- 8 OSEM plates. (1 SOS needs 2 plates)

- The parts looks like old versions. The side panels needs insert pins to hold the OSEMs in place. We need to check what needs to be inserted there.

- An unrelated tower was also included.

[koji, gautam]

Attachment #1 shows the relevant parts of the schematic of the WFS demod board (not whitening board). 

• The basic problem was that the switchable gain channels were not accounted for in the Acromag channel list 😒.
• What this meant was that the DC gain was set to the default x100 (since the two DG211s that provide the switchable x10 and x1 gain options had their control logic pins pulled up to +5V because these pins weren't connected to any sinking BIO channel).
• Rather than set up new connections to Acromags inside the chassis (though we have plenty of spares), Koji and I decided to make these fixed to x1 gain.
• The actual fix was implemented as shown in the annotated schematic. There are some pictures 📷 of the PCB in the DCC entry linked above.
• Amusingly, this board will now require a sourcing BIO unit if we want to still have the capability of switching gains.

Before removing the boards from the eurocrate: 

• I dialled down the Kepco HV supplies
• disconnected all the cabling to these boards after noting down cable numbers etc.

After Koji effected the fix, the boards were re-installed, HV supplies were dialled back up to nominal voltage/currents, and the PMC/IMC were re-locked. The WFS DC channels now no longer saturate even when the IMC is unlocked 👏 👏 . I leave it to Yehonathan / Jon to calibrate these EPICS channels into physical units of mW of power. We should also fix the MEDM screen and remove the un-necessary EPICS channels.

Later in the evening, I took advantage of the non-saturated readbacks to center the beams better on the WFS heads. Then, with the WFS servos disabled, I manually aligned the IMC mirrors till REFLDC was minimized. Then I centered the beam on the MC2 transmission QPD (looking at individual quadrants), and set the WFS1/2 RF offsets and MC2 Trans QPD offsets in this condition.

My old scheme was flawed as I used pitch as the readback. The pitch signal could not distinguish the cross-coupling due to coil imbalance and that due to the natural suspension L2P. A new scheme based on yaw alone has been developed and will be integrated into ifo_test. For now we revert the C1:SUS-MC2_UL/UR/LR/LLCOIL gains back to 1, -1, 1, -1. 

I want to measure the transfer function of the arm cavities to extract the pole frequencies and get more insight into what is going on with the DC loss measurements.

The idea is to modulate the light using the PSL AOM. Measure the light transmitted from the arm cavities and use the light transferred from the IMC as a reference.

I tried to start measuring the X arm but the transmission PD is connected to the QPD whitening filter board with a 4 pin Lemo for which I couldn't find an adapter.

• I switch to the Y arm where the transmission PD - Thorlabs PDA520 (250KHz Bandwidth) - is BNC all the way.
• I lay an 82ft BNC cable from the Y Arm 1Y4 to 1Y1 where the BNC from the IMC Trans PD and an SR785 are found. 
• I lock the Arm cavities.
• I connect the AOM cable to the source, the TRY PD (Teed off from the QPD whitening filter) to CH1 and IMC_TRANS to CH2 and measure the transfer function using a swept sine with an offset of 300mV and amplitude of 100mV.
• I fit it to a low pass filter function - see attachment 1 - but it seems like the fit rails off at 10KHz. 

Could this be because of the PDA520 limited BWs? I tried playing with the PD gain/bandwidth switch but it seems like it was already set to high bandwidth/low gain.

In any case, the extracted pole frequency ~ 2.9kHz implies a finesse > 600 (assuming FSR = 3.9MHz) which is way above the maximal finesse (~ 450) for the arm cavities.

I disconnected the source from the AOM. But left the other two BNCs connected to the SR785. Also, TRY PD is still teed off. Long BNC cable is still on the ground.

I returned the triggering threshold to normal values (5/3).

ETMX was grossly misaligned.

I re-aligned it and the X arm now locks.

7:00PM with Koji

Both the alignment of the X and Y arms was recovered.

~>z avg 10 C1:LSC-TRX_OUT C1:LSC-TRY_OUT
C1:LSC-TRX_OUT 0.9914034307003021
C1:LSC-TRY_OUT 0.9690877735614777

We are running ass for the X arm to recover the X arm alignment.

Meanwhile, i want to block the Y arm trans PD (Thorlabs). To do it, the PD<->QPD thresholds were changed from 5.0/3.0 to 0.5/0.3.

An earthquake around 330 UTC (=730pm yesterday eve) tripped ITMX, ITMY and ETMX watchdogs. ITMX got stuck. I released the stuck optic and re-enabled the local damping loops just now.

I did some preliminary debugging of this, and have localized the problem to the output path (after MC slow) on the IMC Servo card. Basically, I monitored the spectrum of the ALS beat frequency fluctuations under a few different conditions: 

• With the BNC to the NPRO PZT disconnected, there is no noise. So the laser and the FSS phase correction EOM (which the ALS beat pickoff sees) are not responsible.
• With the input to the Koji summing box disconnected, still no excess - so the summing box + Thorlabs HV driver are not responsible.
• With the TTFSS output connected to the summing box, but with the input switch to the TTFSS box disabled (isolating the on-PSL table parts of the FSS system), still no excess.
• With the input to the TTFSS enabled, and the BNC output of the IMC Servo card disconnected at 1X2, still no excess.
• Finally, when I connect the BNC cable, the excess starts to show up.

Toggling C1:IOO-MC_FASTSW, which supposedly isolates the post-MC slow (a.k.a. MCL) part of the servo, I see no difference. I am also reasonably confident this switch itself works, because I can break the IMC lock by toggling it. So pending a more detailed investigation, I am forced to conclude that the problem originates in the part of the IMC servo board after the MCL pickoff. Some cabling was removed at 1X2 on Tuesday between the times when there was no excess and when it showed up, but it's hard to imagine how this could have created this particular problem.

Summary:

Sometime between 1PM and 6PM on Tuesday, excess laser frequency noise shows up in MCF at around 800 Hz, as shown in Attachment #1. Sigh.

Details:

While I show the MCF spectrum here, I confirmed that this noise is not injected by the IMC loop (with the PSL shutter closed, and the IMC servo board disconnected from the feedback path to the NPRO, the PMC error and control points still show the elevated noise, see Attachment #2). I don't think the problem is from the PMC loop - see Attachment #3 which is the ALS beat out-of-loop noise with the PMC unlocked (the PSL beam doesn't see the cavity before it gets to the ALS setup, and we only actuate on the cavity length for that loop, so this wasn't even really necessary).

Was there some work on the PSL table on Tuesday afternoon that can explain this? 

It seems like the AO path gain stages on the IMC Servo board work just fine. The weird results I reported earlier were likely a measurement error arising from the fact that I did not disconnect the LEMO IN2 cable while measuring using the BNC IN2 connector, which probably made some parasitic path to ground that was screwing the measurement up. Today, I re-did the measurement with the signal injected at the IN2 BNC, and the TF measured being the ratio of TP3 on the board to a split-off of the SR785 source (T-eed off). Attachments #1, #2 shows the result - the gain deficit from the "expected" value is now consistent with that seen on other sliders.

Note that the signal from the CM board in the LSC rack is sent single-ended over a 2-pin LEMO cable (whose return pin is shorted to ground). But it is received differentially on the IMC Servo board. I took this chance to look for evidence of extra power line noise due to potential ground loops by looking at the IMC error point with various auxiliary cables connected to the board - but got distracted by some excess noise (next elog).

I am running some tests on the IMC servo board with an extender card so the IMC will not be locking for a couple of hours.

We've completed almost all of the in-situ testing of the c1psl channels. During this process, we identified several channels which needed to be rewired to different Acromags (BIO sinking v. sourcing). We also elected to change the connector type of a few channels for practical advantages. Those modifications and other issues found during testing are detailed below. Also attached are the updated channel assignments, with a column indicating the in-situ testing status of each channel.

Post-installation modifications

• All four channels connected to the sourcing BIO module were found to in fact require sinking I/O. They were reassigned to sinking BIO modules. Affected channels:
  • C1:PSL-FSS_FASTSWEEP
  • C1:PSL-FSS_SW1
  • C1:PSL-FSS_SW2
  • C1:PSL-PSL_Shutter
• Added a new AI channel:
  • C1:PSL-FSS_MIXERM
• Removed an unneccessary AI channel:
  • C1:PSL-FSS_LODET
• Moved two AI channels from BNC connectors to a new Dsub connector (labelled DB25M-2 in the spreadsheet).
  • C1:PSL-FSS_RCTEMP
  • C1:PSL-FSS_RMTEMP_VOLTS

Issues identified during testing

• Digital calibration. The following channels work, but we need to verify their EPICS calibration parameters (EGUF/EGUL):
  • C1:PSL-FSS_FASTGAIN
  • C1:PSL-FSS_FAST
  • C1:PSL-PMC_RFADJ
  • C1:PSL-PMC_MODET
• IMC servo board. The Acromag channels themselves were found to work, but the linearity of the mbbo gain stages are in question (i.e., a potential problem with the board). GV is currently testing the servo board.
• PSL QPD board apears to be dead. We connected a scope directly to the test points on the board and measured a high level of noise and no signal (for all four of the QPD channels). I understand this QPD has not been used in some time, so it may not have been noticed before.
• WFS DC channels are saturating when the IMC is unlocked. The acceptance range of the Acromag ADC is only +/-10 V, but we measured sensor voltages as high as ~14 V. It appears that the old ADCs were somehow accepting a range of 0 to +20 V instead of -10 to +10 V. However, the Acromags do not support the input range 0-20 V. Since SNR is not critical for these channels (they're used only for initial alignment), I propose we simply install a voltage divider inside the chassis, just before the Acromag, for each of these signals.

[Jon, Yehonathan]

Summary

With the Acromag chassis now permanently installed, we tested the C1PSL channels going over the channel list one by one, excluding the IMC channels which Gautam is taking responsibility for (the servo board itself is also in question).

The strategy is to check the response of input channels to specific output channels for expected behaviour whenever is possible.

We marked on the channel list spreadsheet the status of the channels that were tested.

In more detail

FSS

Frequency Ref

PMC Servo Card

WFSs

MC Servo

NPRO Diagnostics

[jordan, gautam]

The C1PSL crate has now been installed in a more permanent way in the rack.

• Top and bottom covers were re-attached after work yesterday.
• +/- 24 V DC and +15 V DC power connectors were screwed on for better robustness (I had removed the fuse for the -24V supply as part of debugging yesterday, this was reconnected).
• PSL diagnostics DB 25 cable was re-run appropriately over the cable tray and connected to the unit.
• The chassis sits on some rails - these rails are mounted to the rack using rack nuts but that means the ears on the Acromag chassis no longer line up with any rack nut slots, and so the chassis is not bolted on to the rack.
• We also took this opportunity to remove the c1iool0 VME chassis from 1X2 - given that the DAC and BIO cards of c1ioo (rtcds system) are unused, I felt comfortable disconnecting them and that made the removal relatively easy. The CDS overview MEDM screen reports no errors after this work.

After this work, I disabled logging and restarted the modbus service (and copied the current version of the systemd service file to the target directory for backup). The PMC and IMC lock alright. The system is now ready to be tested in-situ. I will separately continue my IMC Servo board tests in the evening.

One thought about how to protect against this kind of silent failure - how about we always run the modbus service with logging enabled, and then send out a warning email and stop the service if the logfile size suddenly blows up (which is characteristic of when the communications process dies)? This should be done in addition to the ping-ing of the individual IPs.

Regarding the burt-restore step that the systemd service runs after starting up the IOC - this is not even that useful, at least in the way it is currently setup (restore the "latest" burt snapshot file). If the maintenance takes >1hour as it often does, the "latest" snapshot for the system under maintenance is just garbage. So either the burt-restore should be for a "known good time" (dangerous because this will require frequent updates of the systemd service every time we find a new safe state) or we should just do it manually (my preference). Then there is no need to install custom packages on the server machine. Anyway, for now, I have not commented this step out.

Jordan is going to take pictures of all the electronics racks and update the relevant wiki pages.

I investigated the problem reported earlier today with the BIO1 channels. By logging the systemd messages generated when the IOC starts, I was immediately able to determine that the problem was not limited to BIO1. The modbus communications were failing for several other units as well.

Because some in-situ rewiring of a handful of channels had recently been done (more on this soon), I initially suspected that one of the Acromags had been damaged in the process. However, removing BIO1 (or other non-communicating modules) did not restore communications with the rest of the modules. To test whether the chassis was the source of the problem at all, we set up a fresh ADC (new out of the package) and directly connected it to the secondary Ethernet interface of c1psl. With only the one new ADC connected, the modbus IOC failed in exactly the same way.

To confirm that the new ADC did in fact work, we connected it to c1auxex in the same configuration. The unit worked fine connected to c1auxex. This established that the source of the problem was the c1psl host. After some extensive debugging, I traced the problem to a pre-execution script (part of the modbus IOC systemd service) which resets the secondary network interface (the one connected to the Acromag chassis) prior to launching the IOC. This was to ensure the secondary interface always had the correct IP address. It appears this reset was somehow creating a race condition that allowed the modbus initializations (first communications with the Acromags) to sometimes start before the network interface had actually come back up.

I still don't understand how this was happening, or why the pre script worked just fine up until yesterday, but eliminating the network interface reset fixes the problem in 100% of the trials we ran. Unfortunately we lost the entire day to debugging this problem, so the final round of testing is still to be completed. We plan to pick it back up tomorrow afternoon.

We are going to replace the old Sun c1ioo with a modernized supermicro. At the opportunity, remove the DAC and BIO cards to use them with the new machines. BTW I also have ~4 32ch BIO cards in my office.

Jon is going to write up the details of todays adventures. But the C1PSL Acromag chassis is sitting on the floor between the IMC beamtube and the 1X1 electronics rack, and is very much a trip hazard. Be careful if youre in that area.

To debug a problem with the new c1psl (later elog), we needed a Supermicro EPICS server that was using the shared EPICS/modbus/asyn binaries rather than a local install. Of those available in the lab (c1iscaux, c1vac, c1susaux being the others), this was the only one which uses the shared install. So I 

• turned the slow bias voltages to 0
• shutdown the watchdog
• disconnected the Acromag crate in 1X9 from the 192.168.114.xxx subnet at the supermicro end
• connected a test ADC to the local subnet using a different ethernet cable (leaving the original one dangling)
• ran some software tests to see if we could open up a communication line to the test ADC using modbus without any errors being thrown
• removed the test ADC and restored the ethernet connection.

At which point Jon reset the software end, I restored the slow bias voltage and re-enabled the local damping. The optic seems to have damped okay. The Oplev spot is back in ~center of the QPD and the green beam can be locked to a TEM00 mode (so the alignment is okay - the IR beam is unavailable while c1psl issues are being sorted but I judge that things are back to the nominal state now).

After discussing with Koji, I removed the PZT driver and associated AI card from the Eurocrate at 1X2. The corresponding backplane connectors were also removed from the cross connects. An additional cable going from the DAC to IDC adaptor on 1X2 was removed. Finally, some cables going to the backplane P1 and P2 connectors for slots in which there were no cards were removed. 

Finally, there is the IMC WFS whitening boards. These were reconfigured in ~2016  by Koji to have (i) forever whitening, and (ii) fixed gain. So the signals from the P1 connector no longer have any influence on the operation of this board. So I removed these backplane cables as well.

Some pics attached. The only cross connect cabling remaining on the south side of 1X2 is going to the fast BIO adaptor box - I suspect these are the triggered fast whitening switching for the aforementioned WFS whitening board. If so, we could potentially remove those as well, and remove all the cross connects from 1X1 and 1X2.

Update 1720: indeed, as Attachment #2 shows, the RTCDS BIO channels were for the WFS whitening switching so I removed those cables as well. This means all the xconnects can be removed. Also, the DAC and BIO cards in c1ioo are unused.

There was some work done on the Acro crate this morning. Unclear if this is independent, but I found that the IMC servo board IN1 slider doesn't respond anymore, even though I had tested it and verified it to be working. Patient debugging showed that BIO1 (and only that acromag unit with the static IP 192.168.114.61) doesn't show up on the subnet in c1psl. Hopefully it's just a loose network cable, if not we will switch out the unit in the afternoon. 

Jon is going to make a python script which iteratively pings all devices on the subnet and we will put this info on an MEDM screen to catch this kind of silent failure.

I realigned the input pointing into the PMC this morning. Usually, the way I do this is to minimize any discernible mode structure in the PMC reflection CCD image. Today, I noticed that making the DC reflection go down also makes the DC transmission go down. Possibilities:

• we are sampling slightly different spots inside the PMC cavity which change the buildup by ~2-3%.
• we are misaligned on the transmission/reflection photodiode.
• ??

Allegra had no network cable and no mouse. We found Allegra'snetwork cable (black) and connected it.

I found a dirty old school mouse and connected it.

I wiped Allegra and now I'm currently installing debian 10 on allegra following Jon's elog.

04/01 update: I forgot to mention that I tried installing cds software by following Jamie's instruction: I added the line in /etc/apt/sources.list.d/lscsoft.list: "deb http://software.ligo.org/lscsoft/debian/ stretch contrib". But this the only thing I managed to do. The next command in the instructions failed.

• Re-aligned and locked the arm cavities for IR and green.
• Re-set trans normalization because after the c1iscex and c1iscey reboots, these didn't come back to the old values.