40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 303 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  15228   Wed Feb 26 22:09:52 2020 gautamSummaryBHDProjected IFO noise budget, post-BHD upgrade

The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.

  15229   Wed Feb 26 23:50:51 2020 gautamUpdateIOOIMC checks

In the style of the KA characterization of the CM board, the AO path gain EPICS slider (IN2) of the IMC servo board was stepped by 1 dB through the full available range of -32 dB to +31 dB. For each value of the requested gain, I measured the TF from the injected signal (to IN2) to TP1A on the IMC servo board. I used the BNC connector for this test, whereas we use the LEMO connector for the AO path. The source was tee-d off at the SR785 side, with one leg going to IN2 of the IMC servo board, and the other going to CH1A of the SR785. TP1A of the IMC board was connected to CH2A of the SR785. 

Attachment #1 - Measured gain vs requested gain.

  • When debugging the CM board, it was this kind of test that revealed the faulty latch ICs.
  • -12 dB to -11 dB gain step looks anomalous, but overall the trend seems linear.
  • I was confused by why there should be a discontinuity at this stage of the gain stepping - seems like the scanning script I use changes the SR785 excitation amplitude at this point (from 300mV to 100mV). But why should the size of the excitation signal change the magnitude of the transfer function? Is this indicative of some loading issue?
  • There is an overall offset between the requested gain and measured gain of ~2-3 dB. This seems large.
  • There is nothing in the schematic which would have me expect this - there is a 1/2 divider at the positive input of the differential receiving stage, but this just cancels out the non-inverting gain of x2.

Attachment #2 - Frequency dependent transfer functions

  • There seem to be two families of curves - they correspond to <-12 dB and >-12 dB.
  • The feature at 90 kHz is strange - need to look at the schematic to see what this could be.

The motivation here is to try and figure out why I cannot engage the AO path smoothly in the CARM handoff part of lock acquisiton. I plan to use this information to do some loop modeling and project laser frequency noise coupling in various stages of the lock acquisition process.

Attachment 1: sliderCal.pdf
sliderCal.pdf
Attachment 2: AO_inputTFs.pdf
AO_inputTFs.pdf
  15230   Thu Feb 27 15:50:37 2020 gautamUpdateElectronicsFSS box power cable removed

In 1X1, there is a box labelled "FSS REF" below a KEPCO HV supply. This box had a power cable that wasn't actually connected to any power. I removed said cable.

  15231   Thu Feb 27 17:50:36 2020 gautamUpdatePSLc1psl setup setup

[many people]

in prep for the install tomorrow, we did the following:

  • Install the c1psl Supermicro in the 1X2 rack (Attachment 1). To make room we removed the anti-image filter and mounted it on the OMC rack.
  • Set up a local workstation (monitor+mouse+keyboard) for the Supermicro so we can do some local testing (Attachment 2).
  • Clear up the immediate area around the 1X1/1X2 rack, setup a cart for the Acromag.
  • Make sure there are sufficient adaptor boards cables (DB37, DB15, DB9, DB25, ethernet) etc available at the cart.
  • Label cables, connect on Acromag chassis end (Attachment 3).
  • Keep some large (A3) printouts of the channel mapping handy by the cart.
  • made sure we have open fuse-able DIN rail connectors for +/-15 V DC and +/-24 V DC for the Acromag box (we are waiting on some thinner gauge cabling for the 24V supply, once that arrives, we will power the box from the Sorensens. For now, they are powered by bench supplies on the cart).
  • made sure c1psl1 (still this name for the Supermicro) is ssh-able.

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch (I still want to work on the IFO tonight).

Attachment 1: 20200227_173535.jpg
20200227_173535.jpg
Attachment 2: 20200227_173454_HDR.jpg
20200227_173454_HDR.jpg
Attachment 3: 20200227_172659.jpg
20200227_172659.jpg
  15232   Thu Feb 27 17:59:02 2020 gautamUpdateLSCSome AO thoughts

While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.

I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:

  • Try CARM RF handoff with CM_SLOW gain starting at -12dB instead of -32dB.
  • Measure spectrum of REFL11_I when it is in the linear range.
  15233   Thu Feb 27 22:45:40 2020 gautamUpdateALSALS noise high

There was some UNELOGGED work at EX today. The DFD outputs were also hijacked for loss measurement. Unclear who the culprit was, but there is now a broad noise bump centered around ~180 Hz in the ALS X noise curve, which certainly wasn't there yesterday. Maybe let's keep the few working systems working, it is annoying to have to deal with these auxiliary issues every night. I'll push ahead with locking, hopefully the ALS noise is "good enough".

Attachment 1: ALSnoise.pdf
ALSnoise.pdf
  15234   Fri Feb 28 08:05:22 2020 gautamUpdatePSLc1psl setup setup

And so it begins.

Quote:

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch

  15235   Fri Feb 28 10:04:41 2020 gautamUpdatePSLc1psl setup setup

Summary:

There are several problems evident already.

  1. Several EPICS database entries were missing. WTF.
  2. After fixing the missing entries, the PMC could be locked. However, the IMC could not be locked.
  3. I think the FSS Interface card is not configured correctly.

For now, I've returned the old c1psl connections, the PMC and IMC are both locked. Need to do some debugging on the bench.

  15236   Fri Feb 28 19:37:18 2020 gautamUpdatePSLNew c1psl installed
  1. The new c1psl Acromag crate is now interfaced to the Eurocrate electronics in 1X1 (formerly VME c1psl) and 1X2 (formerly c1iool0).
  2. The PMC and IMC can be locked. We will investigate stability / duty cycle over the weekend.
  3. There were a few issues with the wiring - specifically, the worng kind of Acromag BIO unit (sourcing, whereas we want sinking) was used for the FSS board switches. Once Jordan fixed this issue, the IMC could be locked.
  4. I began to do the detailed tests of the IMC Servo card channels - there may be some issues with the boost stages, but I ran out of time yesterday, so tbc Monday.

On Monday, we will remove the old c1psl and c1iool0 machines from the electronics rack and install the Acromag crate in a more permanent way. We will also clean up some of the old cabling and cross connects, althoug the situation seems so complicated (some cross connects are also used by the rtcds c1ioo expansion chassis) that I am inclined not to remove any cables.

The area around 1X1/1X2 has a lot of dangling cables and general detritus. Be careful if you are walking around there. We will clean up on monday.

  15237   Mon Mar 2 16:14:47 2020 gautamUpdateCDSsome target directory cleanup

$TARGET_DIR = /cvs/cds/caltech/target

  • $TARGET_DIR/c1psl and $TARGET_DIR/c1iool0 moved to $TARGET_DIR/preAcromag_oldVME/
  • $TARGET_DIR/c1psl1 moved to $TARGET_DIR/c1psl 
  • $TARGET_DIR/c1psl/*.service and $TARGET_DIR/C1_PSL.cmd modified - i executed :%s/c1psl1/c1psl/g in vim.
  • $TARGET_DIR/preAcromag_oldVME/c1psl/autoBurt.req and $TARGET_DIR/preAcromag_oldVME/c1iool0/autoBurt.req catenated into $TARGET_DIR/c1psl/autoBurt.req. The first snapshot at 16:19 has been verified.

It remains to (Jon is taking care of these)

  • add a line to modbusIOC.service on the new c1psl machine that restores the latest burt snapshot on startup (this necessitated installation of a debian jessie libXp6 package on our debian buster machine because our shared EPICS is soooooooooooooo oooooooold)
  • change the hostname from c1psl1 to c1psl
  • update martian.hosts
  15238   Mon Mar 2 16:29:40 2020 gautamUpdateElectronicsc1psl VME crate removed, Acro-crate installed

[JV, JWR, YD, GV]

  • The old c1psl VME crate, and all the ribbon cables connected to it were removed from 1X1. They are presently dumped in the office area - we will clear these in the next few days, once the c1iool0 crate also gets removed from the rack.
  • The Acromag crate was capped on the top and bottom, had ears bolted on, and was installed on support rails in the newly cleared up space.
  • The strange orientation of the crate (with the intended backside facing the front of the rack) is to facilitate easy access to the "spare" channels we have in this box, e.g. for a future ISS or laser amplifier.
  • Remaining connections to make are (these will be done tomorrow along with the extrication of the c1iool0 VME crate):
    • PMC trans PD
    • FSS RMTEMP 
    • PSL shutter
    • 2W Mephisto diagnostic connector
    • 24 V DC from Sorensens via DIN connector (we are waiting on a new power cable to arrive).
Attachment 1: c1psl.pdf
c1psl.pdf
  15239   Mon Mar 2 16:35:12 2020 gautamUpdateCDSc1psl test status

Channel list with test status
== Test Status ==

[done] Lock PMC and IMC
[done] IMC Servo board test
[done] IMC LO Det Mon channel check
[0th order] WFS quadrant DC mon
[none] WFS I/F monitors
[0th order] WFS attenuators
[none] IOO QPD channels
[done] FSS readbacks 
[done] PMC readbacks


Some more detailed elogs about the individual tests will follow.

Basically, I have characterized the IMC Servo board in detail. The summary finding is that the IN2 (=AO gain) slider needs to be investigated. 

All other channels need to be verified in a more thorough fashion than my basic checks which were just to guarantee the core interferometer functionality, which is important to me.

  15240   Mon Mar 2 19:32:41 2020 gautamUpdateCDSc1rfm errors

Had to reboot both end machines and the c1rfm model to get the TRX and TRY signals to the LSC models. Now both arms can be locked using POX/POY respectively.

Attachment 1: RFMerrors.png
RFMerrors.png
  15241   Mon Mar 2 23:49:03 2020 JonSummaryBHDProjected IFO noise budget, post-BHD upgrade

Updated noise budget curves, now computed using the latest version of pygwinc. This resolves the inconsistency between the gwinc quantum noise curves and Gautam's analytic calculations. As before, the key configuration parameters are listed in the figure titles.

Attachment 1: Phase quadrature

Attachment 2: Amplitude quadrature

Attachment 3: Comparison to aLIGO design (phase quadrature)

Quote:

The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.

Attachment 1: 40m_phase_quad.pdf
40m_phase_quad.pdf
Attachment 2: 40m_ampl_quad.pdf
40m_ampl_quad.pdf
Attachment 3: 40m_aligo_comp.pdf
40m_aligo_comp.pdf
  15242   Tue Mar 3 17:20:14 2020 gautamUpdateElectronicsMore cabling removed

Jordan and I removed another 10 kg of cabling from 1X2. The c1iool0 crate now has all cabling to it disconnected - but it remains in the rack because I can't think of a good way to remove it without disturbing a bunch of cabling to the fast c1iool0 machine. We can remove it the next time the vertex FEs crash. Cross connects have NOT been removed - we will identify which cross connects are not connected to the fast system and trash those. 

Do we want to preserve the ability to use the PZT driver in 1X2?

  15243   Tue Mar 3 17:59:33 2020 YehonathanUpdateElectronicsPSL Shutter and PMC TRANSPD working

I used existing BNC cables running from the PSL table to the PSL rack and reassigned them to the PSL Shutter and PMC transmission PD channels.

The PSL shutter turned out to be a sinking channel. Jordan reconnected the PSL shutter wires to a sinking BIO Acromag. Channel list is updated.

Both channels have been tested to be working as expected.


gautam add on about EPICS:

  • the PSL shutter channels were previously hosted on c1aux.
  • I didn't comment out the original database entries on c1aux because we changed the prefix for all these channels - i.e. C1:AUX-PSL_Shutter --> C1:PSL-PSL_Shutter.
  • Modified the LSC offset script to close/open the PSL shutter by writing to the correct channel now.
  • there is some EPICS logic that checks the main volume pressure and prevents the opening of the PSL shutter if the main volume pressure is between 0.003 torr and 500 torr. I preserved this capability (so there are some associated soft channels in the database as well).

P.S - there is a problem we noticed - if the modbus process is started with the local subnet not having a fixed IP address, then all the EPICS channels will not be responsive. The way to fix this is to run the following sequence of commands:

sudo systemctl stop modbusIOC.service
sudo ifdown enp4s0
sudo ifup enp4s1
sudo ssytemctl start modbusIOC.service
  15244   Tue Mar 3 18:11:05 2020 JonSummaryBHDProjected IFO noise budget, post-BHD upgrade

Revised noise estimates, correcting a couple of factor of 2 and factor of pi errors found in the coil driver noise calculation. Also resolves a strain vs. displacement units confusion using the new pygwinc. Gautam and I have checked these noises against the analytical predictions and believe they are now accurate. Attachments are again:

Attachment 1: Phase quadrature

Attachment 2: Amplitude quadrature

Attachment 3: Comparison to aLIGO design (phase quadrature)

Attachment 1: 40m_phase_quad.pdf
40m_phase_quad.pdf
Attachment 2: 40m_ampl_quad.pdf
40m_ampl_quad.pdf
Attachment 3: 40m_aligo_comp.pdf
40m_aligo_comp.pdf
  15245   Tue Mar 3 19:11:48 2020 gautamUpdateLSCSome locking prep
  • Re-aligned and locked the arm cavities for IR and green.
  • Re-set trans normalization because after the c1iscex and c1iscey reboots, these didn't come back to the old values.
  15246   Wed Mar 4 11:10:47 2020 YehonathanUpdateComputersAllegra revival

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

I found a dirty old school mouse and connected it.

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

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

  15247   Wed Mar 4 11:16:37 2020 gautamUpdatePSLPMC realignment

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

  • we are sampling slightly different spots inside the PMC cavity which change the buildup by ~2-3%.
  • we are misaligned on the transmission/reflection photodiode.
  • ??
Attachment 1: PMCrealignment.png
PMCrealignment.png
  15248   Wed Mar 4 12:25:11 2020 gautamUpdateCDSBIO1 on c1psl is dead

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

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

  15249   Wed Mar 4 16:18:31 2020 gautamUpdateElectronicsMore cabling removed

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

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

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

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

Quote:

Do we want to preserve the ability to use the PZT driver in 1X2?

Attachment 1: 1X2EuroBefore.JPG
1X2EuroBefore.JPG
Attachment 2: IOO.png
IOO.png
  15250   Wed Mar 4 16:54:43 2020 gautamUpdateCDSc1auxex temporarily disconnected

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

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

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

  15251   Wed Mar 4 20:42:53 2020 gautamUpdateElectronicsC1PSL acromag crate is sitting on the floor

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

  15252   Wed Mar 4 21:02:49 2020 KojiUpdateElectronicsMore cabling removed

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

  15253   Wed Mar 4 22:38:31 2020 JonUpdatePSLc1psl communications problem resolved

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

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

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

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

  15254   Thu Mar 5 11:27:48 2020 gautamUpdateElectronicsC1PSL acromag crate is no longer sitting on the floor

[jordan, gautam]

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

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

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

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

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

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

Quote:

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

  15255   Thu Mar 5 15:03:48 2020 YehonathanUpdateElectronicsPSL Shutter and PMC TRANSPD working

[Jon, Yehonathan]

Summary

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

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

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

In more detail

FSS

Channels under test What was done
C1:PSL-FSS_SW1 Switched C1:PSL-FSS_SW1 and observed the IMC unlock
C1:PSL-FSS_SW2, C1:PSL-FSS_MIXERM Connected a signal to Test2 on FSS box and observed a proportional change on C1:PSL-FSS_MIXERM
C1:PSL-FSS_INOFFSET Disconnected feedback by switching C1:PSL-FSS_SW1. Tweaked C1:PSL-FSS_INOFFSET and observed a proportional response in C1:PSL-FSS_MIXERM
C1:PSL-FSS_MGAIN, C1:PSL-FSS_PCDRIVE Disconnected feedback, turned on some offset using C1:PSL-FSS_INOFFSET. Tweaked C1:PSL-FSS_MGAIN and observed a response in C1:PSL-FSS_PCDRIVE
C1:PSL-FSS_SLOWDC, C1:PSL-FSS_SLOWM Disconnected feedback. Tweaked C1:PSL-FSS_SLOWDC and obsereved a proportional response in C1:PSL-FSS_SLOWM
C1:PSL-FSS_FASTGAIN, C1:PSL-FSS_FAST Disconnected feedback, turned on some offset using C1:PSL-FSS_INOFFSET. Tweaked C1:PSL-FSS_FASTGAIN and obsereved a response in  C1:PSL-FSS_FAST

 

Frequency Ref

Channels under test What was done
C1:PSL-PMC_PHCON Observed the PMC unlocks when a big change in C1: PSL-PMC_PHCON is made
C1:PSL-PMC_RFADJ, C1:PSL-PMC_MODET Tweaked C1:PSL-PMC_RFADJ and obsereved a proportional response in C1:PSL-PMC_MODET
C1:PSL-PMC_PHFLIP Observed the PMC unlock when C1:PSL-PMC_PHFLIP is switched

 

PMC Servo Card

Channels under test What was done
C1:PSL-PMC_SW1, C1:PSL-PMC_PMCERR, C1:PSL-PMC_INOFFSET, C1:PSL-PMC_PZT Unlocked the PMC by switching C1:PSL-PMC_SW1. Tweaked C1:PSL-PMC_INOFFSET and observed a proportional change in C1:PSL-PMC_PMCERR and C1:PSL-PMC_PZT
C1:PSL-PMC_BLANK Observed the PMC unlock with when C1:PSL-PMC_BLANK is switched
C1:PSL-PMC_GAIN Unlocked the PMC by switching C1:PSL-PMC_SW1. Turned on some offset using  C1:PSL-PMC_INOFFSET. Tweaked C1:PSL-PMC_GAIN and observed response in C1:PSL-PMC_PZT
C1:PSL-PMC_SW2 Unlocked the PMC by switching C1:PSL-PMC_SW1. Connected a signal to TP2 on the PMC card and observed a proportional change in C1:PSL-PMC_PZT.
C1:PSL-PMC_RAMP

Unlocked the PMC by switching C1:PSL-PMC_SW1. Tweaked C1:PSL-PMC_RAMP and observed a change in C1:PSL-PMC_PZT.

C1:PSL-PMC_RFPDDC Observed a high value 0.5V when PMC is unlocked and a low value 0.03V when it is locked

 

WFSs

Channels under test What was done
C1:IOO-WFS*_SEG*_ATTEN

We misaligned MC1 to get a measurable signal in WFS channels. NDScoped the corresponding C1:IOO-WFS*_SEG*_I&Q channels and observed a change in those channels in response to switching the attenuation on and off.

C1:IOO-WFS*_LO_LOCK_MON Disconnected the LO cable from the WFS boards and observed C1:IOO-WFS*_LO_LOCK_MON go to zero.
C1:IOO-WFS*_SEG*_I&Q Connected a short SMA cable to the 29.5MHz frequency distribution board. Attenuated the signal by 20db and connected it to the different SEG channels one at a time and observed a response in C1:IOO-WFS*_SEG*_I&Q channels.
C1:IOO-WFS*_SEG*_DC We shined a laser pointer to the different quadrants and observed saturation in the corresponding C1:IOO-WFS*_SEG*_DC with no cross talks.

MC Servo

Channels under test What was done
C1:IOO-MC_SW1, C1:IOO-MC_OPTIONA, C1:IOO-MC_POL, C1:IOO-MC_OPTIONB,C1:IOO-MC_FASTSW These switches unlocked the IMC when flipped.
C1:IOO-MC_SW2, C1:IOO-MC_SUM_MON, C1:IOO-MC_SLOW_MON, C1:IOO-MC_FAST_MON A sine wave signal was injected in IN2 on the servo board. C1:IOO-MC_SW2 was switched on and the value of C1:IOO-MC_SUM_MON, C1:IOO-MC_SLOW_MON and C1:IOO-MC_FAST_MON changed accordingly.
C1:IOO-MC_SW3 Connected a scope to OUT2 on the servo board. Switched C1:IOO-MC_SW3 on and observed a signal on the scope.
C1:IOO-MC_EXCA_EN Unlocked the IMC by switching C1:IOO-MC_SW1 off. Connected a signal to EXC A and a scope to TP2A on the servo board and observed the signal on the scope when C1:IOO-MC_EXCA_EN was switched on.
C1:IOO-MC_EXCB_EN Unlocked the IMC by switching C1:IOO-MC_SW1 off. Connected a signal to EXC B and a scope to TP2B on the servo board and observed the signal on the scope when C1:IOO-MC_EXCB_EN was switched on.
C1:IOO-MC_REFL_OFFSET Unlocked the IMC by switching off. Tweaked C1:IOO-MC_REFL_OFFSET and observed a proportional change in C1:IOO-MC_SUM_MON.
C1:IOO-MC_LATCH_EN Tweaked the VCO gain slider and observed the latch switch off and on.
C1:IOO-MC_LIMIT Unlocked the IMC by switching C1:IOO-MC_SW1 off. Connected a sine wave signal to EXC B and enabled C1:IOO-MC_EXCB_EN. Ramped up the VCO gain. Raised the sine wave amplitude until C1:IOO-MC_LIMIT turned on.
C1:IOO-MC_LIMITER We ramped the VCO such that C1:IOO-MC_LIMIT was switched on. We switched C1:IOO-MC_LIMITER on and observed C1:PSL-FSS_MIXERM high value go down.

NPRO Diagnostics

Channels under test What was done
C1:PSL-NPRO_*

The signals were compared to previous values for consistency. Then they were unplugged from the Acromag chassis to confirm their values went to 0 and returned to the same values after being reconnected.

  15256   Thu Mar 5 19:45:23 2020 JonSummaryPSLC1PSL in-situ test results

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

Post-installation modifications

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

Issues identified during testing

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

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

  15258   Fri Mar 6 01:12:10 2020 gautamUpdateElectronicsIMC Servo IN2 path looks just fine

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

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

Attachment 1: AO_inputTFs_5Mar.pdf
AO_inputTFs_5Mar.pdf
Attachment 2: sliderCal_5Mar.pdf
sliderCal_5Mar.pdf
  15259   Fri Mar 6 01:19:19 2020 gautamUpdateIOOExcess laser frequency noise

Summary:

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

Details:

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

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

Attachment 1: MCF.pdf
MCF.pdf
Attachment 2: ExcessFreqNoise.pdf
ExcessFreqNoise.pdf
Attachment 3: ALSnoise.pdf
ALSnoise.pdf
  15260   Fri Mar 6 16:33:11 2020 gautamUpdateIOOExcess laser frequency noise

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

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

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

  15261   Sat Mar 7 15:18:30 2020 gautamUpdateSUSEQ tripped some suspensions

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

Attachment 1: EQ_6Mar.png
EQ_6Mar.png
  15262   Tue Mar 10 14:30:16 2020 yehonathanUpdateSUS 

ETMX was grossly misaligned.

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

7:00PM with Koji

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

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

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

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

Attachment 1: Screenshot_from_2020-03-10_19-02-31.png
Screenshot_from_2020-03-10_19-02-31.png
  15263   Tue Mar 10 19:58:16 2020 yehonathanUpdateSUS 

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

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

  15264   Tue Mar 10 19:59:09 2020 YehonathanUpdateLoss MeasurementArm transfer function measurement

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

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

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

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

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

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

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

Attachment 1: YArmFrequencyResponse.pdf
YArmFrequencyResponse.pdf
  15265   Wed Mar 11 16:46:25 2020 HangUpdateIOOMC2 coil balancing

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

Quote:

[Yehonathan, Hang]

We did some quick DC balancing of the MC2 coil drivers to reduce the l2a coupling. We updated the gains in the C1:SUS-MC2_UL/UR/LR/LLCOIL to be 1, -0.99, 0.937,-0.933, respectively. The previous values were 1, -1, 1, -1.

The procedures are the following:

Lock IMC.

Drive UL+LR and change the gain of LR to zero pitch.

Drive UR+LL and change the gain of LL to zero pitch.

Lastly, drive all 4 coils and change UR & LR together to zero yaw. 

We used C1:SUS-MC2_LOCKIN1_OSC to create the excitations at 33 Hz w/ 30,000 cts. The angular error signals were derived from IMC WFSs.

While this time we did things by hand, in the future it should be automated as the procedure is sufficiently straightforward. 

  15266   Wed Mar 11 18:12:53 2020 gautamSummaryPSLWFS Demod board modifications

[koji, gautam]

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

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

Before removing the boards from the eurocrate: 

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

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

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

Quote:

WFS DC channels are saturating when the IMC is unlocked.

Attachment 1: D980233-B_Mar2020Mods.pdf
D980233-B_Mar2020Mods.pdf
  15267   Wed Mar 11 21:03:57 2020 KojiUpdateBHDSOS packages from Syracuse

I opened the packages send from Syracuse.

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

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

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

- An unrelated tower was also included.

Attachment 1: P_20200311_203449_vHDR_On.jpg
P_20200311_203449_vHDR_On.jpg
  15268   Thu Mar 12 01:33:21 2020 gautamUpdateLSCResuming locking activities

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

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

                               when doing the AM sweeps of cavities

make sure to cross-calibrate the detectors

                       else you'll make of science much frivolities

            much like the U.S. elections electors

  15270   Thu Mar 12 11:10:49 2020 YehonathanUpdateGeneralPMC got unlcoked

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

 

Is PSL Acromag already failing?

 

I restarted the IOC but it didn't help.

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

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

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

  15271   Thu Mar 12 12:44:34 2020 gautamUpdateGeneralPMC got unlcoked

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

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

Quote:

I restarted the IOC but it didn't help.

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

  15272   Thu Mar 12 16:13:16 2020 gautamUpdatePSLTemperature sensors connected to Acromag

[jordan, gautam]

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

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

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

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

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

Attachment 1: P_20200317_153736_vHDR_On_2.jpg
P_20200317_153736_vHDR_On_2.jpg
  15273   Fri Mar 13 00:32:38 2020 gautamUpdateLSCSome progress

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

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

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

Attachment 1: RFonly_CARM.png
RFonly_CARM.png
Attachment 2: CARMTF.pdf
CARMTF.pdf
  15274   Fri Mar 13 12:48:47 2020 Larry WallaceUpdateelogCert Renewal

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

  15275   Fri Mar 13 14:28:39 2020 gautamUpdatePSLAdded tees to PMC Trans and REFL

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

  15276   Fri Mar 13 20:00:50 2020 JonUpdateComputersLoopback monitoring for slow machines

Summary

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

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

Implementation

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

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

c1auxex

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

​c1vac

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

c1psl

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

c1iscaux

  • ​Restarted IOC

c1susaux

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

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

Attachment 1: Screen_Shot_2020-03-13_at_7.59.55_PM.png
Screen_Shot_2020-03-13_at_7.59.55_PM.png
  15277   Mon Mar 16 15:23:03 2020 YehonathanUpdateLoss MeasurementArm transfer function measurement

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

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

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

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

I calibrated the Y arm frequency response measurement.

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

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

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

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

Attachment 1: Cross_calibration_setup.jpg
Cross_calibration_setup.jpg
Attachment 2: PDA520overPDA255_Response.pdf
PDA520overPDA255_Response.pdf
Attachment 3: YArmFrequencyResponse.pdf
YArmFrequencyResponse.pdf
ELOG V3.1.3-