40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 82 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  690   Thu Jul 17 13:08:37 2008 JohnSummaryLSCHOM resonances in the arms
On Tuesday night we attempted to lock the full DRFPMI in the optical spring configuration with the +f2 sideband resonant in the SRC.
Despite having no problems locking on the +f2 in a DRM we couldn't lock the full IFO.

There was some discussion about whether a +f2 higher order mode resonance in the arms could cause this problem.

I calculated the positions of the first six higher order modes for the carrier and all sidebands (using Siegman p 762 (23) with a plus sign).
Plot attached. Colors indicate different frequency components, numbers are the mode index (m+n). Thick lines are fundamental modes of
the sidebands. Heights of HOM indicators have been scaled by 1/(m+n)^2.

It appears that the first order transverse mode of the +166 is indeed partially resonant. We might try to tweak the sideband frequencies a
little to see if this helps us. It would probably be prudent to measure the MC length first.

Numbers used:

L = 38.5750; %average of Alberto's recent measurements elog #556
Retm = 57.375;
f166 = 165.977195e6;
f33 = 33.195439e6;
  830   Tue Aug 12 21:38:19 2008 JohnUpdateLSCAccidental higher order mode resonances in the arms
Recently we had been having some trouble locking the full IFO in the spring configuration (SRC on +166).
It was thought that an accidental higher order mode resonance in the arms may have been causing problems.

I previously calculated the locations of the resonances using rough arm cavity parameters(Elog #690). Thanks to Koji
and Alberto I have been able to update this work with measured arm length and g factors for the y arm (Elog #801,#802).
I have also included the splitting of the modes caused by the astigmatic ETM. Code is attached.

I don't see any evidence of +166MHz resonances in the y arm.

In the attached plot different colours denote different frequencies +33, -33, +166, -166 & CR.
The numbers above each line are the mn of TEMmn.
Solid black line is the carrier resonance.
  858   Wed Aug 20 11:42:49 2008 JohnSummaryComputerspdftk
I've installed pdftk on all the control room machines.

  859   Wed Aug 20 11:50:10 2008 JohnSummaryComputersStripTools on op540m

To restart the striptools on op540m:

cd /cvs/cds/caltech/scripts/general/

  14111   Sat Jul 28 22:16:49 2018 John MartynUpdate Characterization of Transimpedance Amplifier

Kevin and I meaured the transfer function of the photodiode circuit using the Jenne laser and agilent in the 40m lab. The attached figures depict our measured transfer function over the modulation frequency ranges of 30kHz-30MHz and 1kHz-30MHz when the power of the laser was set to 69 and 95 μW. These plots indicate a clear roll off frequency around 300 kHz. In addition, the plots beginning at 1kHz display unstable behavior at frequencies below 30kHz. I am not sure why there is such a sharp change in the transfer function around 30kHz, but I suspect this to be due to an issue with the agilent or photodiode. 

  8757   Wed Jun 26 15:11:08 2013 John ZweizigUpdateSUSNDS2 Status


I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2

  * restarted nds2 with updated channel lists.

  8787   Fri Jun 28 17:33:33 2013 John ZweizigUpdateSUSNDS2 Status



I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2

  * restarted nds2 with updated channel lists.

 I have set the cron job up to restart the nds2 server automatically if the channel list changes. The only change is that the cron command was changes to /ligo/apps/nds2/nds2-megatron/test-restart.


  9216   Mon Oct 7 18:32:01 2013 John ZweizigSummaryComputer Scripts / Programsnds2 installed, restarted

The upgrade of megatron broke the nds2 service. I have fixed things by

  1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)

  2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)

  3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.

 nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.


  612   Tue Jul 1 12:08:38 2008 John, JoeConfigurationPSLPMC input PD
Joe and I switched cables so that the PMCR screen actually shows reflection not transmission.

The trans camera had a BNC connected to "video out" labelled PMC input PD. The video signal
going to the monitors does not come from "video out", it comes out the "DC in/sync" cable.
As far as we can see this diode doesn't exist. Where should the PMC input PD BNC cable be
  602   Mon Jun 30 13:48:47 2008 John, RobConfigurationPSLDon't put the bin in front of the air conditioning unit
We spotted that the laser power was dropping.

The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.

Let's be careful about this in the future.
  711   Tue Jul 22 03:03:22 2008 John, RobUpdatePSLFSS open loop transfer function
With the common gain slider maxed out the unity gain frequency is 58kHz.

The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.

Tomorrow I'll take a closer look at the board.
  715   Tue Jul 22 13:16:09 2008 John, RobUpdatePSLFSS open loop transfer function

With the common gain slider maxed out the unity gain frequency is 58kHz.

The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.

Tomorrow I'll take a closer look at the board.

Should note that the UGF of 58kHz was measured with the test cable (from RFPD to board), so the demod phase was presumably sub-optimal.
  13976   Sat Jun 16 20:57:59 2018 JonUpdateGeneralPRC modescan attempt

Here's a Finesse modeling of what we're expecting to observe with this test. It uses Gautam's base model of the 40m IFO with appropriate modifications for the needed configuration.

The idea is to lock the IFO in the SRMI configuration, with the phase-locked AUX beam injected from the AS port. The AUX beam is imprinted with AM sidebands and slightly misaligned relative to the SRC so as to transfer power into HOM1. The RF network analyzer provides the drive signal for the AOM, and its frequency is swept to coherently measure the transfer function [reflected AUX beam / drive]. The reflected AUX beam is sensed by the AS110 PDA10CF.

It is also possible to drive PM sidebands as Koji suggests, but the squeezer group has encouraged using AM for practical advantages. The SNR with AM is a bit higher (less power lost into harmonics at large modulation index), there is a broadband AOM already available aligned to the SQZ beam at LLO, and there is also concern that driving strong PM could interfere with the SQZ control loops.

Expected SRMI Response

Attachment #1 shows the expected response to swept-AM in SRMI. Resolving just the FSR and the first-order mode splitting is sufficient to extract the SRC Gouy phase.

Expected response in the SRMI configuration.

Expected DRMI Response

Since the 40m has not been opearted in SRMI since ~2016 (last done by Eric Q.), Gautam believes it may take some time to relock this configuration. However, the modeling indicates that we can likely obtain sufficient sensitivity in DRMI, which would allow us to proceed faster. Attachment #2 shows the expected response to swept-AM in DRMI. The PRC leakage signal turns out to be significantly smaller than the SRC reflection (a factor of ~30 in amplitude), so that the signal still retains its characteristic shape to a very good approximation. The tradeoff is a 10x reduction in SNR due to increased PSL shot noise reaching AS110.

Expected DRMI response. The main difference is a 10x increase in shot noise on AS110.

Based on this, we should proceed with DRMI scans instead of PRMI next week.


The PRC FSR is, of course, very close to twice of our f1 moudlation frequency (11MHz x 2 = 22MHz) .

I still don't understand what response the measurement is looking for. I understood the idea of using the subcarrier as a stablized carrier to the PRC with a certain freq offset from the main carrier. I suppose what was swept was the AOM modulation frequency (i.e. modulation frequency of the AM applied to the subcarrier). If that is the case, the subcarrier seemed fixed at an arbitorary frequency (i.e. 50MHz) away from the carrier. If one of the AM sidebands hits the PRC resonance (i.e. 22, 44, 66MHz away from the main carrier), you still have the other sideband reflected back to the AS. Then the RF signal at the AS is still dominated by this reflected sideband. I feel that the phase modulation is rather suitable for this purpose.

If you are talking about ~MHz AM modulation by the AOM and scanning the PLL frequency from 1MHz to 60MHz, the story is different. And this should involve demodulation of the AS signal at the AM modulation frequency. But I still don't understand why we don't use phase modulation, which gives us the PDH type signal at the reflection (i.e. AS) port...



  13987   Tue Jun 19 18:56:55 2018 JonUpdateGeneralAUX beam alignment issues

Not much progress today with the AUX cavity scans. I've determined there still are some alignment issues.

At the start of today a large AUX/PSL beat note was visible on the AS110 sensor, at a similar power as where we left off last night (-60 dBm). Proceeding from there, I attempted to reproduce Johannes' measurement of the cavity transmission resonances. I misaligned the X-arm, locked the Y-arm cavity, and scanned the AUX RF offset approximately 8 MHz in 2 kHz steps. This should have swept through two FSRs, but nothing was visible.

Further inspection revealed that none of the PSL light was making it back to through the AUX fiber to the PSL table. I take this to mean that the beam seen earlier on AS110 was the ITMY reflection, and that the AUX injection axis was no longer reaching ETMY. I also found that the AUX beam size just after the 90/10 beasmsplitter looks anomolously large. Maybe a lens was recently changed? In any case, the mode-matching looks like it is going to need to be readjusted.

  13994   Thu Jun 21 09:33:02 2018 JonUpdate AUX Mode Scans of YARM, PRC cavities

[Jon, Keerthana, Sandrina]

Yesterday we carried out preliminary proof-of-concept measurements using the new AS-port-injected AUX laser to resolve cavity mode resonances.

At the time we started, I found the beat note levels consistent with what Johannes had reported the night before post-realignment. Hence we did not change the AUX alignment.

Test 1: YARM Mode Scan

  • IFO locked in YARM configuration on carrier.
  • Confirmed the presence of a -80 dBm beat note on the temporary YEND broadband PD (i.e., at the cavity transmission).
  • Slowly canned the RF offset of the AUX laser from 50 MHz (nominal) to 60 MHz in 10 kHz steps.
  • Attachment 1 shows the measured scan in "max hold" mode. The bottom panel is the transmission spectrum and the top panel is the reflection, with the AUX/PSL carrier-carrier beat note visible to the far left. In addition to the FSR, it looks to me like the scan resolves at least two HOMs.

Test 2: PRC Mode Scan

  • IFO locked in PRMI configuration on carrier.
  • Moved the temporary 150 MHz PDA10CF from the YEND to an unused pickoff of the REFL33 beam (i.e., the PRC transmission of the AUX beam). There was an existing 50-50 beamsplitter just before REFL33 whose reflected beam was directed onto a beam dump. The PD is now placed in that location. The modification to the AS table is shown in Attachment 2.
  • We made a similar slow scan of the AUX RF offset over ~35 MHz in 10 kHz steps.
  • We resolve the 22 MHz FSR, but it is apparent that an incoherent "max-hold" analyzer measurement is inadequate. The problem is that in max-hold mode, because the 11 MHz-spaced PSL sidebands also beat with the AUX subcarrier, we measure a messy superposition of the PSLcarrier-AUXcarrier beat AND all of the PSLsideband-AUXcarrier beats. The next step is to use the AOM to make a coherent measurement at only the frequency of PSL/AUX carrier-carrier beat.

The SURFs have the data from last night's scans and will be separately posting plots of these measurements. We'll continue today with mode scans using AM sidebands rather than the AUX RF offset.

  14010   Sat Jun 23 13:08:41 2018 JonUpdateAUXFirst Coherent AUX Scan of PRC Using AM Sidebands

[Jon, Keerthana, Sandrine]

Thu.-Fri. we continued with PRC scans using the AUX laser, but now the "scanned" parameter is the frequency of AM sidebands, rather than the frequency of the AUX carrier itself. The switch to AM (or PM) allows us to coherently measure the cavity transfer as a function of modulation frequency.

In order to make a sentinel measurement, I installed a broadband PDA255 at an unused pickoff behind the first AUX steering mirror on the AS table. The sentinel PD measures the AM actually imprinted on the light going into the IFO, making our measurement independent of the AOM response. This technique removes not only the (non-flat) AOM transfer function, but also any non-linearities from, e.g., overdriving the AOM. The below photo shows the new PD (center) on the AS table.

With the sentinel PD installed, we proceeded as follows.

  • Locked IFO in PRMI on carrier.
  • Locked AUX PLL to PSL.
  • Tuned the frequency of the AUX laser (via the RF offset) to bring the carrier onto resonance with the PRC.
  • Swept the AOM modulation frequency 0-60 MHz while measuring the AUX reflection and injection signals.

The below photo shows the measured transfer function [AUX Reflection / AUX Injection]. The measurement coherence is high to ~55 MHz (the AOM bandwidth is 60 MHz). We clearly resolve two FSRs, visible as Lorentzian dips at which more AUX power couples into the cavity. The SURFs have these data and will be separately posting figures for the measurements.

With the basic system working, we attempted to produce HOMs, first by partially occluding the injected AUX beam with a razor blade, then by placing a thin two-prong fork in the beam path. We also experimented with using a razor blade on the output to partially occlude the reflection beam just before the sensor. We were able to observe an apparent secondary dip indicative of an HOM a few times, as shown below, but could not repeat this deterministically. Besides not having fine control over the occlusion of the beams, there is also large few-Hz angular noise shaking the AS beam position. I suspect from moment to moment the HOM content is varying considerably due to the movement of the AS beam relative to the occluding object. I'm now thinking about more systematic ways to approach this.


  14020   Tue Jun 26 17:20:33 2018 JonConfigurationCamerasLLO Python Camera Software is Working

Thanks to a discussion yesterday with Joe Betzweiser, I was able to identify and fix the remaining problem with the LLO GigE camera software. It is working now, currently only on rossa, but can be set up on all the machines. I've started a wiki page with documentation and usage instructions here:


This page is also linked from the main 40m wiki page under "Electronics."

This software has the ability to both stream live camera feeds and to record feeds as .avi files. It is described more on the wiki page.

  14033   Fri Jun 29 18:16:32 2018 JonConfigurationPSLChanges to AUX Optical Layout on PSL Table

In order to use the 0th-order deflection beam from the AOM for cavity mode scans, I've coaligned this beam to the existing mode-matching/launch optics set up for the 1st-order beam.

Instead of being dumped, the 0th-order beam is now steered by two 45-degree mirrors into the existing beam path. The second mirror is on a flip mount so that we can quickly switch between 0th-order/1st-order injections. None of the existing optics were touched, so the 1st-order beam alignment should still be undisturbed.

Currently the 0th-order beam is being injected into the IFO. After attenuating so as to not exceed 100 mW incident on the fiber, approximately 50 mW of power reaches the AS table. That coupling efficiency is similar to what we have with the 1st-order beam. With the Y-arm cavity locked and the AUX PLL locked at RF offset = 47.60 MHz (an Y-arm FSR), I observed a -50 dBm beat note at Y-end transmission.

  14035   Tue Jul 3 11:59:10 2018 JonUpdateAUXAUX Carrier Scan of Y-Arm Cavity

I made the first successful AUX laser scan of a 40m cavity last night.

Attachment #1 shows the measured Y-end transmission signal w.r.t. the Agilent drive signal, which was used to sweep the AUX carrier frequency. This is a distinct approach from before, where the carrier was locked at a fixed offset from the PSL carrier and the frequency of AM sidebands was swept instead. This AUX carrier-only technique appears to be advantageous.

This 6-15 MHz scan resolves three FSR peaks (TEM00 resonances) and at least six other higher-order modes. The raw data are also enclosed (attachment #2). I'll leave it as an excercise for the SURFs to compute the Y-arm cavity Gouy phase.

  14036   Wed Jul 4 19:11:49 2018 JonUpdateAUXMore Testing of AUX-Laser Mode Scanning

More progress on the AUX-laser cavity scans.

Changes to the Setup

  • For scans, the Agilent is now being used as a standalone source of the LO signal provided to the AUX PLL (instead of the Marconi), which sets the RF offset. We discovered that when the sweep is "held" in network analyzer mode, it does not turn off the RF drive signal, but rather continues outputting a constant signal at the hold frequency. This eliminates the need to use the more complicated double-deomdulation previously in use. The procedure is to start and immediately hold the sweep, then lock the PLL, then restart the sweep. The PLL is able to reliably remain locked for frequency steps of up to ~30 kHz. The SURFs are preparing schematics of both the double- and single-demodulation techniques.
  • Both the Marconi and Agilent are now phase-locked to the 10 MHz time reference provided by the rabidium clock. This did noticeably shift the measured resonance frequencies.
  • I raised the PI controller gain setting to 4.5, which seems to better suppress the extra noise being injected.
  • I've procured a set of surgical needles for occluding the beam to produce HOMs. However, I have not needed to use them so far, as the TEM00 purity of the AUX beam appears to already be low. The below scans show only the intrinisic mode content.

New Results

  • YARM scan at 70 uW injection power (Attachment #1). The previously reported YARM scan was measured with 9 mW of injected AUX power, 100x larger than the power available from the SQZ laser at the sites. This scan repeats the measurement with the AUX power attenuated to uW. It still resolves the FSR and at least three HOMs.
  • PRC scan (Attachment #2) at 9 mW injection power. It appears to resolve the FSR and at least three HOMs. Angular injection noise was found to cause large fluctuations in the measured signal power. This dominates the error bars shown below, but affects only the overall signal amplitude (not the peak frequency locations). The SQZ angular alignment loops should mitigate this issue at the sites.

Both data sets are attached.

  14044   Sun Jul 8 12:20:12 2018 JonSummaryAUXGouy Phase Measurements from AUX-Laser Scans

This note reports analysis of cavity scans made by directly sweeping the AUX laser carrier frequency (no sidebands). The measurement is made by sweeping the RF offset of the AUX-PSL phase-locked loop and demodulating the cavity reflection/transmission signal at the offset frequency.

Y-Arm Scan

Due to the simplicity of its expected response, the Y-arm cavity was scanned first as a test of the AUX hardware and the sensitivity of the technique. Attachment 1 shows the measured cavity transmission with respect to RF drive signal.

The AUX laser launch setup is capable of injecting up to 9.3 mW into the AS port. This high-power measurement is shown by the black trace. The same measurement is repeated for a realistic SQZ injection power, 70 uW, indicated by the red curve. At low power, the technique still clearly resolves the FSR and six HOM resonances. From the identified mode resonance frequencies the following cavity parameters are directly extracted.

YARM Gautam's Finesse Model Actual
FSR 3.966 MHz 3.967 MHz
Gouy phase 54.2 deg 52.0 deg

PRC Scan

An analogous scan was performed for the PRC, with the IFO locked on PSL carrier in PRMI. Attachment 2 shows the measurement of PRC transmission with respect to drive signal.

The scan resolves HOM resonances to at least ~13th order, whose frequencies yield the following cavity parameters.

PRC Gautam's Finesse Model Actual
FSR 22.30 MHz 22.20 MHz
Gouy phase 13.4 deg 15.4 deg

SRC Scan

Ideally (and at the sites) the SRC mode resonances will be measured in SRMI configuration. Because every other cavity is misaligned, this configuration provides an easily-interpretable spectrum whose resonances can all be attributed to the SRC.

Due to time constraints at the 40m, the IFO could not be restored to lockability in SRMI. It has been more than two years since this configuration was last run. For this reason the scan was made instead with the IFO locked in DRMI, as shown in Attachment 3. The quantity measured is the AUX reflection with respect to drive signal.

This result requires far more interpretation because resonances of both the SRC and PRC are superposed. However, the resonances of the PRC are known a priori from the independent PRMI scan. The SRC mode resonances identified below do not conincide with any of the first five PRC mode resonances.

Based on the identified mode resonance frequencies, the SRC parameters are measured as follows.

SRC Gautam's Finesse Model Actual
FSR 27.65 MHz 27.97 MHz
Gouy phase 10.9 deg 8.8 deg

Lessons Learned

From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.

  • Pointing jitter of the input AUX beam. This causes the PSL-AUX beam overlap to vary at transmission (or reflection), causing variation in the amplitude of the AUX-PSL beat note. As far as we can tell, the frequency of the resonances (the only object of this measurement) is not changing in time, only the relative amplitudes of the diferent mode peaks. I believe the SQZ alignment loops will mitigate this problem at the sites.
  • Stabilization of the network analyzer time base. We found the intrinsic frequency stability of the network analyzer (Agilent 4395A) to be unacceptably large. We solved this problem by phase-locking the Agilent to an external reference, a 10-MHz signal provided by an atomic clock.
  14091   Fri Jul 20 18:30:47 2018 JonConfigurationAUXRecommend to install AUX PZT driver

I recently realized that the PLL is only using about 20% of the available actuation range of the AUX PZT. The +/-10 V control signal from the LB1005 is being directly inputted into the fast AUX PZT channel, which has an input range of +/-50 V.

I recommend to install a PZT driver (amplifier) between the controller and laser to use the full available actuator range. For cavity scans, this will increase the available sweep range from +/-50 MHz to +/-250MHz. This has a unique advantage even if slow temperature feedback is also implemented. To sample faster than the timescale of most of the angular noise,  scans generally need to be made with a total sweep time <1 sec. This is faster than the PLL offset can be offloaded via the slow temperature control, so the only way to scan more than 100 MHz in one measurement is with a larger dynamic range.

  14171   Mon Aug 20 15:16:39 2018 JonUpdateCDSRebooted c1lsc, slow machines

When I came in this morning no light was reaching the MC. One fast machine was dead, c1lsc, and a number of the slow machines: c1susaux, c1iool0, c1auxex, c1auxey, c1iscaux. Gautam walked me through reseting the slow machines manually and the fast machines via the reboot script. The computers are all back online and the MC is again able to lock.

  14179   Thu Aug 23 15:26:54 2018 JonUpdateIMCMC/PMC trouble

I tried unsuccessfully to relock the MC this afternoon.

I came in to find it in a trouble state with a huge amount of noise on C1:PSL-FSS_PCDRIVE visible on the projector monitor. Light was reaching the MC but it was unable to lock.

  • I checked the status of the fast machines on the CDS>FE STATUS page. All up.
  • Then I checked the slow machine status. c1iscaux and c1psl were both down. I manually reset both machines. The large noise visible on C1:PSL-FSS_PCDRIVE disappeared.
  • After the reset, light was no longer reaching the MC, which I take to mean the PMC was not locked. On the PSL>PMC page, I blanked the control signal, reenabled it, and attempted to relock by adjusting the servo gain as Gautam had showed me before. The PMC locks were unstable, with each one lasting only a second or so.
  • Next I tried restoring the burt states for c1iscaux and c1psl from a snapshot taken earlier today, before the machine reboots. That did not solve the problem either.
  14187   Tue Aug 28 18:39:41 2018 JonUpdateCDSC1LSC, C1AUX reboots

I found c1lsc unresponsive again today. Following the procedure in elog #13935, I ran the rebootC1LSC.sh script to perform a soft reboot of c1lsc and restart the epics processes on c1lsc, c1sus, and c1ioo. It worked. I also manually restarted one unresponsive slow machine, c1aux.

After the restarts, the CDS overview page shows the first three models on c1lsc are online (image attached). The above elog references c1oaf having to be restarted manually, so I attempted to do that. I connect via ssh to c1lsc and ran the script startc1oaf. This failed as well, however.

In this state I was able to lock the MICH configuration, which is sufficient for my purposes for now, but I was not able to lock either of the arm cavities. Are some of the still-dead models necessary to lock in resonant configurations?

  14190   Wed Aug 29 11:46:27 2018 JonUpdateSUSlocal 4.4M earth quake

I freed ITMX and coarsely realigned the IFO using the OPLEVs. All the alignments were a bit off from overnight.

The IFO is still only able to lock in MICH mode currently, which was the situation before the earthquake. This morning I additionally tried restoring the burt state of the four machines that had been rebooted in the last week (c1iscaux, c1aux, c1psl, c1lsc) but that did not solve it.


All suspension tripped. Their damping restored. The MC is locked.

ITMX-UL & side magnets are stuck.



  14196   Mon Sep 10 12:44:48 2018 JonUpdateCDSADC replacement in c1lsc expansion chassis

Gautam and I restarted the models on c1lsc, c1ioo, and c1sus. The LSC system is functioning again. We found that only restarting c1lsc as Rolf had recommended did actually kill the models running on the other two machines. We simply reverted the rebootC1LSC.sh script to its previous form, since that does work. I'll keep using that as required until the ongoing investigations find the source of the problem.


Looks like the ADC was not to blame, same symptoms persist.


The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue.


  14278   Tue Nov 6 19:41:46 2018 JonOmnistructure c1vac1/2 replacement

This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now.

  14282   Wed Nov 7 19:17:18 2018 JonOmnistructure modbusIOC is running on c1vac replacement

Today I finished setting up the server that will replace the c1vac1/2 machines. I put it on the martian network at the unassigned IP I assigned it the hostname c1vac and added it to the DNS lookup tables on chiara.

I created a new targets directory on the network drive for the new machine: /cvs/cds/caltech/target/c1vac. After setting EPICS environment environment variables according to 13681 and copying over (and modifiying) the files from /cvs/cds/caltech/target/c1auxex as templates, I was able to start a modbusIOC server on the new machine. I was able to read and write (soft) channel values to the EPICS IOC from other machines on the martian network.

I scripted it as a systemd-managed process which automatically starts on boot and restarts after failure, just as it is set up on c1auxex.

  14287   Fri Nov 9 22:24:22 2018 JonOmnistructure Wiring of Vacuum Acromag Chassis Complete

Wiring of the power, Ethernet, and indicator lights for the vacuum Acromag chassis is complete. Even though this crate will only use +24V DC, I wired the +/-15V connector and indicator lights as well to conform to the LIGO standard. There was no wiring diagram available, so I had to reverse-engineer the wiring from the partially complete c1susaux crate. Attached is a diagram for future use. The crate is ready to begin software developing on Monday. 

  14296   Wed Nov 14 21:34:44 2018 JonOmnistructure Vacuum Acromags installed and tested

All 7 Acromag units are now installed in the vacuum chassis. They are connected to 24V DC power and Ethernet.

I have merged and migrated the two EPICS databases from c1vac1 and c1vac2 onto the new machine, with appropriate modifications to address the Acromags rather than VME crate.

I have tested all the digital output channels with a voltmeter, and some of the inputs. Still more channels to be tested.

I’ll follow up with a wiring diagram for channel assignments.

  14308   Mon Nov 19 22:45:23 2018 JonOmnistructure Vacuum System Subnetwork

I've set up a closed subnetwork for interfacing the vacuum hardware (Acromags and serial devices) with the new controls machine (c1vac; The controls machine has two Ethernet interfaces, one which faces outward into the martian network and another which faces the internal subnetwork, 192.168.114.xxx. The second network interface was configured via the following procedure.

1. Add the following lines to /etc/network/interfaces:

allow-hotplug eth1
iface eth1 inet static

2. Restart the networking services:

$sudo /etc/init.d/networking restart

3. Enable DNS lookup on the martian network by adding the following lines to /etc/resolv.conf:

search martian

4. Enable IP forwarding from eth1 to eth0:

$sudo echo 1 > /proc/sys/net/ipv4/ip_forward

5. Configure IP tables to allow outgoing connections, while keeping the LAN invisible from outside the gateway (c1vac):

$sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
$sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

6. Finally, because the EPICS 3.14 server binds to all network interfaces, client applications running on c1vac now see two instances of the EPICS server---one at the outward-facing address and one at the LAN address. To resolve this ambiguity, two additional enviroment variables must be set that specify to local clients which server address to use. Add the following lines to /home/controls/.bashrc:


A list of IP addresses so far assigned on the subnetwork follows.

Device IP Address
Acromag XT1111a
Acromag XT1111b
Acromag XT1111c
Acromag XT1111d
Acromag XT1111e
Acromag XT1121a
Acromag XT1121b
  14309   Mon Nov 19 23:38:41 2018 JonOmnistructure Vacuum Acromag Channel Assignments

I've completed bench testing of all seven vacuum Acromags installed in a custom rackmount chassis. The system contains five XT1111 modules (sinking digital I/O) used for readbacks of the state of the valves, TP1, CP1, and the RPs. It also contains two XT1121 modules (sourcing digital I/O) used to pass 24V DC control signals to the AC relays actuating the valves and RPs. The list of Acromag channel assignments is attached.

I tested each input channel using a manual flip-switch wired between signal pin and return, verifying the EPICS channel readout to change appropriately when the switch is flipped open vs. closed. I tested each output channel using a voltmeter placed between signal pin and return, toggling the EPICS channel on/off state and verifying the output voltage to change appropriately. These tests confirm the Acromag units all work, and that all the EPICS channels are correctly addressed.

  14315   Sun Nov 25 17:41:43 2018 JonOmnistructure Vacuum Controls Upgrade - Status and Plans

New hardware has been installed in the vacuum controls rack. It is shown in the below post-install photo.

  • Supermicro server (c1vac) which will be replacing c1vac1 and c1vac2.
  • 16-port Ethernet switch providing a closed local network for all vacuum devices.
  • 16-port IOLAN terminal server for multiplexing/Ethernetizing all RS-232 serial devices.

Below is a high-level summary of where things stand, and what remains to be done.


 Set up of replacement controls server (c1vac).

  • Supermicro 1U rackmount server, running Debian 8.5.
  • Hosting an EPICS modbus IOC, scripted to start/restart automatically as a system service.
  • First Ethernet interface put on the martian network at
  • Second Ethernet interface configured to host a LAN at 192.168.114.xxx for communications with all vacuum electronics. It connects to a 16-port Ethernet switch installed in the vacuum electronics rack.
  • Server installed in vacuum electronics rack (see photo).

 Set up of Acromag terminals.

  • 6U rackmount chassis frame assembled; 15V DC, 24V DC, and Ethernet wired.
  • Acromags installed in chassis and configured for the LAN (5 XT1111 units, 2 XT1121 units).

 EPICS database migration.

  • All vacuum channels moved to the modbus IOC, with the database updated to address the new Acromags. [The new channels are running concurrently at "C1:Vac2-...." to avoid conflict with the existing system.]
  • Each hard channel was individually tested on the electronics bench to confirm correct addressing and Acromag operation.

 Set up of 16-port IOLAN terminal server (for multiplexing/Ethernetizing the serial devices).

  • Configured for operation on the LAN. Each serial device port is assigned a unique IP address, making the terminal server transparent to client TCP applications.
  • Most of the pressure gauges are now communicating with the controls server via TCP.

Ongoing this week:

  • [Jon] Continue migrating serial devices to ports on the terminal server. Still left are the turbo pumps, N2 gauge, and RGA.
  • [Jon] Continue developing Python code for communicating with gauges and pumps via TCP sockets. A beta version of gauge readout code is running now.
  • [Chub] Install feedthrough panels on the Acromag chassis. Connect the wiring from feedthrough panels to the assigned Acromag slots.
  • [Chub/Jon] Test all the hard EPICS channels on the electronics bench, prior to installing the crate in the vacuum rack.
  • [Chub/Jon] Install the crate in the vacuum rack; connect valve/pump readbacks and actuators; test each hard EPICS channel in situ.
  • [Jon] Once all the signal connections have been made, in situ testing of the Python interlock code can begin.
  14320   Mon Nov 26 21:58:08 2018 JonOmnistructure Serial Vacuum Signals

All the serial vacuum signals are now interfaced to the new digital controls system. A set of persistent Python scripts will query each device at regular intervals (up to ~10 Hz) and push the readings to soft channels hosted by the modbus IOC. Similar scripts will push on/off state commands to the serial turbo pumps.

IP Addresses/Comm Settings

Each serial device is assigned an IP address on the local subnet as follows. Its serial communication parameters as configured in the terminal server are also listed.

Device IP Address Baud Rate Data Bits Stop Bits Parity
MKS937a vacuum gauge controller 9600 8 1 even
MKS937b vacuum gauge controller 9600 8 1 even
GP307 vacuum gauge controller 9600 8 1 even
GP316a vacuum gauge controller 9600 8 1 even
GP316b vacuum gauge controller 9600 8 1 even
N2 pressure line gauge 9600 7 1 odd
TP2/3 9600 8 1 none

Hardware Modifications

  • Each of the five vacuum gauge controllers has an RJ45 adapter installed directly on its DB9/DB25 output port. Because the RJ45 cable now plugs directly into the terminal server, instead of passing through some additional adapters as it formerly did, it was necessary to reverse the wiring of the controller TXD and RXD pins to Ethernet pins. The DB9/25-to-RJ45 adapters on the back of the controllers are now wired as follows.
    • For the MKS controllers: DB2 (RXD) --> Eth4;  DB3 (TXD) --> Eth5;  DB5 (RTN) --> Eth6
    • For the Granville-Phillips controllers: DB2 (TXD) --> Eth5;  DB3 (RXD) --> Eth4;  DB7 (RTN) --> Eth6
  • I traced a communications error with the GP307 gauge controller all the way back to what I would have suspected least, the controller itself. The comm card inside each controller has a set of mechanical relay switches which set the communications parameters (baud rate, parity, etc.). Knowing that this controller was not part of the original installation, but was swapped in to replace the original in 2009, I pulled the controller from the rack and checked the internal switch settings. Sure enough, the switch settings (pictured below) were wrong. In the background of the photo is the unit removed in 2009, which has the correct settings. After setting the correct communications parameters, the controller immediately began communicating with the server. Did these readouts (PRP, PTP1) never work since 2009? I don't see how they could.
  14325   Fri Nov 30 15:53:52 2018 JonOmnistructureGeneralN2 pressure gauge fix

I've made a repair to the N2 pressure monitor. I don't believe the polarity of the analog signal into the controller actually was reversed. I found the data sheet (attached) for the transducer model we have installed. Its voltage should read ~0 at 0 PSI and 100mV at 100 PSI. As wired, the input voltage reads +80 mV as it should.

The controller calibrates the sensor voltage to PSI (i.e., applies a scale and offset) based on two settable reference points which appeared to be incorrect. I changed them to:

  1. 0 mV = 0 PSI (neglecting the small dark bias)
  2. 100 mV = 100 PSI

After the change, the pressure reads 80 PSI. Let's see if the time history now shows a sensible trend. 


[koji, gautam, jon, steve]

  • We suspect analog voltage from N2 pressure gauge is connected to interfacing Omega controller with the 'wrong' polarity (i.e pressure is rising over ~4 days and then rapidly falling instead of the other way around). This should be fixed.


  14327   Sun Dec 2 16:08:44 2018 JonOmnistructureUpgradeFeedthroughs for Vacuum Acromag Chassis

Below is an inventory of the signal feedthroughs that need to be installed on the vacuum Acromag crate this week.

Type Qty Connects to # Chs Signals
DB-37 female 1 Main AC relay box 18 Valve/roughing pump control
DB-9 female 5** Satellite AC relay boxes 3-4/box Valve control
DB-25 male 1 Turbo pump 1 controller 5 Pump status readbacks
DB-9 male 30 Valve position indicators 2/valve Valve position readbacks
DB-9 male 3 Roughing pump controllers 1/pump Pump status readbacks
DB-9 male 1 Cryo pump controller 2 Pump status readbacks

**The original documentation lists five satellite boxes (one for each test mass chamber and one for the beamsplitter chamber), but Chub reports not all of them are in use. We may remove the ones not used.

  14330   Tue Dec 4 10:38:12 2018 JonOmnistructureUpgradeUpdated Feedthrough List for Vacuum Acromag Chassis

Based on new input from Chub, attached is the revised list of signal cable feedthroughs needed on the vacuum system Acromag crate. I believe this list is now complete.

  14333   Thu Dec 6 17:33:33 2018 JonOmnistructureGeneralN2 line disconnected

I believe I finally have the N2 gauge working correctly. The wiring is unchanged from its original state and the controller has been recalibrated.

After letting the line pressure drop to 0 PSI as indicated by the analog gauge in the drill-press room, I recorded the number of counts read by the Omega controller. Then I pressurized the line to 80 PSI, again indicated by the analog gauge, and recorded the Omega counts again. I entered these two reference points into the controller (automatically determines the gain and offset from these), then confirmed the readings to agree with the anaog gauge as I varied the line pressure.

The two reference points are:

0 PSI  :  13 counts
80 PSI : 972 counts



[jon, gautam]

In the latest installment in this puzzler: turns out that maybe the trend of the "N2 pressure" channel increasing over the ~3 day timescale it takes a cylinder of N2 to run out is real, and is a feature of the way our two N2 cylinder lines/regulators are setup (for the automatic switching between cylinders when one runs out). In order to test this hypothesis, we'd like to have the line pressure be 0 initially, and then just have 1 cylinder hooked up. 


  14348   Wed Dec 12 18:27:07 2018 JonOmnistructureUpgradeAnalog signals, A/D Acromag added to vacuum system

There turned out to be a few analog signals for the vacuum system after all. The TP2/3 foreline pressure gauges were never part of the digital system, but we wanted to add them, as some of the interlock conditions should be predicated on their readings. Each gauge connects to an old Granville-Phillips 375 controller which only has an analog output. Interfacing these signals with the new system required installing an Acromag XT1221 8-channel A/D unit. Taking advantage of the extra channels, I also moved the N2 delivery line pressure transducer to the XT1221, eliminating the need for its separate Omega DPiS32 controller. When the new high-pressure transducers are added to the two N2 tanks, their signals can also be connected.

The XT1221 is mounted on the DIN rail inside the chassis and I have wired a DB-9 feedthrough for each of its three input signals. It is assigned the IP on the vacuum subnet. Testing the channels in situ revealed a subtley in calibrating them to physical units. It was first encountered by Johannes in a series of older posts, but I repeat it here in one place.

An analog-input EPICS channel can be calibrated from raw ADC counts to physical units (e.g., sensor voltage) in two ways:

  1. Via LINR="LINEAR" by setting the engineering-units fields EGUF="[V_max_adc]", EGUL="[V_min_adc]"
  2. Via LINR="NO CONVERSION" by manually setting the gain ASLO="[V/count]" and offset AOFF="[V_offset]"

From the documentation, under the engineering-units method EPICS internally computes:

where EGUF="eng units full scale", EGUL="eng units low", and "full scale A/D counts" is the full range of ADC counts. EPICS automatically infers the range of ADC counts based on the data type returned by the ADC. For a 16-bit ADC like the XT1221, this number is 2^16 = 65,536.

The problem is that, for unknown reasons, the XT1221 rescales its values post-digitization to lie within the range +/-30,000 counts. This corresponds to an actual "full scale A/D counts" = 60,001. If a multiplicative correction factor of 65,536/60,000 is absorbed into the values of EGUF and EGUL, then the first term in the above summation can be corrected. However, the second term (the offset) has no dependence on "full scale A/D counts" and should NOT absorb a correction factor. Thus adjusting the EGUF and EGUL values from, e.g., 10V to 10.92V is only correct when EGUL=0V. Otherwise there is a bias introduced from the offset term also being rescaled.

The generally correct way to handle this correction is to use the manual "NO CONVERSION" method. It constructs calibrated values by simply applying a specified gain and offset to the raw ADC counts:

calibrated val = (measured A/D counts)  x ASLO + AOFF

The gain ASLO="[(V_max_adc - V_min_adc) / 60,001]" and the offset AOFF="0". I have tested this on the three vacuum channels and confirmed it works. Note that if the XT1221 input voltage range is restricted from its widest +/-10V setting, the number of counts is not necessarily 60,001. Page 42 of the manual gives the correct counts for each voltage setting.

  14372   Thu Dec 20 08:38:27 2018 JonUpdateVACPumpdown tomorrow

Linked is the pumpdown procedure, contained in the old 40m documentation. The relevant procedure is "All Off --> Vacuum Normal" on page 11.


I just spoke to Jon who asked me to make this elog - we will be ready to test one or more parts of the pumpdown procedure tomorrow (12/20), so we should proceed as planned to put the heavy doors back on EY and OMC chambers at 9am tomorrow morning. Jon will circulate a more detailed procedure about the pumpdown steps later today evening.


  14375   Thu Dec 20 21:29:41 2018 JonOmnistructureUpgradeVacuum Controls Switchover Completed

[Jon, Chub, Koji, Gautam]


Today we carried out the first pumpdown with the new vacuum controls system in place. It performed well. The only problem encountered was with software interlocks spuriously closing valves as the Pirani gauges crossed 1E-4 torr. At that point their readback changes from a number to "L OE-04, " which the system interpreted as a gauge failure instead of "<1E-4." This posed no danger and was fixed on the spot. The main volume was pumped to ~10 torr using roughing pumps 1 and 3. We were limited only by time, as we didn't get started pumping the main volume until after 1pm. The three turbo pumps were also run and tested in parallel, but were isolated to the pumpspool volume. At the end of the day, we closed every pneumatic valve and shut down all five pumps. The main volume is sealed off at ~10 torr, and the pumpspool volume is at ~1e-6 torr. We are leaving the system parked in this state for the holidays. 

Main Volume Pumpdown Procedure

In pumping down the main volume, we carried out the following procedure.

  1. Initially: All valves closed (including manual valves RV1 and VV1); all pumps OFF.
  2. Manually connected roughing pump line to pumpspool via KF joint.
  3. Turned ON RP1 and RP2.
  4. Waited until roughing pump line pressure (PRP) < 0.5 torr.
  5. Opened V3.
  6. Waited until roughing pump line pressure (PRP) < 0.5 torr.
  7. Manually opened RV1 throttling valve to main volume until pumpdown rate reached ~3 torr/min (~3 hours on roughing pumps).
  8. Waited until main volume pressure (P1a/P1b) < 0.5 torr.

We didn't quite reach the end of step 8 by the time we had to stop. The next step would be to valve out the roughing pumps and to valve in the turbo pumps.

Hardware & Channel Assignments

All of the new hardware is now permanently installed in the vacuum rack. This includes the SuperMicro rack server (c1vac), the IOLAN serial device server, a vacuum subnet switch, and the Acromag chassis. Every valve/pump signal cable that formerly connected to the VME bus through terminal blocks has been refitted with a D-sub connector and screwed directly onto feedthroughs on the Acromag chassis.

The attached pdf contains the master list of assigned Acromag channels and their wiring.

  14383   Fri Jan 4 10:25:19 2019 JonOmnistructureVACN2 line valved off

Yes, for TP2 and TP3. They both have a small vent valve that opens automatically on shutdown.


Independent question: Are all the turbo forelines vented automatically? We manually did it for the main roughing line.



  14384   Fri Jan 4 11:06:16 2019 JonOmnistructureUpgradeVac System Punchlist

The base Acromag vacuum system is running and performing nicely. Here is a list of remaining questions and to-do items we still need to address.

Safety Issues

  • Interlock for HV supplies. The vac system hosts a binary EPICS channel that is the interlock signal for the in-vacuum HV supplies. The channel value is OFF when the main volume pressure is in the arcing range, 3 mtorr - 500 torr, and ON otherwise. Is there something outside the vacuum system monitoring this channel and toggling the HV supplies?
  • Exposed 30-amp supply terminals. The 30-amp output terminals on the back of the Sorensen in the vac rack are exposed. We need a cover for those.
  • Interlock for AC power loss. The current vac system is protected only from transient power glitches, not an extended loss. The digital system should sense an outage and put the IFO into a safe state (pumps spun down and critical valves closed) before the UPS battery is fully drained. However, it presently has no way of sensing when power has been lost---the system just continues running normally on UPS power until the battery dies, at which point there is a sudden, uncontrolled shutdown. Is it possible for the digital system to communicate directly with the UPS to poll its activation state?

Infrastructure Improvements

  • Install the new N2 tank regulator and high-pressure transducers (we have the parts; on desk across from electronics bench). Run the transducer signal wires to the Acromag chassis in the vacuum rack.
  • Replace the kludged connectors to the Hornet and SuperBee serial outputs with permanent ones (we need to order the parts).
  • Wire the position indicator readback on the manual TP1 valve to the Acromag chassis.
  • Add cable tension relief to the back of the vac rack.
  • Add the TP1 analog readback signals (rotation speed and current) to the digital system.  Digital temperature, current, voltage, and rotation speed signals have already been added for TP2 and TP3.
  • Set up a local vacuum controls terminal on the desk by the vac rack.
  • Remove gauges from the EPICS database/MEDM screens that are no longer installed or functional. Potential candidates for removal: PAN, PTP1, IG1, CC2, CC3, CC4.
  • Although it appeared on the MEDM screen, the RGA was never interfaced to the old vac system. Should it be connected to c1vac now?
  14387   Mon Jan 7 11:54:12 2019 JonConfigurationComputer Scripts / ProgramsVac system shutdown

I'm making a controlled shutdown of the vac controls to add new ADC channels. Will advise when it's back up.

  14388   Mon Jan 7 19:21:45 2019 JonConfigurationComputer Scripts / ProgramsVac system shutdown

ADC work finished for the day. The vac controls are back up, with all valves CLOSED and all pumps OFF.


I'm making a controlled shutdown of the vac controls to add new ADC channels. Will advise when it's back up.


  14390   Tue Jan 8 19:13:39 2019 JonUpdateUpgradeReady for pumpdown tomorrow

Everything is set for a second pumpdown tomorrow. We'll plan to start pumping after the 1pm meeting. Since the main volume is already at 12 torr, the roughing phase won't take nearly as long this time.

I've added new channels for the TP1 analog readings (current and speed) and for the two N2 tank pressure readings. Chub finished installing the new regulator and has run the transducer signal cable to the vacuum rack. In the morning he will terminate the cable and make the final connection to the Acromag.

Gautam and I updated the framebuilder config file, adding the newly-added channels to the list of those to be logged. We also set up a git repo containing all of the Python interlock/interfacing code: https://git.ligo.org/40m/vacpython. The idea is to use the issue tracker to systematically document any changes to the interlock code.

  14393   Wed Jan 9 20:01:25 2019 JonUpdateVACSecond pumpdown completed

[Jon, Koji, Chub, Gautam]


The second pumpdown with the new vacuum system was completed successfully today. A time history is attached below.

We started with the main volume still at 12 torr from the Dec. pumpdown. Roughing from 12 to 0.5 torr took approximately two hours, at which point we valved out RP1 and RP3 and valved in TP1 backed by TP2 and TP3. We additionally used the AUX dry pump connected to the backing lines of TP2 and TP3, which we found to boost the overall pump rate by a factor of ~3. The manual hand-crank valve directly in front of TP1 was used to throttle the pump rate, to avoid tripping software interlocks. If the crank valve is opened too quickly, the pressure differential between the main volume (TP1 intake) and TP1 exhaust becomes >1 torr, tripping the V1 valve-close interlock. Once the main volume pressure reached 1e-2 torr, the crank valve could be opened fully.

We allowed the pumpdown to continue until reaching 9e-4 torr in the main volume. At this point we valved off the main volume, valved off TP2 and TP3, and then shut down all turbo pumps/dry pumps. We will continue pumping tomorrow under the supervision of an operator. If the system continues to perform problem-free, we will likely leave the turbos pumping on the main volume and annuli after tomorrow.

New Vac Control Station

We installed a local controls terminal for the vacuum system on the desk in front of the vacuum rack (pictured below). This console is connected directly to c1vac and can be used to monitor/control the system even during a network outage or power failure. The entire pumpdown was run from this station today.

To open a controls MEDM screen, open a terminal and execute the alias


Similarly, to open a monitor-only MEDM screen, execute the alias

  14396   Thu Jan 10 19:59:08 2019 JonUpdateVACVac System Running Normally on Turbo Pumps

[Jon, Gautam, Chub]


We continued the pumpdown of the IFO today. The main volume pressure has reached 1.9e-5 torr and is continuing to fall. The system has performed without issue all day, so we'll leave the turbos continuously running from here on in the normal pumping configuration. Both TP2 and TP3 are currently backing for TP1. Once the main volume reaches operating pressure, we can transition TP3 to pump the annuli. They have already been roughed to ~0.1 torr. At that point the speed of all three turbo pumps can also be reduced. I've finished final edits/cleanup of the interlock code and MEDM screens.

Python Code

All the python code running on c1vac is archived to the git repo: 


This includes both the interlock code and the serial device clients for interfacing with gauges and pumps.

MEDM Monitor/Control

We're still using the same base MEDM monitor/control screens, but they have been much improved. Improvements:

  • Valves now light up in red when they are open. This makes it much easier to see at a glance what is valved in/out.
  • Every pump in the system (except CP1) is now digitally controlled from the MEDM control screen. No more need to physically push any buttons in the vaccum rack. 👍
  • The turbo pumps now show additional diagnostic readouts: speed (TP1/2/3), temperature (TP2/3), current draw (TP1/2/3), and voltage (TP2/3).
  • The foreline pressure gauge readouts for TP2/3 have been added to the digital system.
  • The two new main volume gauges, Hornet and SuperBee, have been added to the digital system as well.
  • New transducers have been added to read back the two N2 tank pressures.
  • The interlock code generates a log file of all its actions. A field in the MEDM screens specifies the location of the log file.
  • A tripped interlock (appearing as a message in the "Error message" field) must be manually cleared via the "Clear error message" button on the control screen before the system will accept any more manual valve input.

Note: The apparent glitches in the pressure and TP diagnostic channels are due to the interlock system being taken down to implement some of these changes.

  14410   Sun Jan 20 23:41:00 2019 JonOmnistructureVACNotes on vac serial comm, adapter wiring

I've attached my handwritten notes covering all the serial communications in the vac system, and the relevant wiring for all the adapters, etc. I'll work with Chub to produce a final documentation, but in the meantime this may be a useful reference.

ELOG V3.1.3-