40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 232 of 355  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  16378   Mon Oct 4 20:46:08 2021 KojiUpdateElectronicsSatellite amp box adapters

Thanks. You should be able to find the chassis-related hardware on the left side of the benchtop drawers at the middle workbench.

Hardware: The special low profile 4-40 standoff screw / 1U handles / screws and washers for the chassis / flat-top screws for chassis panels and lids

  14417   Thu Jan 24 22:55:50 2019 gautamUpdateElectronicsSatellite box S/N 102 investigation

I had taken Satellite box S/N 102, from the SRM suspension, down to the Y-end as part of debugging. However, at some point, I stopped getting readbacks from the shadow sensor PDs, even with the Sat. Box tester hooked up (so as to rule out anything funky with the actual OSEMs). Today evening, I did a more systematic investigation. Schematic with component references is here.

  1. Used mini-grabbers and a bench power supply to connect +/-24V to C57 and C58.
  2. Checked that all ICs were getting +/- 15 V to the supply pins.
  3. Debugged individual channels, checking voltages at various nodes
    • Found that the "PD K" bias voltage was anomalosly low.
    • Found that the inverting input of U3C wasn't ground.
    • The above findings are summarized in Attachment #2.
    • This suggested something was wrong with the Quad OpAmp LT1125 IC, so I elected to switch it out.
    • During the desoldering process, the pads for the "NC" pins came off (Attachment #1) - this has happened to me before on these old boards. I don't think I applied excess heat during the desoldering (I used 650F).
    • Replaced the IC, and measured the expected 10V at the "PD K" node.
  4. I then connected the tester box and verified all the shadow sensor channels (LED + PD) work as expected, using the front panel J3 and the "octopus cable".
  5. It remains to verify that the coil driver signals get correctly routed through the Satellite box before giving this box a pass certification.

The question remains as to what caused this failure mode - I can't think of why that particular IC was damaged during the Satellite box swapping process - is this indicative of some problem elsewhere in the ETMY OSEM/coil driver electronics chain?

Attachment 1: IMG_7294.JPG
IMG_7294.JPG
Attachment 2: D961289-B2.pdf
D961289-B2.pdf
  14421   Tue Jan 29 17:19:16 2019 gautamUpdateElectronicsSatellite box S/N 105 repaired

[chub, koji, gautam]

Attachment #1 shows the signal routing near the Satellite box. Somehow, the female 64 pin IDC connector that brings the signals from the coil driver board wasn't mating well with the mail connector on the Satellite box front panel. This is a connector specific problem - plugging the female end into one of the male connectors inside the Satellite box yielded signal continuity. The problem was resolved by re-making both connections -by driving the EPICS bias slider through its full range, we were able to see the full voltage swing at the DB connectors going to the flange

This kind of flakiness could be all around the lab, and could be responsible for many of the suspension "mysteries". To re-iterate, the problem seems to be the way the female sockets of the connector mates with the male pins - while the actual crimping points may look secure, there may not be signal continuity.

Now that this problem is resolved, tomorrow we will recover the cavity alignment and possibly start a pumpdown.


Unrelated to this work - the spare satellite box (S/N #100), which had a note on it that said "low voltages", was tested. The "low voltages" referred to the OSEM shadow sensor voltages being low when the LED was completely unobscured. The reason was that the mod to increase the drive current to 25 mA had not yet been implemented on this unit. I added the appropriate 806 ohm resistors, and verified that the voltages were correct, so now we have a working spare. It is stored in the "photodiode" cabinet along the east arm, together with the tester boxes. 

Attachment 1: IMG_7301.JPG
IMG_7301.JPG
  1198   Sat Dec 20 23:37:43 2008 robOmnistructureGeneralSaturday Night Fever after presumed power failure

Just came by to pick something up...

... alarm handlers screeching...

... TP1 failure--closing V1... call Steve... Steve says ok till tomorrow...

... all front ends down (red)...

... all suspensions watchdogged...

... all (I think) servos off...

... PSL shutter closed ...

... chiller at 15C ... I turned it off to prevent condensation in PA...

... MOPA shutter closed... turned off key on Lightwave power supply

... good luck all, and happy holidays!
  1495   Sun Apr 19 03:34:05 2009 YoichiUpdateLockingSaturday night lock
Tonight I was able to go up to arm power = 33, by mainly tweaking the DARM gain. A small progress.
In order to give more phase margin to the CARM MC_L path, I added a 300:100 filter to C1:LSC-MC.
To reduce the load to the lsc computer I deleted several filters from the filter bank, which were not used in the locking scripts.
Before I deleted the filters, I checked in the current chans directory into the svn repository.
If you want to restore the deleted filters, go back to the revision 36142.
  16484   Wed Nov 24 14:34:15 2021 YehonathanUpdateBHDSaving on SUSAUX slow channels

Koji found out that the stock for BIO Acromag modules is very low and that the lead time for ordering new ones is ~ 1-year X-o.

We figure we might need to minimize the number of modules but still keep the Acromag chassis functional.

 

Looking at the new C1AUXEY feed-throughs spreadsheet one can see that we actually normally need only 1 BIO (not 2) module since there are 16 suspensions related bios + 1 green shutter which is unrelated to SUSAUX so there is no room to cut back here.

 

There are 16 analog input channels, 5 for PDMONs and 5 VMONs, and 6 spares which require 2 ADCs. Removing the spares and 2 monitoring channels will be enough to get us to 1 ADC.

  10207   Tue Jul 15 22:23:51 2014 AndresUpdate40m Xend Table upgradeScan the Xarm for the mode matching

 Nick and I with the help of Jenne scan the green light when the cavity is unlocked. Nick placed a Beam dump on the IR so that we can just scan the green, but it was removed as soon as we finished with the measurement. I'm working on the calculation, and i'll be posted solution tonight.

  2499   Sun Jan 10 23:22:56 2010 JenneSummaryGeneralScattering Measurements of 35W Beam Dumps

On Friday, Rana and I measured the scatter coming from the 35W beam dumps.

(These are the ones with big aluminum heat sinks on the back that kind of look like little robots with 2 legs...inside the horn is a piece of polished silicon at Brewster's Angle.)

 

SETUP:

For the measurement, we used the Scatterometer setup at the 40m on the small optical table near MC2. 

We used a frequency of 1743 Hz for the Chopper, and this was also used as the reference frequency for the SR830 Lock-In Amplifier. 

The settings on the Lock-In were as follows:

Input A

24dB/octave

AC coupled

Floating input

"Low Noise"

Time Constant = 1sec

'Scope reading Output A, Output A set to 'Display', and A's display set to "R" (as in magnitude).

Sensitivity changed throughout the experiment, so that's quoted for each measurement.

 

MEASUREMENTS:

White Paper Calibration - white paper placed just in front of Beam Dump.  Sensitivity = 500microVolts.  Reading on 'scope = 7V

Laser Shuttered.  Sensitivity = 500microVolts. 'scope reading = 9mV.

Black Glass at Beam Dump location.  Sensitivity = 500microVolts.  Reading on 'scope = 142mV.   (DON'T touch the glass....measure the same setup with different sensitivity)

Black Glass at Beam Dump location (Not Touched since prev. measurement). Sensitivity = 10microVolts. Reading on 'scope = 6.8V

Laser Shuttered. Sensitivity = 10microVolts. 'scope Reading = 14mV +/- 10mV (lots of fluctuation).

Black Glass Wedge Dump at Beam Dump location. Sensitivity = 10microVolts. 'scope = 100mV.

Beam Dump with original shiny front plate. Sensitivity = 10microVolts.  'scope railing at 11V

Beam Dump with front plate removed. Sensitivity = 10microVolts. 'scope reading = 770mV

Beam Dump, no front plate, but horn's opening surrounded by 2 pieces of Black Glass (one per side ~1cm opening), BG is NOT flush with the opening...it's at an angle relative to where the front plate was.  Sensitivity = 10microV. 'scope = 160mV +/- 20mV.

Beam Dump, no front plate, only 1 piece of Black Glass. Sensitivity = 10microV. 'scope reading = 260mV.

Beam Dump, no front plate, 2 pieces of Black Glass, normal incidence (the BG is flush with where the front plate would have been). Sensitivity = 10microV. 'Scope reading = ~600mV

 

CALIBRATION:

Using our calibration numbers (Black Glass measured at 2 different sensitivities, not touching the setup between the measurements), we can find the calibration between our 2 different sets of measurements (at 500microV and 10microV), to compare our Beam Dump with regular white paper. 

BG at 500uV was 142mV.  BG at 10uV was 6.8V.    6.8V/0.142V = 47.9 

So the white paper, which was measured at 500uV sensitivity, would have been (7V * 47.9) = 335 V in 10uV sensitivity units. 

This is compared to the BG wedge dump at 10uV sensitivity of 100mV, and the Beam Dump reading of 770mV, and the Beam Dump with-black-glass-at-the-opening reading of 160mV.

So our Silicon/Steel horn dump is ~8x worse than a Black Glass wedge and (335 / 0.77) = 435x better than white paper.

We used regular white paper as a calibration because it has a Lambertian reflectance. For some general idea of how to do these kinds of scatter measurements, you can look at this MZ doc.

Assuming that our white paper had a BRDF of (1/pi)/steradian, we can estimate some numbers for our setup:

Sensitivity (signal with the laser shuttered) = (0.02 / 335 / pi) = 2 x 10^-5 / sr.   This is ~3x worse than the best black glass surfaces.

Our wedge = (0.1 / 335 / pi) = 1 x 10^-4 / sr.  Needs a wipe.

Our Silicon-Steel Horn = (0.75 / 335 / pi) = 7 x 10^-4 / steradian.

Our measurements were all made at a small angle since we are interested in scatter back along the incoming beam. We were using a 1" lens to collect the scatter onto a PDA55. The distance from the beam to the center of the lens was ~2" and the detector's lens was ~20" from the front of the horn. So that's an incident angle of ~3 deg.

CONCLUSIONS:

* It seems that any front plate other than Black Glass is probably worse than just having no front plate at all.

* If we put in a front plate, it shouldn't be normal to the incident beam.  Black Glass at normal incidence was almost at the same level as having no front plate. So if we're going to bother with a front plate, it should be about 30deg or 40deg from where the original front plate was.

* No front plate on the Dump is about 7x a Black Glass wedge dump.

* The silicon looks like it might have some dust on it (as well as the rest of the inside of the horn).  We should clean everything.  (Maybe with deionized nitrogen?)

* We should remeasure the Beam Dump using polished steel at a small (30-40deg) angle as the front plate. 

 

ATTACHMENTS:

 * Photos taken with the Olympus camera, which has its IR blocker removed.

* In the photo you can see that we have a lot of reflection off of the horn on the side opposite from the silicon.

* The 2nd picture is of the scatterometer setup.

Attachment 1: P1090014_copy.JPG
P1090014_copy.JPG
Attachment 2: ScatterometerSetup.png
ScatterometerSetup.png
  2507   Tue Jan 12 09:14:52 2010 steveSummaryGeneralScattering Measurements of 35W Beam Dumps

 

 What was the power level, polarization and beam size at beam trap?

  7402   Tue Sep 18 18:24:50 2012 JenneUpdateGeneralScattering in BS chamber or ITMX chamber

I have touched PZT2 such that the beam goes through the 45 degree non-iris target on the beam splitter.  This puts the beam at the center of ITMY, and without moving the BS, at the center of ITMX.  I say "at the center", but what I really mean is I put the target approximately at the center, within what looks like, say, 2 mm, by looking from above.  The target was many (5ish) centimeters away from the optic though, so that's why my side-to-side centering isn't so precise.  Given that, the beam was always more than half going through the hole of the target for both ITMs, so I'm claiming that the spots on the ITMs are within a few mm of center.

With this alignment, the beam was also hitting the center of the SRM (with all the same caveats).

I was able to get the SRM to retroreflect, while I still had Michelson fringing, so I think that I had the SRMI at least close to aligned (I was looking at the SRM retroreflection at the beam splitter, not all the way out to the AS port).  PRM is also pretty easy to align.

We're hitting the top of the AS camera, so I think things are pretty good.  I don't see beam on the REFL camera, but no investigation of that has been done as yet.

There is some scattering going on in the BS / ITMX chambers that's making me kind of unhappy.  I don't know how to get this to embed the youtube video, so here's the embed link, as well as the regular link:

youtube of AS and BS/PRM camera.

<iframe width="420" height="315" src="http://www.youtube.com/embed/QUbnMLXSS5U" frameborder="0" allowfullscreen></iframe>

Manasa watched the camera while I waved an IR card around in the BS chamber, and the only way I was able to get all the scatter spots to go away was to either block the beam incident on the BS (duh), or block the beam reflected off the BS, heading to ITMX.  Manasa said that the scatter spots still looked like they were fringing though, so I'm confused.  I may wave a card around in the ITMX chamber when I come back later tonight, to see what I can see.  Also, I just misaligned the SRM, and the scatter spots moved.  Now there's just some scatter off of what looks like the BS OSEM holders, as seen through the BS optic.

  7948   Mon Jan 28 19:15:14 2013 ManasaUpdateScatteringScattering setup

 [Jan, Manasa]

We are trying to get some scattering measurements in the Y-arm cavity. We have removed one of  the viewport windows window covers of ETMY chamber and have installed cameras on a ring that clamps to the window. The window along with the ring attachment is covered with aluminium foil when not in use.

  7962   Wed Jan 30 11:18:31 2013 ManasaUpdateScatteringScattering setup

Quote:

 [Jan, Manasa]

We are trying to get some scattering measurements in the Y-arm cavity. We have removed one of  the viewport windows window covers of ETMY chamber and have installed cameras on a ring that clamps to the window. The window along with the ring attachment is covered with aluminium foil when not in use.

[Jan, Manasa]

To align the camera to see small angle scattering from the ITMY, we tried shooting a green laser pointer at the pickoff mirror that was installed in the ETMY chamber such that we hit the face of ITMY. But we concluded that to be a very bad way to align the camera because we have no means to reconfirm that the camera was exactly looking at the scattering from ITMY.

Since we are in air, we came up with a plan B. The plan is to temporarily install a mirror in the ITMY chamber to steer the beam from the laser pointer (installed on the POY table) through ITMY to the pickoff mirror at the ETMY end. This way, we can install the camera at the ETMY window and be sure we are looking at ITMY scattered light. 

  7971   Thu Jan 31 11:53:31 2013 ManasaUpdateScatteringScattering setup

Since we are in air, we came up with a plan B. The plan is to temporarily install a mirror in the ITMY chamber to steer the beam from the laser pointer (installed on the POY table) through ITMY to the pickoff mirror at the ETMY end. This way, we can install the camera at the ETMY window and be sure we are looking at ITMY scattered light. 

 [Jan,Manasa]

We executed plan B. We installed the green laser pointer on POY table and steered the beam  through ITMY to hit the pick off mirror at the ETM end by installing *temporary mirrors. The pick off mirror was adjusted in pitch and yaw to center the reflected beam on the viewport window. We have installed irides on the ring attached to the viewport window to direct the beam to the camera.

*Temporary mirrors were removed from the ITMY chamber after this alignment.

  8072   Tue Feb 12 23:22:14 2013 ManasaUpdateScatteringScattering setup

 

 [Jan, Manasa]

We installed a camera at the ETMY end to look at the scattering pickoff from the ITMY. We were able to see the whole of the beam tube. We need to meditate on where to assemble the camera and use appropriate lenses to narrow the field of view such that we avoid looking at scattering from other sources inside the chamber.

  5092   Tue Aug 2 11:52:44 2011 kiwamuSummaryGeneralSchedule

I have updated the 40m public calender.

Main change :

  + The vent starts from 3rd of August

  + Keiko and Anamaria (LSU) come from 13th of August

  16648   Mon Feb 7 09:00:26 2022 PacoUpdateGeneralScheduled power outage recovery

[Paco]

Started recovering from scheduled (Feb 05) power outage. Basically, time-reversing through this list.


== Office area ==

  • Power martian network switches, WiFi routers on the north-rack.
  • Power windows (CAD) machine on.

== Main network stations ==

  • Power on nodus, try ping (fail).
  • Power on network switches, try ping (success), try ssh controls@nodus.ligo.caltech.edu (success).
  • Power on chiara to serve names for other stations, try ssh chiara (success).
  • Power on fb1, try ping (success), try ssh fb1 (success).
  • Power on paola (xend laptop), viviana (yend laptop), optimus, megatron.

== Control workstations ==

  • Power on zita (success)
  • Power on giada (success), run system upgrade.
  • Power on donatella (success)
  • Power on allegra (fail)  **
  • Power on pianosa (success)
  • Power on rossa (success)
  • From nodus, started elog (success).

== PSL + Vertex instruments ==

  • Turn on newport PD power supplies on PSL table.
  • Turn on TC200 temp controller on (setpoint --> 36.9 C)
  • Turn on two oscilloscopes in PSL table.
  • Turn on PSL (current setpoint --> 2.1 A, other settings seem nominal)
  • Turn on Thorlabs HV pzt supply.
  • Turn on ITMX OpLev / laser instrument AC strip.

== YEND and XEND instruments ==

  • Turn on XEND AUX pump on (current setpoint -->1.984 A)
  • Turn on XEND AUX SHG oven on (setpoint --> 37.1 C) (see green beam)
  • Turn on XEND AUX shutter controller on.
  • Turn on DCPD supply, and OpLev supply AC strip on.
  • Turn on YEND AUX pump on (fail) *
    • With the controller on STDBY, I tried setting up the current but got HD FAULT (or according to the manual this is what the head reports when the diode temperature is too high...)
    • Upon power cycling the controller, even the controller display stopped working... YAUX controller + head died? maybe just the diode? maybe just the controller?
      • I borrowed a spare LW125 controller from the PSL table (Yehonathan pointed me to it) and swapped it in.
      • Got YEND AUX to lase with this controller, so the old controller is busted but at least the laser head is fine.
      • Even saw SHG light. We switched the laser head off to "STDBY" (so it remains warm) and took the faulty controller out of there.
  • Turn on YEND AUX SHG oven on (setpoint -->35.7 C)
  • Turn on YEND AUX shutter controller on.

== YARM Electronic racks ==

== XARM Electronic racks ==

 


* Top priority, this needs to be fixed.

** Non-priority, but to be debugged

  16651   Mon Feb 7 16:53:02 2022 KojiUpdateGeneralScheduled power outage recovery

I went to the X end and found it was warm. Turned out that not all the A/Cs were on. They were turned on now.

Attachment 1: PXL_20220208_001646282.jpg
PXL_20220208_001646282.jpg
Attachment 2: PXL_20220208_001657871.jpg
PXL_20220208_001657871.jpg
  16665   Fri Feb 11 11:17:00 2022 AnchalUpdateGeneralScheduled power outage recovery

I found that two computers are not powering up in the control room, Ottavia and Allegra. Allegra was important for us as it had the current version of LIGO CDS workstation installed on, providing us with options to use latest packages written by LIGO CDS team. I think the power issue should be resolvable if someone opens it and knows what thye are doing. Do we have any way of getting fuse repairs on such computers? Both these computers are Dell XPS 420.

 

  16671   Mon Feb 14 21:03:25 2022 KojiUpdateGeneralScheduled power outage recovery

I opened the boxes. Allegra has obvious vent of at least 4 caps. And the power supply did not respond even a paper clip test was performed. https://www.silverstonetek.com/downloads/QA/PSU/PSU-Paper%20Clip-EN.pdf (Paper Clip Test)
=> The mother board and the PSU are dead.

Then Ottavia was also checked. The mother board looked OK, but the PSU did not respond. I quickly opened the PSU and it had a bunch of bulged capacitors in it. => PSU dead

Conclusion: Save the cards/memory etc as much as possible. Migrate the allegra HDD to any other healthy PC or obtain a new used PC from Larry. Otherwise, we just want to buy another WS and copy the disk in it.

 

Attachment 1: PXL_20220215_025325118.jpg
PXL_20220215_025325118.jpg
  16669   Mon Feb 14 18:31:50 2022 PacoUpdateGeneralScheduled power outage recovery - IMC recovery progress

[Paco, Anchal, Tega]

We have been realigning the IMC as of last Friday (02/11). Today we made some significant progress (still at high input power), but the IMC autolocker is unable to engage a stable mode lock. We have made some changes to reach this point, including re-centering of the MC1 REFL beam on the ccd, centering of MC2 QPD trans (using flashes), and centering of the MC REFL RFPD beam. The IMC is flashing to peak transmission of > 50% its max (near 14,000 counts average on 2021), and all PDs seem to be working ok... We will keep the PSL shutter closed (especially with high input power) for now.

  16672   Tue Feb 15 19:32:50 2022 KojiUpdateGeneralScheduled power outage recovery - IMC recovery progress

Reduced the IMC power to 100mW

Setup: The power meter was placed right before the final aperture (Attachment 1)

Before the adjustment: Initial position of the HWP was 37.29deg and the input power was 987mW (Attachments 2/3)

After the adjustment: Initial position of the HWP was 74.00deg and the input power was 100mW (Attachments 4/5)

This made the MCREFL reading 0.549.

The MC refl path optics has not been modified.

Attachment 1: PXL_20220216_001731377.jpg
PXL_20220216_001731377.jpg
Attachment 2: Screen_Shot_2022-02-15_at_16.18.16.png
Screen_Shot_2022-02-15_at_16.18.16.png
Attachment 3: PXL_20220216_001727465.jpg
PXL_20220216_001727465.jpg
Attachment 4: Screen_Shot_2022-02-15_at_16.22.16.png
Screen_Shot_2022-02-15_at_16.22.16.png
Attachment 5: PXL_20220216_002229572.jpg
PXL_20220216_002229572.jpg
  16667   Fri Feb 11 16:09:11 2022 AnchalUpdateGeneralScheduled power outage recovery - Input power increased

We increased the input power to IMC by replacing the 98% transmission BS by a 10% transmission BS on the detection table (reverse of what mentioned in 40m/16408 see attachment 8-9laugh). We then realigned the BS so that MC RFPD is centered. Then we realigned two steering mirrors to get the beam centered on the WFS1 and WFS2 QPD. Then we increased the power of the input beam to get 5.307 reading on the C1:IOO-MC_RFPD_DCMON channel. We did this so that we can align the IMC. Once we have it aligned, we'll go back to low poer for doing chamber work.

Beware, there is about 1W beam on the detection table right now.

 

  16655   Wed Feb 9 16:43:35 2022 PacoUpdateGeneralScheduled power outage recovery - Locking mode cleaner(s)

[Paco, Anchal]

  • We went in and measured the power after the power splitting HWP at the PSL table. Almost right before the PSL shutter (which was closed), when the PMC was locked we saw ~ 598 mW (!!)
  • Checking back on ESP300, it seems the channel was not enabled even though the right angle was punched in, so it got enabled.
    • No change.
  • The power adjustment MEDM screen is not really working...
  • Going back to the controller, press HOME on the Axis 1 (our HWP) and see it go to zero...
    • Now the power measured is ~ 78 mW.
  • Not sure why the MEDM screen didn't really work (this needs to be fixed later)

We proceeded to align the MC optics because all offsets in MC_ALIGN screen were zeroed. After opening the PSL shutter, we used values from last year as a reference, and try to steadily recover the alignment. The IMC lock remains at large.

  16657   Thu Feb 10 15:41:00 2022 AnchalUpdateGeneralScheduled power outage recovery - Locking mode cleaner(s)

I found out that the ESP300 service needs to be run in root mode for it to be able to connect to the USB port of HWP motor controller. While doing this change, I noticed that the channels hosted by c1psl might have a duplication conflict with some other channel hosting computer, because a lot of them show the Warning: "Identical process variable names on multiple servers" which is not good. Someone should look into this conflict.

I added instructions on the power control MEDM screen as it was very non-trivial to use. I have set the power such that the C1:IOO-MC_RFPD_DCMON is 5.6 and this happened at C1:IOO-HWP_POS_SET 2.29.

  16658   Thu Feb 10 17:57:48 2022 AnchalUpdateGeneralScheduled power outage recovery - Locking mode cleaner(s)

Something is wrong with the Video MUX. The system did not turn back on with full functionality. Even though we see the screens as they were before the power shutdown, we have lost control on switching any of the videos. I went to check the wiki page about Video MUX which told be we should be able to see the configuration screen on this link, but the page wasn't opening. I went and removed the power cable and put it back in. That brought back the configuration page. Still, I could not change any of the video feeds however this time, I could see the EPICS channel values (like C1:VID-QUAD1_4) change. I tired to go to the configuration page and change the matrix values from the control tab there. I found out that the matrix was mislabeled and while making the changes, I started seeing blue screen on QUAD1_3 (where MC2T was set before). I set the QUAD1_3 (output 23) to MC2T (input 16), but no change. The EPICS values are also set properly, so I don't understand the reason behind blue screen. The same happened when I tried to use:

~>/opt/rtcds/caltech/c1/scripts/general/videoscripts videoswitch3 QUAD1_3 MC2T

Weirdly, this caused the QUAD1_4 screen to go blue. Running following had no effect:

~>/opt/rtcds/caltech/c1/scripts/general/videoscripts videoswitch3 QUAD1_4 MCR

So, I'm not sure what to do. This really needs to be fixed! I wanted to see teh MC2F camera so that I can align IMC, that was the whole reason for this rabit hole. Help needed.

Attachment 1: PXL_20220211_021509819.jpg
PXL_20220211_021509819.jpg
  16659   Thu Feb 10 19:03:23 2022 KojiUpdateGeneralScheduled power outage recovery - Locking mode cleaner(s)

I came back to the 40m and started the investigation.

If I ping 192.168.113.92, it responds. But telnet (port 23) was rejected. I somehow tried ssh and it responds! I even could login to the host using usual password. Here is the prompt.

controls@nodus|~> ssh 192.168.113.92
controls@192.168.113.92's password:

...
controls@c1sus2:~ 0$

Oh no...

Looks like c1sus2 and the videomux have the IP address conflict.

Here are the useful ELOG links:

https://nodus.ligo.caltech.edu:8081/40m/4498

https://nodus.ligo.caltech.edu:8081/40m/4529

  16660   Thu Feb 10 19:46:37 2022 KojiUpdateGeneralScheduled power outage recovery - Locking mode cleaner(s)

== Assign new IP address to c1sus2 ==

cf: [40m ELOG 16398] [40m ELOG 16396]

- Shutdown c1sus2 (Oh, no. This killed c1lsc/c1sus/c1ioo... This should be taken care of later)

- Confirmed 192.168.113.87 is not alive

- Go to chiara
- Modify /diskless/root/etc/hosts

192.168.113.87  c1sus2 c1sus2.martian

- Modify /etc/dhcp/dhcpd.conf

host c1sus2 {
  hardware ethernet 00:25:90:06:69:C2;
  fixed-address 192.168.113.87;
}

- Modify /var/lib/bind/martian.hosts

c1sus2          A    192.168.113.87
videomux        A    192.168.113.92

- Modify /var/lib/bind/martian.hosts/rev.113.168.192.in-addr.arpa

87            PTR    c1sus2.martian
92            PTR    videomux.martian

- Reload/restart bind9 / dhcpd. Run the following command

sudo service bind9 reload
sudo service isc-dhcp-server restart

- Restart c1sus2 and confirm if the IP address was actually changed

controls@c1sus2:~ 0$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:25:90:06:69:c2
          inet addr:192.168.113.87  Bcast:192.168.113.255  Mask:255.255.255.0
...

== Restart c1lsc / c1sus /c1ioo ==

- Reboot c1lsc/c1sus/c1ioo

- Go to scripts/cds

- Run startC1LSC.sh and follow the instruction

 

  15956   Wed Mar 24 00:51:19 2021 gautamUpdateLSCSchnupp asymmetry

I used the Valera technique to measure the Schnupp asymmetry to be \approx 3.5 \, \mathrm{cm}, see Attachment #1. The data points are points, and the zero crossing is estimated using a linear fit. I repeated the measurement 3 times for each arm to see if I get consistent results - seems like I do. Subtle effects like possible differential detuning of each arm cavity (since the measurement is done one arm at a time) are not included in the error analysis, but I think it's not controversial to say that our Schnupp asymmetry has not changed by a huge amount from past measurements. Jamie set a pretty high bar with his plot which I've tried to live up to. 

Attachment 1: Lsch.pdf
Lsch.pdf
  16264   Wed Jul 28 17:10:24 2021 AnchalUpdateLSCSchnupp asymmetry

[Anchal, Paco]

I redid the measurement of Schnupp asymmetry today and found it to be 3.8 cm \pm 0.9 cm.


Method

  • One of the arms is misalgined both at ITM and ETM.
  • The other arm is locked and aligned using ASS.
  • The SRCL oscillator's output is changed to the ETM of the chosen arm.
  • The AS55_Q channel in demodulation of SRCL oscillator is configured (phase corrected) so that all signal comes in C1:CAL-SENSMAT_SRCL_AS55_Q_DEMOD_I_OUT.
  • The rotation angle of AS55 RFPD is scanned and the C1:CAL-SENSMAT_SRCL_AS55_Q_DEMOD_I_OUT is averaged over 10s after waiting for 5s to let the transients pass.
  • This data is used to find the zero crossing of AS55_Q signal when light is coming from one particular arm only.
  • The same is repeated for the other arm.
  • The difference in the zero crossing phase angles is twice the phase accumulated by a 55 MHz signal in travelling the length difference between the arm cavities i.e. the Schnupp Asymmetry.

I measured a phase difference of 5 \pm1 degrees between the two paths.

The uncertainty in this measurement is much more than gautam's 15956 measurement. I'm not sure yet why, but would look into it.

 

Quote:

I used the Valera technique to measure the Schnupp asymmetry to be \approx 3.5 \, \mathrm{cm}, see Attachment #1. The data points are points, and the zero crossing is estimated using a linear fit. I repeated the measurement 3 times for each arm to see if I get consistent results - seems like I do. Subtle effects like possible differential detuning of each arm cavity (since the measurement is done one arm at a time) are not included in the error analysis, but I think it's not controversial to say that our Schnupp asymmetry has not changed by a huge amount from past measurements. Jamie set a pretty high bar with his plot which I've tried to live up to. 

 

Attachment 1: Lsch.pdf
Lsch.pdf
  4821   Wed Jun 15 01:30:38 2011 JamieSummaryLSCSchnupp asymmetry measurement

Measurement of Schnupp asymmetry

This was done by measuring the relative phase between the sidebands reflected from the two arms while the arm cavities are locked.

The Schnupp asymmetry is measured to be:   Lsa = 3.64 ± 0.32 cm

schnupp.png

Description:

As a phase reference we use the zero crossing of the response function for the out-of-phase control signal for the single arm cavity lock [0]. The difference in the RD rotation phase of the response zero crossings indicates the phase difference in the sideband signals reflected from the arms. Assuming the asymmetry is less than half the RF modulation wavelength [1], the asymmetry is given by the following formula:

       \Delta \phi   c   1 
L_sa = ----------- ----- -
           360     f_RSB 2

We use a LSC digital lock-in to measure the response of the arm cavity at a single-frequency drive of it's end mirror.

[0] The locations of the zero crossings in the out-of-phase components of the response can be determined to higher precision than the maxima of the in-phase components.

[1] fRSB = 55 MHz,     c/fRSB/2 = 2.725 m

Procedure:

  1. Lock/tune the Y arm only.
    • We use AS55_I to lock the arms.
  2. Engage the LSC lock-in.
  3. Tune the lock-in parameters:
  4. lock-in freq: 103.1313 Hz
    I/Q filters:  0.1 Hz low-pass
    phase:        0 degrees
    
  5. Set as input to the lock-in the out-of-phase quadrature from the control RFPD.  In this case AS55_Q->LOCKIN.
  6. Drive the arm cavity end mirror by setting the LOCKIN->Y_arm element in the control matrix.
  7. Note the "RD Rotation" phase between the demodulated signals from the control PD (AS55)
  8. For some reasonable distribution of phases around the nominal "RD Rotation" value, measure the amplitude of the lock-in I output.
    • Assuming the Q output is nearly zero, it can be neglected.  In this case the Q amplitude was more than a factor of 10 less than the I amplitude.
    • Here we take 5 measurements, each separated by one over the measurement bandwidth (as determined by the lock-in low pass filter), in this case 10 seconds.  The figure above plots the mean of these measurements, and the error bars indicate the standard deviation.

The data and python data-taking and plotting scripts are attached.

Error Analysis:

To to determine the parameters of the response (which we know to be linear) we use a weighted linear least-squares fit to the data:

y = b X

where:

X0j = 1
X1j = xj              # the measurement points
y = yi                 # the response
b = (b0, b1)     # line parameters

The weighting is given by the inverse of the measurement covariance matrix. Since we assume the measurements are independent, the matrix is diagonal and Wii = 1/\sigmai2 The
estimated parameter values are given by:

\beta  =  ( XT W X )-1 XT W y  =  ( X'T X' )-1 X'T y'

where X' = w X, y' = w y and wii = \sqrt{Wii}.

The X' and y' are calculated from the data and passed into the lstsq routine. The output is \beta.

The error on the parameters is described by the covariance matrix M\beta:

M\beta = ( XT W X)-1 = ( X'T X')-1

with correlation coefficients \rhoij = M\betaij / \sigmai / \sigmaj.

The x-axis crossing is then given by:

X(Y=0) = - \beta1 / \beta0

References:

Valera's LLO measurement
http://en.wikipedia.org/wiki/Weighted_least_squares
http://en.wikipedia.org/wiki/Linear_least_squares_(mathematics)#Weighted_linear_least_squares
http://en.wikipedia.org/wiki/Error_propagation

Attachment 2: arm_phase.py
#!/usr/bin/env python

import sys
import os
import subprocess
import time
import pickle
from numpy import *
import nds
import matplotlib
... 229 more lines ...
Attachment 3: plot.py
#!/usr/bin/env python

import pickle
from numpy import *
import matplotlib
#matplotlib.use('AGG')
from matplotlib.pyplot import *

##################################################

... 137 more lines ...
Attachment 4: schnupp_ETMX.pik
(dp0
S'I'
p1
(dp2
cnumpy.core.multiarray
scalar
p3
(cnumpy
dtype
p4
... 341 more lines ...
Attachment 5: schnupp_ETMY.pik
(dp0
S'I'
p1
(dp2
cnumpy.core.multiarray
scalar
p3
(cnumpy
dtype
p4
... 341 more lines ...
  6151   Tue Dec 27 16:56:15 2011 kiwamuUpdateLSCScmitt trigger installed
The old trigger system has been replaced by Schmitt triggers in the c1lsc realtime model.
They seem working correctly.
  

      An example              

Here below is a picture of time series showing how the Schmitt trigger works as an example.
trigger_time_series.png
 
 In order to check the new trigger, I injected a fake sine signal into the TRY path to simulate lock acquisition of the Y arm with TRY used as a trigger.
Then I monitored the trigger signal, called C1:LSC-YARM_TRIG_MON.
This variable is a boolean, and hence it returns zero when the trigger is off and one when it is on.
I set the upper and lower thresholds to be 0.6 and 0.2 respectively.
As shown in the picture, the trigger became on when the TRY sine curve crossed the upper threshold of 0.6.
After that the TRY signal then crossed the lower threshold of 0.2 and the trigger became off.
 

      How to set the thresholds         

The setting procedure is the same as before.
  1. Open the trigger matrix window, which is accessible from the C1LSC overview screen as usual.
  2. Then type the desired upper and lower thresholds into the column.

The below is a screenshot of the trigger matrix screen. The thresholds column is pointed by a big white arrow.

 trig_mat.png

Of course, DO NOT set the upper threshold value to be smaller than that of the lower threshold. Otherwise it won't correctly work.

Also if you want to have the usual trigger rather than the Schmitt trigger, simply put the upper and lower thresholds at the same values.

 

 

      Details         

 Here I explain how the new trigger exactly work.
The attached screen shot below is the actual c1lsc simulink model, zoomed in the blocks of the MICH trigger.
model_trigger_edit.png
 
    The signal flows from the left hand side to the right hand side and the resultant output is always either zero or one.
There are two variables, which you can control via EPICS: TRIG_THRES_ON and TRIG_THRES_OFF.
Those two variables correspond to the upper and lower thresholds respectively.
   An important thing is that there are two key components: "UnitDelay" and "Choice" blocks.
First of all the code checks whether the trigger used to be ON or OFF at the "Choice" block by looking at the TRIG_MON data which is from the past.
The "Choice" block is configured such that if the TRIG_MON value used to be True, it lets the TRIG_THRES_OFF signal go through.
And if the TRIG_MON used to be False, then it lets the TRIG_ON signal go through.
Therefore this procedure breaks the situation into two cases : trigger used be ON and OFF, and depending on the situation it returns a proper threshold.
     After this check, the code does the usual triggering.
The proper threshold from the "Choice" block will be compared with an LSC signal at ">" block.
If the LSC signal is greater than the threshold value then it gives one and enables the feedback.
 
  3935   Tue Nov 16 21:42:31 2010 ranaUpdateCDSScreen Time Fix
I learned today that the following python code will do a find/replace to fix the TIME string on any MEDM screen which has a whited out time field.
Previously, this field was sourced from the c1dscepics of c1losepics process. Now we have to get it from the IOO or SUS front ends

Here's the python code:

import re
o = open("output.adl","w")
data = open("test.adl").read()
o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
o.close()

Where 'output.adl' could be the same name as 'test.adl' if you want to
replace the existing file. Also FEC-34 just refers to which FE you're running.
It could, in principle, be any one of them.
 

The next step is to figure out how to apply this to all the files in a directory.

  3938   Wed Nov 17 10:39:20 2010 josephbUpdateCDSScreen Time Fix

An improved python code to apply a replacement to all *.adl files in a directory would be:

import re, os
files = os.listdir("./")
  for file in files:
    if ".adl" in str(file):
      data = open(file).read()
      o = open(file,"w")
      o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
      o.close()

Of course, this entire python script can be replaced with a single sed command:

sed -i 's/C0:TIM-PACIFIC_STRING/C1:FEC-34_TIME_STRING/g' *

A more complicated script could be written which looks for key identifiers either in the file header or inside the file to determine which front end is appropriate, using a dictionary like:

dcuid_dict = {"BS":21,"PRM":37,"SRM":37,"ITMX":21,"ITMY":21,"MC1":36,"MC2":36,"MC3":36,"ETMX":24,"ETMY":26}

and then using for loops and if statements.

 

  3652   Tue Oct 5 16:30:00 2010 josephb, yutaHowToCDSScreen settings and medm screens for new system

You can find the sitemap medm screen in

/opt/rtcds/caltech/c1/medm/master

The settings for the screens were last saved by burt in the original system on Sept 29, 2010 at 11:07.  So go to the

/cvs/cds/caltech/burt/autoburt/snapshots/2010/Sep/29/11:07

directory.  You can grep for the channels in the files in this directory.

You can also then use the autoBurt.req file in the /opt/rtcds/caltech/c1/target/sysname/sysnameepics (c1sus/c1susepics) to backup the settings entered.  Save to the /opt/rtcds/caltech/c1/target/snapshots directory for now.

 

 

  5772   Mon Oct 31 19:39:00 2011 JenneUpdateAdaptive FilteringScreens, code, computers

[Mirko, Jenne]

I finished (mostly? maybe?) the OAF screens.  They're pretty awesome. 

While we were playing with the OAF, trying to do some oafing, the output of the code decided to just be zeros.  We did a test, and in the c-code set the output to be a constant value, and that worked.  But when we put it back to normal (being adaptive) and recompiled, it still only outputs zeros.  The code is receiving both witness and error signals, so we don't know what's going on.

In the course of trying to make things work again, we did a complete reboot of c1lsc and c1sus.  Did a burt restore.  Everything (except our weird code problem) should be fine again.  Optics are damping happily.

  1617   Thu May 21 18:07:32 2009 ranaUpdatePSLScrew on Needle valve loosened
Alberto and I went in to loosen up the needle valve yesterday around 4:30 PM. The idea was to cut down on
the flow to the NPRO so that the cooling power of the chiller would be used almost entirely on the
amplifier instead of the NPRO block.

The need valve was basically all the way open. The lock nut was screwed in all the way and stuck. By using
pliers and a wrench for the nut, we freed the lock nut. Even so, the screw for the needle valve seemed to
be bad: I think the thread is stripped; it doesn't go down even after several turns. I even tried to squirt
alchohol on it and really press down in the hopes of catching a thread. It may have closed slightly but its
impossible to be sure.

I also increased the NPRO diode current to the max (+0.1 A). This got us a little bit of NPRO power and
I hope some more AMPMON stability. The attached plot shows 4 days of minute trend. If you squint you
might believe that we got some suppression in the HTEMP fluctuations over the last two days.
Attachment 1: Untitled.png
Untitled.png
  13078   Fri Jun 23 02:55:18 2017 KaustubhUpdateComputer Scripts / ProgramsScript Running

I am leaving a script running on the Pianoso for the night. For this purpose, even the AG4395A is kept on. I'll see the result of the script in the morning (it should be complete by then). Just check so before fiddling with the Analyzer.

Thank you.

  5634   Fri Oct 7 22:41:05 2011 KojiConfigurationGeneralScript backup fixed

Script backup regularly runs on op340m by crontab,
but the true backup were not taken since Oct 16, 2010
as the backup program was looking at the old script directory.
/cvs/cds/script/backupScripts.pl was modified to look at the new script directory.

OLD COMMAND:

$command = "cd /cvs/cds/caltech; /usr/sbin/tar cfX - $EXCLUDE_LIST scripts | bzip2 > $ARCHIVEDIR/scripts_$curdate.tar.bz2";

NEW COMMAND:

$command = "cd /opt/rtcds/caltech/c1; /usr/sbin/tar cfX - $EXCLUDE_LIST scripts | bzip2 > $ARCHIVEDIR/scripts_$curdate.tar.bz2";

  11833   Tue Dec 1 17:16:31 2015 gautamUpdateCDSScript for copying BLRMS filters

We've been talking about putting in BLRMS filters for several channels - it would be a pain to manually copy over the correct bandpass and lowpass filter coefficients into the newly created filter banks, and so I've set up a script (attached) that can do the job. As template filters, I'vm using the filters rana detailed here. Essentially, what the script does is identify the (empty on creation) block of text for a given filter: e.g. RMS_STS1Z_BP_0p01_0p03 for STS1Z), and appends the template filter coefficients. To test my script, I first backed up the original C1PEM.txt file from /opt/rtcds/caltech/c1/chans, removed all the filter coefficients for the STS1Z BLRMS filters, and then replaced it with one generated using my script. I then loaded the coefficients for all the filters in the C1PEM modules, without any obvious error messages being generated. I also checked that foton could read the new file, and checked tmake sure that sensible filter shapes were seen for some channels. Since this seems to be working, I'm going to start putting in BLRMS blocks into the models tomorrow.

Attachment 1: makeFilterFiles.bash.zip
  9242   Wed Oct 16 02:08:05 2013 MasayukiUpdateGreen LockingScript for scan cavity.

I wrote the script to scan the cavity using ALS until it finds IR resonance . This script is  (script)/ALS/ALSfindIRresonance.py I attached the time series of the C1:ALS-OFFSETTER and IR transmission of XARM when the script was working.

When you start this script, it start rough scan. It steps the offset of the C1:ALS-OFFSETER with ramp time, and for each step it checks the value of C1:LSC-TR. At rough scan, one step is 0.1 count. When IR transmission become larger than threshold, this script start fine scan. In fine scan, this script steps the offset by 0.01 for the range of 2. For each step, C1:LSC_TR value is measured, and after fine scan it set the offset to the value which had the maximal C1:LSC-TR.

I put new button 'Scan %ARM'  to the ALS screen. You can run this script by pushing that button.

 

Attachment 1: scan-cavity.png
scan-cavity.png
Attachment 2: Scan_ARMs.png
Scan_ARMs.png
  4136   Tue Jan 11 16:04:17 2011 josephbUpdateCDSScript to update web views of models for all installed front ends

I wrote a new script that is in /opt/rtcds/caltech/c1/scripts/AutoUpdate/ called  webview_simlink_update.m. 

This m-file when run in matlab will go to the /opt/rtcds/caltech/c1/target directory and for each c1 front end, generate the corresponding webview files for that system and place them in the AutoUpdate directory. 

Afterwards the files can be moved on Nodus to the /users/public_html/FE/ directory with:

mv /opt/rtcds/caltech/c1/scripts/AutoUpdate/*slwebview* /users/public_html/FE/

This was run today, and the files can be viewed at:

https://nodus.ligo.caltech.edu:30889/FE/

Long term, I'd like to figure out a way of automating this to produce automatically updated screens without having to run it manually.  However, simulink seems to stubbornly require an X window to work.

  3998   Tue Nov 30 14:21:21 2010 ZachUpdateelogScript unnecessary
I didn't realize that the script in .../elog was configured to start 2.8.0 already. I will revert the instructions on the wiki to point to that 
one.
  14585   Mon Apr 29 19:23:49 2019 JonUpdateComputer Scripts / ProgramsScripted tests of suspension VMons using fast system

I've added a scripted VMon/coil-enable test to PyIFOTest following the suggestion in #15542. Basically, a DC offset is added to one fast coil output at a time, and all the VMon responses are checked.

After resolving the swapped ITMX/ITMY eurocrate slots described in #14584, I ran the new scripted VMon test on all eight optics managed by c1susaux. All of them passed: SRM, BS, MC1, MC2, MC3, PRM, ITMX, ITMY. This is not the final suspension test we plan to do, but it gives me reasonably good confidence that all channels are connected correctly.

  9655   Wed Feb 19 11:45:12 2014 JenneUpdateLSCScripts for ALS being modified

We need to change several scripts for use with the new ALS-in-the-LSC paradigm:

* Watch arms (to turn off ALS if we lose the beatnote, before pushing optics too hard)

* Find IR resonance

* Offset from resonance

None of these should be difficult, just changing the filter bank names to match the new ones (ex. LSC-XARM rather than ALS-XARM, and LSC-ALSX rather than ALS-OFFSETTER1). 

So far, I have changed the "find resonance" script (ALSfindIRresonance.py).  I believe, in principle, to first order, that my modifications should work, however I have not yet tested the script.  So.  If you use it, watch the output of the script and ensure it's doing what it ought.  I'll check it after the lunch meeting and update this log entry.  (I changed the name of the "OFSFILT" variable, line 26, and also modified line 114.  Both of those lines have comments on how to revert the changes).

I have also changed the "offset from resonance" script (ALSchangeOffset.py).  Again, since I'm not locking right now, I have not tested this script either.  So, pay attention if you need to use it, before I check it.  (I changed the name of the OFSFILT variable, and the check which arm logic around line 37.  Again, both of those lines have comments on how to revert the changes.)

  9658   Wed Feb 19 18:21:33 2014 manasaUpdateLSCScripts for ALS modified

Quote:

We need to change several scripts for use with the new ALS-in-the-LSC paradigm:

* Watch arms (to turn off ALS if we lose the beatnote, before pushing optics too hard)

* Find IR resonance

* Offset from resonance

None of these should be difficult, just changing the filter bank names to match the new ones (ex. LSC-XARM rather than ALS-XARM, and LSC-ALSX rather than ALS-OFFSETTER1). 

So far, I have changed the "find resonance" script (ALSfindIRresonance.py).  I believe, in principle, to first order, that my modifications should work, however I have not yet tested the script.  So.  If you use it, watch the output of the script and ensure it's doing what it ought.  I'll check it after the lunch meeting and update this log entry.  (I changed the name of the "OFSFILT" variable, line 26, and also modified line 114.  Both of those lines have comments on how to revert the changes).

I have also changed the "offset from resonance" script (ALSchangeOffset.py).  Again, since I'm not locking right now, I have not tested this script either.  So, pay attention if you need to use it, before I check it.  (I changed the name of the OFSFILT variable, and the check which arm logic around line 37.  Again, both of those lines have comments on how to revert the changes.)

Watch arms script (ALSdown.py) has been modified and now watches the LSC-$ARM filter module instead of the ALS-$ARM filter module. Threshold has been kept the same +/-5000 counts to the ETM suspensions. The script has been tested and works just fine. It exists in the same place scripts/ALS/.

Jenne's modified versions of ALSfindResonance.py and ALSchangeOffset.py were tested and work just fine.

  11861   Tue Dec 8 11:24:45 2015 yutaroSummaryComputer Scripts / ProgramsScripts for loss map measurement

Here I explain usage of my scripts for loss map measurement. There are 7 script files in a same directory /opt/rtcds/caltech/c1/scripts/lossmap_scripts. With these scripts, round trip loss of an arm cavity with the beam spot on one mirror shifted to 5x5 (option: 3x3) points is measured. You can choose on which cavity you measure, the beam spot on which mirror you shift, and maximum shift of the beam spot in vertical and horizontal direction.

 

To start measurement from the beginning

Run the following command in an arbitrary directory and you will get several text files including the result of loss map measurement:

> python /opt/rtcds/caltech/c1/scripts/lossmap_scripts/lossmap.py [maximum shift in mm (PIT)] [maximum shift in mm (YAW)] [arm name (XorY)] [mirror name (E or I)]

Optionally, you can add "AUTO" at the end of the above command. Without "AUTO", you will be asked if the dithering has already settled down or not after each shift of the beam spot and you can let the scripts wait until the dithering settles down sufficiently. If you add "AUTO", it will be judged if the dithering has settled down or not according to some criteria, and the measurement will continue without your response to the terminal.

The files to be created in the current directory by the scripts are:

- lossmapETMX1-1.txt                                # [POX power (locked)] / [POX power (misaligned)]

- lossmapETMX1-2.txt                                # standard deviation of [POX power (locked)] / [POX power (misaligned)]

- lossmapETMX1-3.txt                                # TRX

- lossmapETMX1-1_converted.txt               # round trip loss (ppm) calculated from lossmapETMX1-1.txt

- lossmapETMX1-1_converted_sigma.txt     # standard deviation of round trip loss calculated from 1-1.txt and 1-2.txt

- lossmapETMX_result.txt                           # round trip loss and its error in a clear form.

The name of the files would be "lossmapITMY1-1.txt" etc. depending on which mirror you have chosen.

 

To restart measurement from a certain point

Run the following command in a directory containing "lossmap(mirror name)1-1.txt", "lossmap(mirror name)1-2.txt" and "lossmap(mirrorname)1-3.txt" which are created by previous not-completed measurement:

> python /opt/rtcds/caltech/c1/scripts/lossmap_scripts/lossmap.py [maximum shift in mm (PIT)] [maximum shift in mm (YAW)] [arm name (XorY)] [mirror name (E or I)] [restart point (PIT)] [restart point (YAW)]​ 

You can also add "AUTO".

How to designate the restart point:

Matrix elements of output of this measurement procedure are characterized by a pair of two numbers as the following shows.

   (-1,-1) ->  (-1,-0.5) ->  (-1,0) ->   (-1,0.5)  ->   (-1,1)
                                                                              v
   (-0.5,1) <- (-0.5,0.5) <- (-0.5,0) <- (-0.5,-0.5) <- (0.5,-1)
      v
   (0,-1) ->   (0,-0.5)  ->  (0,0)  ->   (0,0.5)  ->    (0,1)   
                                                                              v
   (0.5,1)  <- (0.5,0.5)  <- (0.5,0)  <- (0.5,-0.5)  <- (0.5,-1)
      v
   (1,-1) ->   (1,-0.5) ->   (1,0)  ->   (1,0.5)   ->   (1,1)

Please write the numbers that correspond to the matrix element you want to restart at. Arrows show the order of sequence of measurement. About the correspondence between the matrix elements and real position on the ETMY and ETMX, see elog 11818 and 11857, respectively. 

This script will overwrite the files (~1-1.txt etc.) so it is safer to make backup of the files before you run this script.

 

Some notes on the scripts and measurement

- Calibration has been done only for ETMs, i.e. for ITMs unit of [maximum shift] is not mm, but the values written in [maximum shift] equal to the maximum offsets added just after demodulation of ASS loop (ex. C1:ASS-YARM_ITM_PIT_L_DEMOD_I_OFFSET).

- It should be checked before doing measurement if the following parameters are correct or not.

POXzero (L47 in lossmapx.py and L52 in lossmapx_resume.py: the value of C1:LSC-POXDC_OUTPUT when no light injects into POXPD.)

POYzero (L45 in lossmapy.py and L50 in lossmapy_resume.py: the value of C1:LSC-POYDC_OUTPUT when no light injects into POYPD.)

mmr (L11 in lossmap_convert.py: (mode matching carrier power)/(total power))

Tf (L12 in lossmap_convert.py; transmittivity of ITM) 

Tetm (L13 in lossmap_convert.py: transmittivity of ETM in ppm)

- Changing n (L50 in lossmap.py) from 5 to 3, the grid points will be 3x3 changed from the default value of 5x5. If 3x3, the matrix elements are characterized by

   (-1,-1) -> (-1,0) -> (-1,1)
                                    v
   (0,1)  <-  (0,0) <-  (0,-1)   
      v
   (1,-1) ->  (1,0) ->  (1,1)  

similarly to the case of 5x5.

- You can copy the directory lossmap_scripts anywhere in controls and use it. These scripts will work as long as all the 7 scripts exist in a same directory. 

  1367   Fri Mar 6 18:22:42 2009 YoichiSummaryComputersScripts to restart the FE computers
While doing locking, the FE computers are overloaded sometimes and I have to reboot them.
Being sick of logging into the FE computers one by one to start front end codes, I wrote scripts to do this automatically.
The scripts are in /cvs/cds/caltech/scripts/FE/.
For example, you can restart c1lsc by typing
restartFE c1lsc
You can give multiple computer names to the restartFE command like,
restartFE c1lsc c1asc c1susvme1

To restart all the FE computers, type
restartFE all

For the scripts to work properly, the computers have to accept login, i.e. you either have to power cycle the computers or push "Reset" buttons on the RFMNETWORK medm screen prior to running the scripts.
  11164   Tue Mar 24 10:53:30 2015 manasaUpdateGeneralScripts updated to the svn

I found that the scripts in FOL and PDFR directories were not in the svn. These were added to the svn.

  9816   Wed Apr 16 01:51:16 2014 JenneUpdateLSCScripts written for ALS acquisition, CARM and DARM transitions

[Jenne, EricQ]

This evening, as part of locking activities, we threw together some handy scripts.


The first one, "Lock_ALS_CARM_and_DARM.py" (no judging of my naming style!!), lives in .../scripts/ALS/ . 

It acquires ALS lock in CARM and DARM mode, so we don't have to do it by hand anymore.

The first thing that it does is ask you to acknowledge that your beatnotes are in place, and they follow our new (newer than the last elog about conventions) beatnote convention.  You are reminded in the terminal window what that convention is:  When the temperature sliders for either arm is INCREASED, the beatnote frequency should INCREASE. 

After you acknowledge that the beatnotes are good, it sets the CARM and DARM servo gains to zero, enables the outputs, sets the input matrix elements, clears the phase tracker histories, and starts ramping up the gains (with +1,+1 for DARM, the darm servo gain is +positive.  with -1*ALSX,+1*ALSY for CARM, the carm servo gain is -negative).  At a gain of 3, it engages the integrators and the resonant gains.  At the final gain of 6, it engages the boosts.

We have used this script ~10 times tonight, and it's been great every time.


The next two scripts are for making the transition from ALS to IR signals.  They both live in ..../scripts/PRFPMI/

"Transition_CARM_ALS_to_TransSqrtInv.py" (again - no judging!) slowly blends the input matrix elements to swap CARM control from the ALS signals to the 1/sqrt(trans) signals.  It takes a few steps, and asks for a keyboard input between steps.  This is because if our 1/sqrt(trans) offsets aren't perfect, we can start to lose transmission power.  To mitigate this, we decrease the offset in the CARM servo filter bank to get more power back.  This script requires an input, which is what you want the final sqrtinv matrix elements to be.  It will fail without this.  For a CARM offset, both of the final sqrtinv matrix elements will have the same sign.

"Transition_DARM_ALS_to_AS55.py" (I can telepathically hear you judging me right now.)  does the same blending, except to swap DARM control from ALS signals to AS55Q.  For the same reason of imperfect offset-setting, it takes several steps, to allow you to adjust the CARM offset if needed. Although, after typing this, I realized that perhaps we should have been tweaking the DARM offset.  Either way, this transition required much less tweaking of offsets than the CARM transition did.  Again, the script requires an input, which is your final desired AS55Q->DARM matrix element value.

Both of these scripts should be run at a digital CARM offset of about 2 counts, although with the offset tweaking during the CARM transition, I usually end at about 1.5 counts. 

*  To determine the final gain value for the CARM sqrtinv matrix elements, we have been using a spare filter bank (ex. XARM), and having the input to that be the sum of the sqrtinv channels.  We then put in a CARM line, and look at the transfer function between the temporary filter bank's input, and the CARM_IN1. 

*  To determine the final gain value for the DARM AS55 matrix element, we have been doing a similar thing, looking at the transfer function between DARM_IN1 and AS55Q with a DARM line on.  We have been putting this DC gain into the static PD normalization (4th block from the left on the big LSC screen), although with the new script, it will be easier to just put that value into the matrix element.

  14600   Thu May 9 22:26:39 2019 JonOmnistructurePSLSecond ADC added to PSL Acromag crate

This evening I added a second ADC module to the prototype Acromag chassis. This chassis can now read out all the PSL diagnostic channels.

I configured the second ADC identically to the first ("ADC0"), and assigned it IP address 192.168.113.122. I confirmed it is visible on the martian network.

There was an existing but unused DB-15 feedthrough which I used for ADC1 channels 1-7. The eighth channel I left unwired, but there are slots available in the neighboring DB-25 feedthough, if that channel is needed in the future. The channel wiring assignments are as follows.

ADC1 Channel DB-15 Feedthrough Pin
0+ 1
0- 9
1+ 2
1- 10
2+ 3
2- 11
3+ 4
3- 12
4+ 5
4- 13
5+ 6
5- 14
6+ 7
6- 15
7+ not connected
7- not connected

I tested all seven of these channels by applying a calibrated voltage source and measuring the response via the Windows Acromag software. All work and are correctly calibrated to better than 0.1%.

Attachment 1: IMG_3291.jpg
IMG_3291.jpg
ELOG V3.1.3-