40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 68 of 350  Not logged in ELOG logo
ID Date Author Type Category Subject
  14212   Sun Sep 23 19:32:23 2018 yukiConfigurationASCY end table upgrade plan

[ Yuki, Gautam ]

The setup I designed before has abrupt gouy phase shift between two steering mirrors which makes alignment much sensitive. So I designed a new one (Attached #1, #2 and #3). It improves the slope of gouy phase and the difference between steering mirrors is about 100 deg. To install this, we need new lenses: f=100mm, f=200mm, f=-250mm which have 532nm coating. If this setup is OK, I will order them.

There may be a problem: One lens should be put soon after dichroic mirror, but there is little room for fix it. (Attached #4, It will be put where the pedestal is.)  Tomorrow we will check this problem again.

And another problem; one steering mirror on the corner of the box is not easy to access. (Attached #5) I have to design a new seup with considering this problem.

Quote:

One of the example for improvement is just adding a new lens (f=10cm) soon after the doubling crystal. That will make mode matching better (100%) and also make separation better (85 deg) (Attachments #4 and #5). I'm checking whether we have the lens and there is space to set it. And I will measure current power of transmitted main laser in order to confirm the improvement of alignment.

 

Attachment 1: Pic_NewSetup0923_AUXYgreen.jpeg
Pic_NewSetup0923_AUXYgreen.jpeg
Attachment 2: ModeMatchingSolution_Result.pdf
ModeMatchingSolution_Result.pdf
Attachment 3: ModeMatchingSolution_Magnified_0923.jpg
ModeMatchingSolution_Magnified_0923.jpg
Attachment 4: pic0923_1.jpg
pic0923_1.jpg
Attachment 5: pic0923_2.jpg
pic0923_2.jpg
  14211   Sun Sep 23 17:38:48 2018 yukiUpdateASCAlignment of AUX Y end green beam was recovered

[ Yuki, Koji, Gautam ]

An alignment of AUX Y end green beam was bad. With Koji and Gautam's advice, it was recovered on Friday. The maximum value of TRY was about 0.5.

  14210   Sat Sep 22 00:21:07 2018 KojiUpdateCDSFrequent time out

[Gautam, Koji]

We had another crash of c1sus and Gautam did full power cycling of c1sus. It was a sturggle to recover all the frontends, but this solved the timing issue.

We went through full reset of c1sus, and rebooting all the other RT hosts, as well as daqd and fb1.

Attachment 1: 23.png
23.png
  14208   Fri Sep 21 19:50:17 2018 KojiUpdateCDSFrequent time out

Multiple realtime processes on c1sus are suffering from frequent time outs. It eventually knocks out c1sus (process).

Obviously this has started since the fiber swap this afternoon.

gautam 10pm: there are no clues as to the origin of this problem on the c1sus frontend dmesg logs. The only clue (see Attachment #3) is that the "ADC" error bit in the CDS status word is red - but opening up the individual ADC error log MEDM screens show no errors or overflows. Not sure what to make of this. The IOP model on this machine (c1x02) reports an error in the "Timing" bit of the CDS status word, but from the previous exchange with Rolf / J Hanks, this is down to a misuse of ADC0 Ch31 which is supposed to be reserved for a DuoTone diagnostic signal, but which we use for some other signal (one of the MC suspension shadow sensors iirc). The response is also not consistent with this CDS manual - which suggests that an "ADC" error should just kill the models. There are no obvious red indicator lights in the c1sus expansion chassis either.

Attachment 1: 33.png
33.png
Attachment 2: 49.png
49.png
Attachment 3: Screenshot_from_2018-09-21_21-52-54.png
Screenshot_from_2018-09-21_21-52-54.png
  14207   Fri Sep 21 16:51:43 2018 gautamUpdateVACc1vac1 is unresponsive

Steve pointed out that some of the vacuum MEDM screen fields were reporting "NO COMM". Koji confirmed that this is a c1vac1 problem, likely the same as reported here and can be fixed using the same procedure.

However, Steve is worried that the interlock won't kick in in case of a vacuum emergency, so we are leaving the PSL shutter closed over the weekend. The problem will be revisited on Monday.

  14206   Fri Sep 21 16:46:38 2018 gautamUpdateCDSNew PCIe fiber installed and routed

[steve, koji, gautam]

We took another pass at this today, and it seems to have worked - see Attachment #1. I'm leaving CDS in this configuration so that we can investigate stability. IMC could be locked. However, due to the vacuum slow machine having failed, we are going to leave the PSL shutter closed over the weekend.

Attachment 1: PCIeFiber.png
PCIeFiber.png
Attachment 2: IMG_5878.JPG
IMG_5878.JPG
  14205   Fri Sep 21 09:59:09 2018 yukiConfigurationASCY end table upgrade plan

[Yuki, Gautam]

Attachments #1 is the current setup of AUX Y Green locking and it has to be improved because:

  • current efficiency of mode matching is about 50%
  • current setup doesn't separate the degrees of freedom of TEM01 with PZT mirrors (the difference of gouy phase between PZT mirrors should be around 90 deg) 
  • we want to remotely control PZT mirrors for alignment
    (Attachments #2 and #3)

About the above two: 

One of the example for improvement is just adding a new lens (f=10cm) soon after the doubling crystal. That will make mode matching better (100%) and also make separation better (85 deg) (Attachments #4 and #5). I'm checking whether we have the lens and there is space to set it. And I will measure current power of transmitted main laser in order to confirm the improvement of alignment.

About the last:

I am considering what component is needed. 

Reference:

Attachment 1: Pic_CurrentSetup_AUXYgreen.jpeg
Pic_CurrentSetup_AUXYgreen.jpeg
Attachment 2: ModeMatchingSolution_Current.pdf
ModeMatchingSolution_Current.pdf
Attachment 3: ModeMatchingSolution_Current_Magnified.pdf
ModeMatchingSolution_Current_Magnified.pdf
Attachment 4: ModeMatchingSolution_Optimized.pdf
ModeMatchingSolution_Optimized.pdf
Attachment 5: ModeMatchingSolution_Optimized_Magnified.pdf
ModeMatchingSolution_Optimized_Magnified.pdf
  14203   Thu Sep 20 16:19:04 2018 gautamUpdateCDSNew PCIe fiber install postponed to tomorrow

[steve, gautam]

This didn't go as smoothly as planned. While there were no issues with the new fiber over the ~3 hours that I left it plugged in, I didn't realize the fiber has distinct ends for the "HOST" and "TARGET" (-5 points to me I guess). So while we had plugged in the ends correctly (by accident) for the pre-lunch test, while routing the fiber on the overhead cable tray, we switched the ends (because the "HOST" end of the cable is close to the reel and we felt it would be easier to do the routing the other way. 

Anyway, we will fix this tomorrow. For now, the old fiber was re-connected, and the models are running. IMC is locked.

Quote:

Pictures + more procedural details + proper routing of the protected fiber along cable trays after lunch. If this doesn't help the stability problem, we are out of ideas again, so fingers crossed...

  14202   Thu Sep 20 11:29:04 2018 gautamUpdateCDSNew PCIe fiber housed

[steve, yuki, gautam]

The plastic tubing/housing for the fiber arrived a couple of days ago. We routed ~40m of fiber through roughly that length of the tubing this morning, using some custom implements Steve sourced. To make sure we didn't damage the fiber during this process, I'm now testing the vertex models with the plastic tubing just routed casually (= illegally) along the floor from 1X4 to 1Y3 (NOTE THAT THE WIKI PAGE DIAGRAM IS OUT OF DATE AND NEEDS TO BE UPDATED), and have plugged in the new fiber to the expansion chassis and the c1lsc front end machine. But I'm seeing a DC error (0x4000), which is indicative of some sort of timing error (Attachment #1) **. Needs more investigation...

Pictures + more procedural details + proper routing of the protected fiber along cable trays after lunch. If this doesn't help the stability problem, we are out of ideas again, so fingers crossed...

** In the past, I have been able to fix the 0x4000 error by manually rebooting fb (simply restarting the daqd processes on fb using sudo systemctl restart daqd_* doesn't seem to fix the problem). Sure enough, seems to have done the job this time as well (Attachment #2). So my initial impression is that the new fiber is functioning alright yes.

Quote:

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)

Attachment 1: PCIeFiberSwap.png
PCIeFiberSwap.png
Attachment 2: PCIeFiberSwap_FBrebooted.png
PCIeFiberSwap_FBrebooted.png
  14201   Thu Sep 20 08:17:14 2018 SteveUpdateSUSlocal 3.4M earth quake

M3.4 Colton shake did not trip sus.

 

Attachment 1: local_3.4M.png
local_3.4M.png
  14200   Tue Sep 18 17:56:01 2018 not gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

I restarted the LSC models in the usual way via the c1lsc reboot script. After doing this I was able to lock the YARM configuration for more noise coupling scripting.

Quote:

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

 

  14199   Tue Sep 18 14:02:37 2018 SteveUpdatesafety safety training

Yuki Miyazaki received 40m specific basic safety training.

 

  14198   Mon Sep 17 12:28:19 2018 gautamUpdateIOOPMC and IMC relocked, WFS inputs turned off

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

  14197   Wed Sep 12 22:22:30 2018 KojiUpdateComputersSSL2.0, SSL3.0 disabled

LIGO GC notified us that nodus had SSL2.0 and SSL3.0 enabled. This has been disabled now.
The details are described on 40m wiki.

  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.

Quote:

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

Quote:

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.

 

  14195   Fri Sep 7 12:35:14 2018 gautamUpdateCDSADC replacement in c1lsc expansion chassis

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

Quote:

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.

Attachment 1: Screenshot_from_2018-09-07_12-34-52.png
Screenshot_from_2018-09-07_12-34-52.png
  14194   Thu Sep 6 14:21:26 2018 gautamUpdateCDSADC replacement in c1lsc expansion chassis

Todd E. came by this morning and gave us (i) 1x new ADC card and (ii) 1x roll of 100m (2017 vintage) PCIe fiber. This afternoon, I replaced the old ADC card in the c1lsc expansion chassis, and have returned the old card to Todd. 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. CDS is back to what is now the nominal state (Attachment #1) and Yarm is locked for Jon to work on his IFOcoupling study. We will monitor the stability in the coming days.

Quote:

(i) to replace the old generation ADC card in the expansion chassis which has a red indicator light always on and (ii) to replace the PCIe fiber (2010 make) running from the c1lsc front-end machine in 1X6 to the expansion chassis in 1Y3, as the manufacturer has suggested that pre-2012 versions of the fiber are prone to failure. We will do these opportunistically and see if there is any improvement in the situation.

Attachment 1: CDSoverview.png
CDSoverview.png
  14193   Wed Sep 5 10:59:23 2018 wgautamUpdateCDSCDS status update

Rolf came by today morning. For now, we've restarted the FE machine and the expansion chassis (note that the correct order in which to do this is: turn off computer--->turn off expansion chassis--->turn on expansion chassis--->turn on computer). The debugging measures Rolf suggested are (i) to replace the old generation ADC card in the expansion chassis which has a red indicator light always on and (ii) to replace the PCIe fiber (2010 make) running from the c1lsc front-end machine in 1X6 to the expansion chassis in 1Y3, as the manufacturer has suggested that pre-2012 versions of the fiber are prone to failure. We will do these opportunistically and see if there is any improvement in the situation.

Another tip from Rolf: if the c1lsc FE is responsive but the models have crashed, then doing sudo reboot by ssh-ing into c1lsc should suffice* (i.e. it shouldn't take down the models on the other vertex FEs, although if the FE is unresponsive and you hard reboot it, this may still be a problem). I'll modify I've modified the c1lsc reboot script accordingly.

* Seems like this can still lead to the other vertex FEs crashing, so I'm leaving the reboot script as is (so all vertex machines are softly rebooted when c1lsc models crash).

Quote:

c1lsc crashed again. I've contacted Rolf/JHanks for help since I'm out of ideas on what can be done to fix this problem.

  14192   Tue Sep 4 10:14:11 2018 gautamUpdateCDSCDS status update

c1lsc crashed again. I've contacted Rolf/JHanks for help since I'm out of ideas on what can be done to fix this problem.

Quote:

Starting c1cal now, let's see if the other c1lsc FE models are affected at all... Moreover, since MC1 seems to be well-behaved, I'm going to restore the nominal eurocrate configuration (sans extender board) tomorrow.

  14191   Wed Aug 29 14:51:05 2018 SteveUpdateGeneraltomorrow morning

Electrician is coming to fix one of the fluorenent light fixture holder in the east arm tomorrow morning at 8am. He will be out by 9am.

The job did not get done. There was no scaffolding or ladder to reach troubled areas.

  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.

Quote:

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

ITMX-UL & side magnets are stuck.

 

 

  14189   Wed Aug 29 09:56:00 2018 SteveUpdateVACMaglev controller needs service

TP-1 Osaka maglev controller  [  model TCO10M,  ser V3F04J07 ]  needs maintenance. Alarm led  on indicating  that we need Lv2 service.

The turbo and the controller are in good working order.

*****************************

Hi Steve,

Our maintenance level 2 service price is $...... It consists of a complete disassembly of the controller for internal cleaning of all ICB’s, replacement of all main board capacitors, replacement of all internal cooling units, ROM battery replacement, re-assembly, and mandatory final testing to make sure it meets our factory specifications. Turnaround time is approximately 3 weeks.

  RMA 5686 has been assigned to Caltech’s returning TC010M controller. Attached please find our RMA forms. Complete and return them to us via email, along with your PO, prior to shipping the cont

Best regards,

Pedro Gutierrez

Osaka Vacuum USA, Inc.

510-770-0100 x 109

*************************************************

our TP-1 TG390MCAB is 9 years old. What is the life expectancy of this turbo?

                        The Osaka maglev turbopumps are designed with a 100,000 hours(or ~ 10 operating years) life span but as you know most of our end-users are

                        running their Osaka maglev turbopumps in excess of 10+, 15+ years continuously.     The 100,000 hours design value is based upon the AL material being rotated at

                        the given speed.   But the design fudge factor have somehow elongated the practical life span.  

We should have the cost of new maglev & controller in next year budget. I  put the quote into the wiki.

 

                         

 

  14188   Wed Aug 29 09:20:27 2018 SteveUpdateSUSlocal 4.4M earth quake

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

ITMX-UL & side magnets are stuck.

 

Attachment 1: 4.4_La_Verne.png
4.4_La_Verne.png
Attachment 2: 3.4_&_4.4M_EQ.png
3.4_&_4.4M_EQ.png
  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?

Attachment 1: CDS_FE_STATUS.png
CDS_FE_STATUS.png
  14186   Tue Aug 28 15:29:19 2018 SteveFrogsPEMRat is cut

The rat is cut by mechanical trap and it was removed from ITMX south west location.

A nagy kover patkanyt a fogo elkapta es megolte.

Attachment 1: rat#2.png.png
rat#2.png.png
  14185   Mon Aug 27 09:14:45 2018 SteveUpdatePEMsmall earth quakes

Small earth quakes and suspensions. Which one is the most free and most sensitive: ITMX

 

Attachment 1: small_EQs_vs_SUSs.png
small_EQs_vs_SUSs.png
  14184   Fri Aug 24 14:58:30 2018 SteveUpdateSUSETMX trips again

The second big glich trips ETMX sus. There were small earth quakes around the glitches. It's damping recovered.

Quote:

Glitch, small amplitude, 350 counts  &  no trip.

Quote:

Here is an other big one

Quote:

A brief follow-up on this since we discussed this at the meeting yesterday: the attached DV screenshot shows the full 2k data for a period of 2 seconds starting just before the watchdog tripped. It is clear that the timescale of the glitch in the UL channel is much faster (~50 ms) compared to the (presumably mechanical) timescale seen in the other channels of ~250 ms, with the step also being much smaller (a few counts as opposed to the few thousand counts seen in the UL channel, and I guess 1 OSEM count ~ 1 um). All this supports the hypothesis that the problem is electrical and not mechanical (i.e. I think we can rule out the Acromag sending a glitchy signal to the coil and kicking the optic). The watchdog itself gets tripped because the tripping condition is the RMS of the shadow sensor outputs, which presumably exceeds the set threshold when UL glitches by a few thousand counts.

 

 

 

Attachment 1: glitches.png
glitches.png
  14183   Fri Aug 24 10:51:23 2018 SteveUpdateVACpumpdown 81 at day 38

 

 

Attachment 1: d38.png
d38.png
  14182   Fri Aug 24 08:04:37 2018 SteveUpdateGeneralsmall earth quake

 

 

Attachment 1: small_EQ.png
small_EQ.png
  14181   Thu Aug 23 16:10:13 2018 not KojiUpdateIMCMC/PMC trouble

Great, thanks!

Quote:

I don't know what had been wrong, but I could lock the PMC as usual.
The IMC got relocked by AutoLocker. I checked the LSC and confirmed at least Y arm could be locked just by turning on the LSC servos.

 

  14180   Thu Aug 23 16:05:24 2018 KojiUpdateIMCMC/PMC trouble

I don't know what had been wrong, but I could lock the PMC as usual.
The IMC got relocked by AutoLocker. I checked the LSC and confirmed at least Y arm could be locked just by turning on the LSC servos.

  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.
  14178   Thu Aug 23 08:24:38 2018 SteveUpdateSUSETMX trip follow-up

Glitch, small amplitude, 350 counts  &  no trip.

Quote:

Here is an other big one

Quote:

A brief follow-up on this since we discussed this at the meeting yesterday: the attached DV screenshot shows the full 2k data for a period of 2 seconds starting just before the watchdog tripped. It is clear that the timescale of the glitch in the UL channel is much faster (~50 ms) compared to the (presumably mechanical) timescale seen in the other channels of ~250 ms, with the step also being much smaller (a few counts as opposed to the few thousand counts seen in the UL channel, and I guess 1 OSEM count ~ 1 um). All this supports the hypothesis that the problem is electrical and not mechanical (i.e. I think we can rule out the Acromag sending a glitchy signal to the coil and kicking the optic). The watchdog itself gets tripped because the tripping condition is the RMS of the shadow sensor outputs, which presumably exceeds the set threshold when UL glitches by a few thousand counts.

 

 

Attachment 1: ETMX-UL_glitch.png
ETMX-UL_glitch.png
Attachment 2: PEM_4d.png
PEM_4d.png
  14177   Wed Aug 22 12:22:27 2018 ranaSummaryElectronicsInspection of the possible dual backplane interfaces for Acromag DAQ

I think we don't need to keep Crystal Ref: we can change this into a regular Wenzel box with no outside control or monitoring.

Quote:

 

  • Crystal Ref (D980353)
    • Schematic source: LIGO DCC D980353
    • Assesment: Only P1 (1A-4A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-4A

 

  14176   Wed Aug 22 08:44:09 2018 SteveUpdateGeneralearth quake

6.2M Bandon, OR did not trip any sus

 

Attachment 1: yesterday_EQs.png
yesterday_EQs.png
  14175   Wed Aug 22 00:22:05 2018 KojiSummaryElectronicsInspection of the possible dual backplane interfaces for Acromag DAQ

[Johannes, Koji]

We went around the LSC, PSL, IOO, and SUS racks to check how many dual backplane interfaces will be required.

Euro card modules are connected to the backplane with two DIN 41612 connectors (as you know). The backplane connectors provide DC supplies and GND connections.
In addition, they are also used for the input and output connections with the fast and slow machines.

According to the past inspection by Johannes, most of the modules just use the upper DIN41612 connector (called P1). But there are some modules exhibited the possibility of the additional use of the other connector (P2).

Tuesday afternoon Johannes and I made the list of the modules with the possible dual use. And I took a time to check the modules with DCC, Jay's schematics, and the visual inspection of the actual modules.

LSC Rack

  • Common mode servo (D040180 Rev B)
    • Schematic source D040180 Rev B D1500308
    • Assesment: Both P1 and P2 are to be connected to Acromag, but there are only a few channels on P2
    • P1: 1A-32A Digital In
    • P2: 1A-3A Analog Out (D32/33/34, SLOW MON and spare?)
            9A Digital Out for D35 (Limitter)
            10A-15A Spare
            16A Digital In (Latch Enable/Disable)
            25A, 25C  Differential Analog in (Differential offset input, indicated as "BIAS") 
  • PD Interface (D990543 Rev B)
    • Schematic source D990543 RevB
    • Assesment: No connection necessary. We don't monitor/control anything of any LSC PDs from Acromag.

PSL Rack

  • Generic DAQ Interface (D990155) - This is a DAC interface.
    • Schematic source: Jay's page D990155 Rev.B All the lines between P2 and P3 are connected.
    • Assesment: Only P2 is to be connected to Acromag.
    • P1 DAC mon -> not necessary
    • P2 A1-A16, Connected to DAC in P2-P3
  • PMC Servo
    • Schematic source: LIGO DCC D980352
    • Assesment: Only P1 (1A-9A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-9A
  • Crystal Ref (D980353)
    • Schematic source: LIGO DCC D980353
    • Assesment: Only P1 (1A-4A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-4A
  • TTFSS REV A
    • Schematic source: PNot found
    • Assesment: Probably Only P1 is sufficient. We need to analyze the board to figure out the channel assignment.

IOO Rack

  • PD Interface (D990543 Rev B)
    • Schematic source D990543 RevB
    • Assesment: Only P1 connection is sufficient.
  • Generic DAQ Interface (D990155)
    • Assesment: Remove the module. We already have the same module in PSL Rack. This is redundant.
  • Common mode servo (D040180 Rev B)
    • See above
  • Pentek Generic Input Board D020432
    • Schematic source Jay's page D020432-A
    • Assesment: No connection. There is no signal on the backplane.

SUS Rack

  • SUS Dewhitening
    • Schematic source: Jay's page D000316-A
    • Assesment: No connection.
    • We can omit Mon CHs.
    • Bypass/Inputs are already connected to the fast channels.

 

  14174   Tue Aug 21 17:32:51 2018 awadeBureaucracyEquipment loanOne P-810.10 Piezo Actuators element removed

I've taken a PI Piezo Actuator (P-810.10) from the 40m collection. I forgot to note it on the equipment checklist by the door, will do so when I next drop by.

  14173   Tue Aug 21 09:16:23 2018 SteveUpdateWiki AP table layout 20180821

 

 

Attachment 1: 20180821.JPG
20180821.JPG
  14172   Tue Aug 21 03:09:59 2018 johannesOmnistructureDAQPanels for Acromag DAQ chassis

I expanded the previous panels to 6U height for the new DAQ chassis we're buying for the upgrade. I figure it's best if we stick to the modular design, so I'm showing a panel for 8 BNC connectors as an example. The front panel has 12 slots, the back has 10 plus power connectors, switches, and the ethernet plug.

I moved the power switch to the rear because it's a waste of space to put it in the front, and it's not like we're power cycling this thing all the time. Note that the unit only requires +24V (for general operation, +20V also does the trick, as is the situation for ETMX) and +15V (excitation field for the binary I/O modules). While these could fit into a single CONEC power connector, it's probably for the better if we don't make a version that supplies a large positive voltage where negative is expected, so I put in two CONEC plugs for +/- 15 and +/- 24.

I want to order 5-6 of these as soon as possible, so if anyone wants anything changed or sees a problem, please do tell!

Attachment 1: auxdaq_40m_6U_front.pdf
auxdaq_40m_6U_front.pdf
Attachment 2: auxdaq_40m_6U_rear.pdf
auxdaq_40m_6U_rear.pdf
Attachment 3: auxdaq_40m_6U_BNC.pdf
auxdaq_40m_6U_BNC.pdf
  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.

  14170   Mon Aug 20 14:04:53 2018 johannesBureaucracyEquipment loanTwo C30642G PDs removed

EDIT: After discussing with Koji and checking the existing M2ISS PDs I put the two C30642G back and took two C30665GH (active diameter: 3mm) diodes. Only one of this type remains in storage.

I removed two C30642G photodiodes from the stash for the new M2ISS hardware and updated the wiki page accordingly.

  14169   Thu Aug 16 23:06:50 2018 gautamUpdateSUSAnother low noise bias path idea

I had a very fruitful discussion with Rich about this circuit today. He agreed with the overall architecture, but made the following suggestions (Attachment #1 shows the circuit with these suggestions incorporated):

  1. Use an Op27 instead of LT1128, as it is a more friendly part especially in these composite amplifier topologies. I confirmed that this doesn't affect the output voltage noise at 100 Hz, we will still limited by Johnson noise of the 15kohm series resistor.
  2. Take care of voltage distribution in the HV feedback path
    • I overlooked the fact that the passive filtering stage means that the DC current we can drive in the configuration I posted earlier is 150V / 25kohm = 6mA, whereas we'd like to be able to drive at least 10 mA, and probably want the ability to do 12 mA to leave some headroom.
    • At the same time, the feedback resistance shouldn't be too small such that the PA91 has to drive a significant current in the feedback path (we'd like to save that for the coil).
    • Changing the supply voltage of the PA91 from 150 V to 320 V, and changing the gain to x30 instead of x15 (by changing the feedback resistor from 14kohm to 29kohm), we can still drive 12 mA through the 25 kohms of series resistance. This will require getting new HV power supplies, as the KEPCO ones we have cannot handle these numbers.
    • The current limiting resistor is chosen to be 25ohms such that the PA91 is limited to ~26 mA. Of this, 300V / 30kohm ~ 10 mA will flow in the feedback path, which means under normal operation, 12 mA can safely flow through the coils.
    • Rich recommended using metal film resistors in the high voltage feedback path. However, these have a power rating, and also a voltage rating. By using 6x 5kohm resistors, the max power dissipated in each resistor is 50^2 / 5000 ~ 0.5 W, so we can get 0.6 W (or 1W?)  rated resistors which should do the job. I think the S102K or S104K series will do the job.
  3. Add a voltage monitoring capability.
    • This is implemented via a resistive voltage divider at the output of the PA91.
    • We can use an amplifier stage with whitening if necessary, but I think simply reading off the voltage across the terminating resistor in the ladder will be sufficient since this circuit will only have DC authority.
  4. Make a Spice model instead of LISO, to simulate transient effects.
    • I've made the model, investigating transients now.
  5. High voltage precautions:
    • When doing PCB layout, ensure the HV points have more than the default clearance. Rich recommends 100 mils.
    • Use a dual-diode (Schottky) as input protection for the Op27 (not yet implemented in Spice model).
    • Use a TVS diode for the moniotring circuit (not yet implemented in Spice model).
    • Make sure resistors and capacitors that see high voltage are rated with some safety margin.
  6. Consider using the PA95 (which Rich has tested and approves of) instead of the PA91. Does anyone have any opinions on this?

If all this sounds okay, I'd like to start making the PCB layout (with 5 such channels) so we can get a couple of trial boards and try this out in a couple of weeks. Per the current threat matrix and noises calculated, coil driver noise is still projected to be the main technical noise contribution in the 40m PonderSqueeze NB (more on this in a separate elog).

Quote:

Looks like this will do the job. I'm going to run this by Rich and get his input on whether this will work (this design has a few differences from Rich's design), and also on how to best protect from HV incidents.

Attachment 1: HVamp_schem.PDF
HVamp_schem.PDF
Attachment 2: Hvamp.zip
  14168   Thu Aug 16 14:48:14 2018 SteveUpdateVACwhy do we need a root pump?

Basic Pump Throughput Concepts

What is Pump Throughput?

The manufacturer of a vacuum pump supplies a chart for each pump showing pumping speed (volume in unit time) vs pressure. The example, for a fictitious pump, shows the pumping speed is substantially constant over a large pressure range.

By multiplying pumping speed by pressure at which that pumping speed occurs, we get a measure called pump throughput. We can tabulate those results, as shown in the table below, or plot them as a graph of pressure vs pump throughput. As is clear from the chart,  pump throughput (which might also be called mass flow) decreases proportionally with PRESSURE, at least over the pressure range where pumping speed is constant.

 

Pumping Speed Pressure Pressure x Pumping Speed
100 L/sec 10 torr 1000 torr.liter/sec
100 L/sec 1 torr 100 torr.liter/sec
100 L/sec 0.1 torr 10 torr.liter/sec
100 L/sec 0.01 torr

1 torr.liter/sec

The roughing pump speed actually will reach 0 l/s  at it's ultimate pressure performance.

Our roughing pump  pumping speed will slowly drop  as chamber pressure drops. Below 10 Torr this decrease is accelerated and bottoms out. This where the Root pump can help. See NASA evaluation of dry rough pumps...What is a root pump 

We have been operating succsessfully with a narrow margin. The danger is that the Maglev forline peaks at 4 Torr. This puts load on the small turbo TP2, TP3 &  large TP1

The temperature of these TP2 & 3  70 l/s drag turbos go up to 38 C and their  rotation speed slow to 45K rpm from 50K rpm because of the large volume 33,000 liters

Either high temp or low rotation speed of drag turbo or long time of overloading  can shut down the small turbo pumps......meaning: stop pumping, wait till they cool down

The manual gate valve installed helped to lower peak temp to 32C It just took too long.

We have been running with 2 external fans [one on TP1 & one on TP3]  for cooling and one aux drypump to help lowering the foreline pressure of TP2 & 3

The vacuum control upgrade should include adding root pump into the zero pumping speed range.

 

Atm1,   Pump speed chart:   TP1  turbo -red, root pump -blue and mechanical pump green. Note green color here representing an oily rotory pump. Our small drypumps [SH-100] typically run above 100 mTorr

                                           They are the forepump of TP2 & 3     Our pumpdown procedure: Oily Leybold rotory pumps ( with safety orifice 350 mT to atm ) rough to 500 mTorr

                                                                                                 Here we switch over to TP2 & 3 running at 50k RPM with drypumps SH-100 plus Aux Triscroll

                                                                                                 TP1- Maglev rotating full speed when V1 is opened at full volume at 500 mTorr 

                         History: the original design of the early 1990s had no dry scroll pumps. Oil free dry scrools replaced the oily forepumps of TP2 & TP3 in ~2002  at the cost of degrading the forline pressure somewhat.

                                     We had 2 temperature related Maglev failers in 2005 Aug 8 and 2006 April 5  Osaka advised us to use AUX fan to cool TP1  This helped. 

Atm2,   Wanted Root pump - Leybold EcoDry 65 plus  

Atm3,   Typical 8 hrs pumpdown from 2007 with TP2 & 3 

Atm4,   Last pumpdown zoomed in from 400 mT to 1mT with throttled gate  valve took 9 hrs  The foreline pressure of TP1 peaked at 290 mT, TP3 temperature peaked at 32C

            This technic is workable, but 9 hrs is too long.

Atm5,   The lowest pressure achived in  the 40m Vacuum Envelope 5e-7 Torr with pumps Maglev  ~300 l/s,  Cryo 1500 l/s  and 3 ion pumps of 500 l/s      [ in April 2002 at pumpdown 53 day 7 ] with annuloses at ~ 10 mTorr

Atm6,  Osaka TG390MCAB Throughput with screen ~300 L/s at 12 cfm backing pump

Attachment 1: PUMPSPEED_CHAR.pdf
PUMPSPEED_CHAR.pdf
Attachment 2: Leybold_Broschuere_8Seiten_EN_ANSICHT.pdf
Leybold_Broschuere_8Seiten_EN_ANSICHT.pdf
Attachment 3: pd65.jpg.png
pd65.jpg.png
Attachment 4: pd81completed.png
pd81completed.png
Attachment 5: best_.pdf
best_.pdf
Attachment 6: Osaka390.pdf
Osaka390.pdf
  14167   Thu Aug 16 07:50:28 2018 SteveUpdateVACpumpdown 81 at day 30

 

 

Attachment 1: pd81d30.png
pd81d30.png
  14166   Wed Aug 15 21:27:47 2018 gautamUpdateCDSCDS status update

Starting c1cal now, let's see if the other c1lsc FE models are affected at all... Moreover, since MC1 seems to be well-behaved, I'm going to restore the nominal eurocrate configuration (sans extender board) tomorrow.

  14165   Wed Aug 15 19:18:07 2018 gautamUpdateSUSAnother low noise bias path idea

I took another pass at this. Here is what I have now:

Attachment #1: Composite amplifier design to suppress voltage noise of PA91 at low frequencies.

Attachment #2: Transfer function from input to output.

Attachment #3: Top 5 voltage noise contributions for this topology.

Attachment #4: Current noises for this topology, comparison to current noise from fast path and slow DAC noise.

Attachment #5: LISO file for this topology.

Looks like this will do the job. I'm going to run this by Rich and get his input on whether this will work (this design has a few differences from Rich's design), and also on how to best protect from HV incidents.

Attachment 1: HV_Bias.pdf
HV_Bias.pdf
Attachment 2: HVamp_TF.pdf
HVamp_TF.pdf
Attachment 3: HVamp_noises.pdf
HVamp_noises.pdf
Attachment 4: currentNoises.pdf
currentNoises.pdf
Attachment 5: HVamp.fil.zip
  14164   Wed Aug 15 12:15:24 2018 gautamUpdateCOCMacroscopic SRC length for SR tuning

Summary:

It looks like we can have a stable SRC of length 4.044 m without getting any new mirrors, so this is an option to consider in the short-term.

Details:

  • The detailed calculations are in the git repo
  • The optical configuration is:
    • A single folding mirror approximately at the current SR3 location.
    • An SRM that is ~1.5m away from the above folding mirror. Which table the SRM goes on is still an open question, per the previous elog in this thread. 
  • The SRC length is chosen to be 4.044 m, which is what the modeling tells us we need for operating in the SR tuning instead of RSE.
  • Using this macroscopic length, I found that we could use a single folding mirror in the SRC, and that the existing (convex) G&H folding mirrors, which have a curvature of -700m, happily combine with our existing SRM (concave with a curvature of 142m) to give reasonable TMS and mode-matching to the arm cavity.
  • The existing SRM transmission of 10% may not be optimal but Kevin's calculations say we should still be able to see some squeezing (~0.8 dB) with this SRM.
  • Attachment #1 - corner plot of the distribution of TMS for the vertical and horizontal modes, as well as the mode-matching (averaged between the two modes) between the SRC and arm cavity.
  • Attachment #2 - histograms of the distributions of RoCs and lengths used to generate Attachment #1. The distributions were drawn from i.i.d Gaussian pdfs.

gautam 245pm: Koji pointed out that the G&H mirrors are coated for normal incidence, but looking at the measurement, it looks like the optic has T~75ppm at 45 degree incidence, which is maybe still okay. Alternatively, we could use the -600m SR3 as the single folding mirror in the SRC, at the expense of slightly reduced mode-matching between the arm cavity and SRC.

Attachment 1: SRC_MCMC_shortTerm.pdf
SRC_MCMC_shortTerm.pdf
Attachment 2: SRC_dists_shortTerm.pdf
SRC_dists_shortTerm.pdf
  14163   Tue Aug 14 23:14:24 2018 aaronUpdateOMCOMC scanning/aligning script

I made a script to scan the OMC length at each setpoint for the two TTs steering into the OMC. It is currently located on nodus at /users/aaron/OMC/scripts/OMC_lockScan.py.

I haven't tested it and used some ez.write syntax that I hadn't used before, so I'll have to double check it.

My other qualm is that I start with all PZTs set at 0, and step around alternative +/- values on each PZT at the same magnitude (for example, at some value of PZT1_PIT, PZT1_YAW, PZT2_PIT, I'll scan PZT2_YAW=1, then PZT2_YAW=-1, then PZT2_YAW=2). If there's strong hysteresis in the PZTs, this might be a problem.

  14162   Tue Aug 14 02:01:12 2018 gautamUpdateLSCDRMI locking - partial success

After tweaking the AS55 demod phase, SRM alignment, triggering settings, I got a few brief DRMI locks in tonight, I'm calling it a success (though this isn't really robust yet). The main things to do now are:

  • turn on all the boosts on the LSC loops - today I only managed to trigger the PRCL boost filters successfully without blowing up the lock.
  • measure all 3 loops, tweak gain as necessary.
  • Run some sensing lines, tune the demod phase.
  • The SRCL triggering is strange to me - SRCL loop is currently triggered on POP22_I, but the 2f1 buildup in the symmetric side does not say anything about the linearity of the SRCL error signal? Or are we just hoping the SRM is in the correct place and engaging the servo? Anyway, this setting seems to work but perhaps once the locking is more robust the triggering can be fixed.
  • do a quick NB - I expect the main change to be that the AS55_Q dark noise contribution would have gone up on account on the reduced amount of light at this port.

I think the main IFO characterization remaining to be done to determine the status of the IFO post vent is to measure the losses of the arm cavities. IMO, we will need to certainly fix the clipping at ETMY before we attempt some serious locking.

Attachment 1: DRMI.png
DRMI.png
  14161   Tue Aug 14 00:50:32 2018 gautamUpdateASSX arm ASS still not quite right?

While working on the single arm alignment, I noticed that today, i was able to get the X arm transmission back to ~1.22, and the GTRX to 0.52. These are closer to the values I remember from prior to the vent. Running the dither alignment promptly degrades both the green and IR transmissions. Since the pianosa SL7 upgrade, I can't use the sensoray to capture images, but to me, the spot looks a little off-center in Yaw on ETMX in this configuration, I've tried to show this in the phone grab (Atm #2). Maybe indicative of clipping somewhere upstream of ITMX?

Anyways, I'm pushing onwards for now, something to check out in the daytime.

Quote:

[koji, gautam]

After I effected the series resistance change for ETMX, the X arm ASS didn't work (i.e. IR transmission would degrade if the servo was run). Today, we succeeded in recovering a functional ASS servo yes.

We then tried to maximize GTRX using the PZT mirrors, but were only successful in reaching a maximum of 0.41. The value I remember from before the vent was 0.5, and indeed, with the IR alignment not quite optimized before we began this work, I saw GTRX of 0.48. But the IR dither servo signals indicate that the cavity axis may have shifted (spot position on the ITM, which is uncontrolled, seems to have drifred significantly, the Pitch signal doesn't stay on the StripTool scale anymore). So we may have to double check that the transmitted beam isn't falling off the GTRX DC PD.

Attachment 1: POXPOY.png
POXPOY.png
Attachment 2: IMG_7108.JPG
IMG_7108.JPG
ELOG V3.1.3-