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.
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:
* 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.
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.
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.
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.
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.
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...
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.
[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
Test 2: PRC Mode Scan
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.
[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.
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.
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.
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.
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.
More progress on the AUX-laser cavity scans.
Both data sets are attached.
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.
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.
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.
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.
From experience with the 40m, the main challenges to repeating this measurement at the sites will be the following.
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.
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.
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 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?
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.
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.
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.
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 192.168.113.72. 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.
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.
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.
I've set up a closed subnetwork for interfacing the vacuum hardware (Acromags and serial devices) with the new controls machine (c1vac; 192.168.113.72). 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:
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:
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.
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.
New hardware has been installed in the vacuum controls rack. It is shown in the below post-install photo.
Below is a high-level summary of where things stand, and what remains to be done.
✔ Set up of replacement controls server (c1vac).
✔ Set up of Acromag terminals.
✔ EPICS database migration.
✔ Set up of 16-port IOLAN terminal server (for multiplexing/Ethernetizing the serial devices).
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.
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.
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:
After the change, the pressure reads 80 PSI. Let's see if the time history now shows a sensible trend.
[koji, gautam, jon, steve]
Below is an inventory of the signal feedthroughs that need to be installed on the vacuum Acromag crate this week.
**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.
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.
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:
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.
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 192.168.114.27 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:
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.
Linked is the pumpdown procedure, contained in the old 40m documentation. The relevant procedure is "All Off --> Vacuum Normal" on page 11.
[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.
In pumping down the main volume, we carried out the following procedure.
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.
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.
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.
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.
I'm making a controlled shutdown of the vac controls to add new ADC channels. Will advise when it's back up.
ADC work finished for the day. The vac controls are back up, with all valves CLOSED and all pumps OFF.
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.
[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.
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
[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.
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.
We're still using the same base MEDM monitor/control screens, but they have been much improved. Improvements:
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.
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.