40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 137 of 344 Not logged in
ID Date Author Type Category Subject
5959   Sat Nov 19 10:41:30 2011 ranaUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

I'm quite sure that this is not good: since MC2 can produce a signal in WFS1 and WFS2, it cannot be removed in this way from the actuation without introducing a significant cross-coupling between the MC_TRANS and WFS loops.

Really need loop TFs measured and compared with the model.

The WFS noise model will also show that we need to have a much lower UGF in the MCT loop since that sensor is just a DC QPD: it can never have as good of a sensing noise as a good WFS. In the current case with no Whitening, this is even more so.

1823   Mon Aug 3 22:54:53 2009 Jenne, Koji, ranaUpdateIOOMC_trans is now better, but not best

Jenne, Koji, Rana

After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.

Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad.  The light travels around the edge of the AP table, then out the corner of the table toward the PSL table.  A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD.

The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner.  Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.

Things done:

1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm.  We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped).

2.  We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.

3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror.

4. We noticed that the bottom periscope mirror was mounted much too low.  It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table.  However, for the MC_trans stuff, all the optics are 4".  We moved the periscope up one hole, which made it the correct height.

5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.

6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path.  2 lenses made the beam too skinny at the QPD.

7.  After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed.  This results in a much brighter beam at the MC_trans QPD, and at the camera.  The QPDs readouts are now a factor of ~3.5 higher than they used to be.  These (especially the camera) could use some ND-filtering action.

8.  The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed).

9.  Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now.  Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.

10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.

11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.

Alberto will elog things about the RFAM mon, including different values of the PD output, etc.

Still on the to-do list:

A.  Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet.  Us a U200A mount if possible, because they are really nice mounts.

B.  Put an ND filter in front of the MC_trans camera, because the image is too bright.

C.  Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization.  They should be divided by the DC value.  This lack of normalization results in higher sensitivity to input pointing.

D.  Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table.  There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.

E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.

Image 1:  The new setup of the AP table, Mc_trans portion.

Image 2:  New setup of the MC_trans part of the PSL table.

1825   Tue Aug 4 11:54:20 2009 JenneUpdateIOOMC_trans readout on LOCK_MC screen now normalized

The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488

/caltech/target/c1iool0/ioo.db now includes:

grecord(calc, "C1:IOO-MC_TRANS_P")
{
field(INPA, "C1:IOO-MC_TRANS_VERT")
field(INPB, "C1:IOO-MC_TRANS_SUM")
field(SCAN, ".1 second")
field(PREC, "3")
field(CALC, "A/B")
}

grecord(calc, "C1:IOO-MC_TRANS_Y")
{
field(INPA, "C1:IOO-MC_TRANS_HOR")
field(INPB, "C1:IOO-MC_TRANS_SUM")
field(SCAN, ".1 second")
field(PREC, "3")
field(CALC, "A/B")
}

The Lock_MC screen was changed to show these new P and Y channels.

12980   Wed May 10 12:37:41 2017 gautamUpdateCDSMCautolocker dead

The MCautolocker had stalled - there were no additional lines to the logfile after 12:17pm (~20mins ago). Normally, it suffices to ssh into megatron and run sudo initctl restart MCautolocker - but it seems that there was no running initctl instance of this, so I had to run sudo initctl start MCautolocker. The FSS Slow control initctl process also seemed to have been terminated, so I ran sudo initctl start FSSslowPy.

### It is not clear to me why the initctl instances got killed in the first place, but MC locks fine now.

12982   Wed May 10 16:57:52 2017 ranaUpdateCDSMCautolocker dead

I rebooted megatron around 12:20 today. It had dozens of stalled medm process (some of them there since February!). I couldn't kill them without them coming back like zombies, so I did sudo reboot.

13533   Thu Jan 11 18:50:31 2018 gautamUpdateIOOMCautolocker getting stuck

I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour.

Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

13547   Mon Jan 15 11:53:57 2018 gautamUpdateIOOMCautolocker getting stuck

Looks like this problem presisted over the weekend - Attachment #1 is the wall StripTool trace for PSL diagnostics, seems like the control signal to the NPRO PZT and FSS EOM were all over the place, and saturated for the most part.

I traced down the problem to an unresponsive c1iool0. So looks like for the IMC autolocker to work properly (on the software end), we need c1psl, c1iool0 and megatron to all be running smoothly. c1psl controls the FSS box gains through EPICS channels, c1iool0 controls the MC servo board gains through EPICS channels, and megatron runs the various scripts to setup the gains for either lock acquisition or in lock states. In this specific case, the autolocker was being foiled because the mcdown script wasn't running properly - it was unable to set the EPICS channel C1:IOO-MC_VCO_GAIN to its lock acquisition value of -15dB, and was stuck at its in-lock value of +7dB. Curiously, the other EPICS channels on c1iool0 seemed readable and were reset by mcdown. Anyways, keying the c1iool0 crate seems to have fixed the probelm.

 Quote: I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour. Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

339   Fri Feb 22 21:19:38 2008 AndreyBureaucracyComputer Scripts / ProgramsMDV library does not work at "LINUX 2"

While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".

Andrey.
343   Thu Feb 28 12:31:33 2008 robBureaucracyComputer Scripts / ProgramsMDV library does not work at "LINUX 2"

 Quote: While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2". Andrey.

This turned out to be due to /frames not being mounted on linux2, as a result of a reboot. The issue is discussed in entry 270. I remounted the /frames, and added a line to mdv_config.m to check whether the frames are mounted.
855   Tue Aug 19 17:15:34 2008 SharonUpdate MEDM
I plugged in the gains I got for the accelerometers in the accelerometers' filters in the PEM screen of the adaptive filter
13879   Tue May 22 17:29:27 2018 keerthanaUpdateelogMEDM Diagram for the auxilary laser system control and display.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

9022   Sun Aug 18 17:56:16 2013 ranaSummaryCDSMEDM Screen CPU Usages

I noticed at LLO (?) that the LSC screen there uses up ~25-30% of the CPU time on a single core for the control room iMac workstations - this seems excessive.

Here is an accounting of CPU usage percentages for some of our screens:

 Screen Name CPU (%) LSC_OVERVIEW 7 ALS_OVERVIEW 0 ALS 1 SUS_SUMMARY 0 IOO_WFS_MASTER 0.3 OPLEV_MASTER 0.5

These were measured using the program 'glances' on rosalba. MEDM running with only the sitemap used up 0.9% of a CPU. With the screens running, the fluctuation from sample to sample could be ~ +/- 0.5%. While the LSC screen seems to be the biggest pig, it is only big in comparison to small pigs. Certainly this pig has gotten bigger after getting sent to Louisiana.

4707   Thu May 12 23:41:47 2011 ranaUpdateCDSMEDM Snapshots not working

Looks like 2 different MEDM Snapshot functiions (at least) are broken.

The regular update of the screens here as well as the usual "Update Snapshot" and view "previous snapshot" button on all of the auto-generated screens.

Also, how do we add the snapshot button to the custom made screens?

12277   Fri Jul 8 19:33:16 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

A new MEDM tab has been added to the summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160708/medm/), although some of the screens are not updated when /cvs/cds/projects/statScreen/cronjob.sh is run. In /cvs/cds/projects/statScreen/log.txt, the following error is given for those files: import: unable to read X window image 0x20011f': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5027. If anyone has seen this error before or knows how to fix it, please let me know.

In the meantime, I'll be working on creating an archive of MEDM screens for every hour to be displayed on the summary pages.

12279   Fri Jul 8 21:02:09 2016 KojiUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

Very nice!

Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?

12280   Fri Jul 8 21:15:03 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

Thanks! Yes, only the screens that are not updated when the script is executed show this error. I'll try to keep debugging over the weekend.

 Quote: Very nice! Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?

723   Wed Jul 23 13:52:26 2008 SharonUpdate MEDM changes
There is a new MEDM screen now when you go from c1ass>top>pem.
Instead of having 12 "mini filters" screens go to 8 outputs (with the wrong correlation impression from the table), we have a 24X8 matrix.
This matrix is there so you could choose which noise signals you want to send to the adaptive code. When you indicate the number of noise channels you are going to use
on the nAUX option on the screen top, you are choosing the channels 1 to nAUX. Channels 15-22 are the seismic and accelerometers we are now using. (you can see the order in Jenne's post 673).
Hope this will make things clearer.
10197   Mon Jul 14 17:51:34 2014 NichinUpdateComputer Scripts / ProgramsMEDM for PDFR system

A

Successfully completed the rudimentary GUI for PDFR system. (users/nichin/PDFR)

Pressing any of the buttons above runs the script that does the following:

1) Change RF mux channel to the required one.

2) Frequency sweep on the network analyzer. The common sweep parameters are in a file named param_NWAG4395A.yml . PD specific parameters are in param_[PD name].yml in their respective folders

3) The transimpedance is calculated and the plot is saved as PDF in the respective folder for the PD. Each set of measurement data and plot is in a timestamped subfolder.

Further work:

To take transimpedance readings for each PD and create a canonical set of data that can be used to compare with data obtained for every measurement run.

1177   Fri Dec 5 01:41:33 2008 YoichiConfigurationComputersMEDM screen snapshot now works on linux machines
As a part of my "make everything work on linux" project, I modified 'updatesnap' script so that linux machines can update MEDM screen snapshots.
This script will take a window snapshot to a PNG file, and move the old snapshot to archive folders with date information added to the filename.
For compatibility, it also saves JPEG snapshot. Right now, most of 'view snapshot' menus in MEDM screens are calling 'sdtimage' command, which cannot display PNG files. I installed Imagemagick to op440m. We should change MEDM files to use 'display' command instead of 'sdtimage' so that it can show PNG files.
I've already changed some MEDM screens, but there are so many remaining to be modified.

PNG is better than JPEG for crisp images like screen shots. JPEG performs a sort of spacial Fourier transformations and low-pass filtering to compress the information. If it is used with sharp edges like boundaries of buttons on an MEDM screen, it naturally produces spacial aliasing (ghost images).

I also created several sym-links on the apps/linux/bin directory to mimic the Solaris-only commands, such as 'sdtimage', 'nedit' and 'dtterm'.
For example, nedit is symbolic linked to gedit. Many MEDM buttons/menus, which used to be incompatible with linux, now work fine on the linux machines.
4543   Tue Apr 19 15:48:43 2011 josephbUpdateCDSMEDM screens and Front Ends updated to new Matrices

## Problem:

The original matrix naming conventions for the front ends was broken.  It used _11, _12,...,_1e, _1f, _110, _111 and so forth.  The code was changes to use _1_1, _1_2,...,_1_16,_1_17, and so on.

In addition the matrix of filter banks was modified to use the same naming convetion (instead of starting at zero, it now start with one).

## Work Done:

I rebuilt all the models, and restarted them all.

I wrote a simple script to modify the burt restore files to have the correct names for all the stored matrix values.

I also modified all the suspension screens, by modifying the default screens in /opt/rtcds/caltech/c1/medm/master/

The C1SUS, C1SCX, C1SPX, C1SCY, C1SPY, and C1MCS models had their foton filter files modified to put filters into the newly changed named filters

4544   Tue Apr 19 17:34:02 2011 KojiUpdateCDSMEDM screens and Front Ends updated to new Matrices

Just a curiosity:

I just wonder how you have distingushed the difference between _111 and _111.

They are equivalent alone themselves. Have you looked at the contexts of the lines?
Or you just did not have the larger matrix than 16x16, did you?

4545   Wed Apr 20 11:02:18 2011 josephbUpdateCDSMEDM screens and Front Ends updated to new Matrices
We simply didn't any matrices larger than 16x16. If we had, than that matrix would not have worked properly since the beginning.

 Quote: Just a curiosity: I just wonder how you have distingushed the difference between _111 and _111. They are equivalent alone themselves. Have you looked at the contexts of the lines? Or you just did not have the larger matrix than 16x16, did you?

13740   Mon Apr 9 16:30:21 2018 KiraUpdatePEMMEDM setup

I created an MEDM screen for the PID control. In addition, I added a new EPICS channel for the setpoint so that it could be adjusted using the MEDM screen.

Edit: forgot to mention the channel name is C1:PEM-SEIS_EX_TEMP_SETPOINT

Edit #2: the path for the MEDM is /opt/rtcds/caltech/c1/medm/c1pem/C1PEM_SEIS_EX_TCTRL.adl

13745   Tue Apr 10 15:42:08 2018 KiraUpdatePEMMEDM setup

An update to the screen. I changed the min/max values for some of the parameters, as well as changing the script so that I could specify the integral gain in terms of 1e-5. I've also added this screen to the PEM tab in the sitemap.

13748   Thu Apr 12 10:15:33 2018 KiraUpdatePEMMEDM setup

Another update. I've changed the on/off button so that it's visible which state it's in. I did that by changing the type of C1:PEM-SEIS-EX_TEMP_SLOWLOOP from ai to bi (I checked the FSS script and copied the entry for the slowloop). Previously, MEDM was giving me an error that it wasn't an ENUM value when I wanted to use a choice button to indicate the value of slowloop, and this solved the issue. I've also added a StripTool button.

13750   Fri Apr 13 00:20:46 2018 ranaUpdatePEMMEDM setup

changed the setpoint of the EX Seismomter T ctrl servo from 35 to 39 C to see if this helps the stability by decreasing the cooldown time constant.

3914   Sun Nov 14 02:59:31 2010 ranaConfigurationGeneralMEDM snapshots web page

Since Nodus is a Solaris machine it can barely handle doing the ImageMagick commands (such as convert and import). I removed the auto MEDM snapshot routine from it

awhile ago and I think the rate of ELOGD crashes has decreased, although its not definitive.

The snapshots have now been re-actived to run on MAFALDA, after I fixed the absolute pathnames in the scripts and installed (via yum) the packages that mafalda

needed to run this (Xvfb, openmotif, compat, etc.). The snapshots web page is now refreshing by itself and the statScreen/cronjob.sh is running on mafalda 5x per hour.

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

6654   Mon May 21 21:27:39 2012 yutaUpdateCDSMEDM suspension screens using macro

Background:
We need more organized MEDM screens. Let's use macro.

What I did:
1. Edited /opt/rtcds/userapps/trunk/sus/c1/medm/templates/SUS_SINGLE.adl using replacements below;

sed -i s/#IFO#SUS_#PART_NAME#/'$(IFO)$(SYS)_$(OPTIC)'/g SUS_SINGLE.adl sed -i s/#IFO#SUS#_#PART_NAME#/'$(IFO)$(SYS)_$(OPTIC)'/g SUS_SINGLE.adl
sed -i s/#IFO#:FEC-#DCU_ID#/'$(IFO):FEC-$(DCU_ID)'/g SUS_SINGLE.adl
sed -i s/#CHANNEL#/'$(IFO):$(SYS)-$(OPTIC)'/g SUS_SINGLE.adl sed -i s/#PART_NAME#/'$(OPTIC)'/g SUS_SINGLE.adl

IFO=C1,SYS=SUS,OPTIC=MC1,DCU_ID=36

3. I also fixed white blocks in the LOCKIN part.

Result:
Now you don't have to generate every suspension screens. Just edit SUS_SIGNLE.adl.

Things to do:
- fix every other MEDM screens which open suspension screens, so that they open SUS_SINGLE.adl

6657   Tue May 22 11:32:02 2012 JamieUpdateCDSMEDM suspension screens using macro

Very nice, Yuta!  Don't forget to commit your changes to the SVN.  I took the liberty of doing that for you.  I also tweaked the file a bit, so we don't have to specify IFO and SYS, since those aren't going to ever change.  So the arguments are now only: OPTIC=MC1,DCU_ID=36.  I updated the sitemap accordingly.

Yuta, if you could go ahead and modify the calls to these screens in other places that would be great.  The WATCHDOG, LSC_OVERVIEW, MC_ALIGN screens are ones that immediately come to mind.

And also feel free to make cool new ones.  We could try to make simplified version of the suspension screens now being used at the sites, which are quite nice.

6659   Tue May 22 11:47:43 2012 JamieUpdateCDSMEDM suspension screens using macro

Actually, it looks like we're not quite done here.  All the paths in the SUS_SINGLE screen need to be updated to reflect the move.  We should probably make a macro that points to /opt/rtcds/caltech/c1/screens, and update all the paths accordingly.

6663   Tue May 22 20:46:38 2012 yutaUpdateCDSMEDM suspension screens using macro

I fixed the problem Jamie pointed out in elog #6657 and #6659.

What I did:
1. Created the following template files in /opt/rtcds/userapps/trunk/sus/c1/medm/templates/ directry.

To open these files, you have to define $(OPTIC) and$(DCU_ID).

2. Fixed the following screens so that they open SUS_SINGLE.adl.

6621   Tue May 8 03:38:28 2012 JenneUpdateGeneralMEDM svn emergency!!!

We officially are *failures* at svn-ing our scripts and screens.  This is NOT OKAY.  I checked in a few things, since there were already folders on the svn, but many things don't have folders created.  It's a hot mess.  We need to get our shit together, and become as disciplined about MEDM and scripts as we have been (under Jamie's watchful eye) of the simulink models.

I'm not going to start fixing it all right now.  It might not even happen at this point until after GWADW, but it needs to happen.

9450   Sat Dec 7 19:29:14 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box         place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button         place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box         place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim         place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim         place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim         place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim         place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle         place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle 

9466   Fri Dec 13 13:45:50 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl`

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

6925   Fri Jul 6 01:39:56 2012 yutaUpdateLockingMI + Y arm ALS succeed, but not both

MI with X arm length stabilized off resonance and Y arm length stabilized at resonance using ALS succeed, but I couldn't bring X arm to IR resonance. This maybe because of too much phase fluctuation. I will calculate it later.

What I did:
1. Brought X arm to IR resonance.
2. Brought Y arm to IR resonance.
3. Brought X arm to off-resonance.
4. Brought Y arm to off-resonance. (1-4 are to play with arms)
5. Locked MI in dark fringe using AS55_Q as error signal and BS as actuator.
6. Brought Y arm to IR resonance. This flips sign, so MI lock will be bright fringe.
7. Brought X arm to IR resonance. This destroys MI lock.

Below is the plot showing what I did

I also tried to lock MI after both arms are stabilized at resonance, but it failed, too.
MI + X arm ALS fails. I think this is from too much BS motion to compensate phase fluctuation of arm reflected beam.
MI + Y arm ALS fails when I want to lock in dark fringe. Only bright fringe works.

New compact MEDM screen for ALS:

It has (almost) everything you need for ALS. It lives in /opt/rtcds/caltech/c1/medm/c1gcv/master/C1ALS_COMPACT.adl.
Features;

- Button for turning on/off ALS. It even does "clear history"!
(light brown button "ON plus", "ON minus", "OFF"; runs /opt/rtcds/caltech/c1/scripts/ALS/easyALS.py; Currently, you have to guess the sign of gain. Ctrl-C if the sign was wrong. It will be nice if script can handle this. Use lockin to detemrine the sign?)

- Button for finding IR resonance.
(pink button "IRres"; runs /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py)

- Button for bringing arm length to off-resonance.
(pink button "-10", "+10"; steps +/- 10 deg offset)

- Button for toggling green shutters.
(green button "shutter"; runs /opt/rtcds/caltech/c1/medm/c1gcv/cmd/toggle(X|Y)Shutter.py)

- Button for switching monitors.
(grey button "Video (X|Y)arm"; runs /opt/rtcds/caltech/c1/scripts/general/Video_(X|Y)arm.csh)

- Slider for changing temperature of end lasers. You can also open temperature servo screens from orange "(X|Y)SLOW" button.

4638   Thu May 5 13:55:08 2011 kiwamuUpdateLSCMI locking : calibration of BS and ITMs actuators

EDIT by KI on 15/5/2011:

The calibration of MICH error signal was wrong by a factor of 2.

The open loop transfer functions of the Michelson locking have been measured.

The purpose of this excise is to calibrate the coil-magnet actuators on BS and ITMs.

The estimated actuation coefficients are :

BS = 3.69e-08 [m/counts]
ITMX = 8.89e-09 [m/counts]
ITMY = 9.22e-09 [m/counts]

I guess the accuracy is something like 5 % because the calibration of the MI optical gain relies on a peak-to-peak measurement.

A next step is to calibrate the PRM actuator and the PRC optical gain.

(measurement)

The Michelson was locked with different actuators in every measurement. I locked the Michelson to the dark fringe with BS, ITMX and ITMY in each time.

The measured peak-to-peak value in the error signal was 20.2 counts, corresponding to a sensor gain of 5.96e+07 [counts/m]. Note that I used AS55_Q for the locking.

After locking the MI I took the open loop transfer function by injecting broadband noise from DTT.

Then the data were fitted coarsely.  In the fitting I used the resonant frequencies that Leo reported recently (http://blue.ligo-wa.caltech.edu:8000/40m/Mechanical_Resonances).

The Q-values are assumed to be 5 because of the local dampings. As a result the fitting gives us the actuator coefficients.

Here is a plot showing the measured open loop transfer functions. The solid lines represent the fittings.

(by the way)

- The delay time including ADC/DAC and RFM looks quite big. According to the fitting the delay is something like 600 usec.

This is about two times larger than the one reported before (see this entry). I will re-measure it with empty filters.

4639   Thu May 5 14:40:14 2011 KojiUpdateLSCMI locking : calibration of BS and ITMs actuators

I've got confused

1) Are these the DC responses of the coils? If that is true, we need to specify the resonant frequency of each suspension to get the AC response.

2) Are these the AC responses well above the resonant freqs? In that case, The responses should be x.xxx / f^2 [m/counts]

 Quote: The open loop transfer functions of the Michelson locking have been measured. The purpose of this excise is to calibrate the coil-magnet actuators on BS and ITMs. The estimated actuation coefficients are :  BS = 3.69e-08 [m/counts]  ITMX = 8.89e-09 [m/counts]  ITMY = 9.22e-09 [m/counts]

6916   Thu Jul 5 01:34:11 2012 yutaUpdateLockingMI with X arm ALS

I tried to lock FPMI using ALS, but I could not take care of ALS for both arms + MI. So, I decided to try one arm + MI.
I don't know why, but I couldn't make it. We need investigation.

Procedure I took:

1. Align FPMI.

2. Misalign ETMY.

3. Press CLEAR HISTORY for C1:ALS-BEATY_FINE_PHASE filter module.
Are there any command to do this?

4. Stabilize X arm length.
I made a script for turning on ALS servo nicely. It currently lives in /users/yuta/scripts/easyALS.py. You have to specify the arm(X or Y) and sign of the gain. It needs to be refined.

5. Sweep the offset and stabilize X arm lenth to IR resonance.
(Ran /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py Xarm)

6. Tried to lock MI. I tried to do this by feeding back the signal to BS or ITMs. Both worked fine when ALS holds X arm to IR off-resonance, but I couldn't lock MI when ALS holds X arm to IR resonance. This may come from too much phase fluctuation from X arm reflection. We should investigate this.

Handing off the servo from ALS to LSC:

I made a script to do this. It just decreases ALS gain and increases LSC gain with 30 sec ramp time. It needs to be refined, so it currently lives in /users/yuta/scripts/handofftoLSC.py. It worked fine without loosing IR transmission.

ALS stability:
Current stabiliy of the ALS servo is not enough. It doesn't stay for more than ~ 10min. I suspect this is from frequency servo of end lasers losing lock, or beat signals being too small for the beat box because of intensity fluctuation of green transmission. We definitely need to align end greens, but it is painful.

16984   Mon Jul 11 11:56:40 2022 he YehonathanUpdateBHDMICH AS55 noise budget

I calculated a noise budget for the MICH using AS55 as a sensor. The calculation includes closed-loop TF calculations.

The notebook and associated files can be found on https://git.ligo.org/40m/bhd/-/blob/master/controls/compute_MICH_noisebudget.ipynb.

Attachment 1 shows the loop diagram I was using. The equation describing the steady-state of the loop is

$\left[\mathbb{I}-G \right]\begin{pmatrix} \gamma \\ \delta \\ \Delta\end{pmatrix} = \begin{pmatrix} \alpha \\ \beta \\ \epsilon\end{pmatrix}$

, where G is the adjacency matrix given by

$G=\begin{pmatrix} 0 & 0 & AE_2\\ 0 & 0 & BE_2 \\ E_1C & E_1D & 0 \end{pmatrix}$

First, the adjacency matrix G is constructed by stitching the small ABCDE matrices together. Once the inverse of (I-G) is calculated we can simply propagate any noise source to $\delta$ and then calculate $\left[\mathbb{I}-E(CA+DB)\right]B^{-1}\delta$ to estimate the displacement of the optics.

Attachment 2 shows the calculated noise budget together with Yuta's measurement.

All the input and output electronics are clumped together for now. Laser noise is irrelevant as this is a heterodyne measurement at 55MHz.

It seems like there is some mismatch in the calibration of the optical gain between the measurement and model. The missing noise at 3-30Hz could be due to angle-to-length coupling which I haven't included in the model.

16989   Tue Jul 12 09:14:50 2022 ranaUpdateBHDMICH AS55 noise budget

Looking good:

• I think the notches you see in he measured noise are a clue as to the excess noise source. You can try turning some notches on/off.
• Laser noise does matter a bit more subtley: the low freq noise couples to AS55 through the RMS deviation of the MICH loop from the zero crossing, and the noise of the 55 MHz modulation.
• Jitter in the IMC couples to MICH through the misalignment of the Michelson.
• As you rightly note, the optical lever feedback on the ITMs and BS also make length noise through the suspension actuator imbalance and the spot mis-centering.
16996   Wed Jul 13 10:54:39 2022 YehonathanUpdateBHDMICH AS55 noise budget

I fixed some mistakes in the budget:

1. The BS pendulum resonance was corrected from 0.8Hz to 1Hz

2. Added missing X3 filter in the coil filters

3. Optical gain is now computed from MICH to AS55 instead of BS to AS55 and is calculated to be: 9.95e8 cts/m.

4. Coil driver gain is still unmeasured but it is found to be 1.333 to make the actuation calibration from BS to MICH match the measurement (see attachment 1).

Attachment 2 shows the resulting MICH OLTF.

Laser noise was added to the budget in a slightly ad-hoc fashion (will fix later): Yuta and I measured MC_F and computed MC_F*(Schnupp asymmetry)/(Laser frequency). Attachment 3 shows the updated noise budget.

10503   Fri Sep 12 15:10:09 2014 JenneUpdateASCMICH ASS

During the Sim meeting today, I added parts to the ASS model so that we can also dither the BS and minimize the power at AS.

ASS screen has been updated.

Model changes required a new sender from LSC for ASDC, so both LSC and ASS were compiled, installed and restarted.  Also on LSC, I added AS110 I&Q to DQ channels, since we haven't been recording them in the past.

I have done a quick trial in MICH-only lock, and it seems to work.  Gain of 10 for both Pit and Yaw servos.

17294   Mon Nov 21 17:44:00 2022 yutaSummaryBHDMICH BHD displacement sensitivity with AS55_Q and BHD_DIFF

[Paco, Yuta]

MICH displacement sensitivity was compared under AS55_Q locking and BHD_DIFF locking.
Sensitivity with BHD was better by more than an order of magnitude due to smaller sensing noise.
During the measurement, LO phase fluctuation was ~13 deg RMS.

Locking configurations:
- MICH was first locked with AS55_Q, no offset, and then handed over to BHD_DIFF after LO phase locked. FM2, FM3, FM4, FM5, FM6, FM8, FM10 on, C1:LSC-MICH_GAIN=-3 gave UGF of around 80 Hz.
- LO PHASE was locked with BH55_Q, no offset. FM5, FM8 on, C1:HPC-LO_PHASE_GAIN=-2 feeding back to LO1 gave UGF of around 40 Hz.
- Attachment #1 shows the OLTFs.

Sensitivity estimate:
- Sensitivity was estimated using measured actuator gains and optical gains. Following numbers are used.

C1:LSC-AS55_Q_ERR to MICH 1.08e-9 counts/m (measured at 311.1 Hz today)
C1:HPC-BHDC_DIFF to MICH 1.91e-9 counts/m (measured at 311.1 Hz today)
BS   : 26.54e-9 /f^2 m/counts (40m/17285)
LO1  : 26.34e-9 /f^2 m/counts (40m/17285)

These numbers were also reflected to C1:CAL-MICH_CINV and C1:CAL-MICH_A.
C1:CAL-MICH_A_GAIN = 0.5 was used to take into account of LSC output matrix of MICH to BS being C1:LSC-OUTPUT_MTRX_8_2=0.5.

- Attachment #2 shows the displacement spectrum of MICH (top) and LO PHASE (bottom). Brown MICH curve is when locked with AS55_Q and black MICH curve is when locked with BHD_DIFF. RMS of original and in-loop LO PHASE was estimated to be

Original LO phase noise: 393 nm RMS (266 deg RMS)
In-loop LO phase noise: 19.4 nm RMS (13 deg RMS)

Next:
- Improve LO phase loops to reduce LO phase noise
- Estimate LO phase noise contribution to MICH sensitivity

12979   Wed May 10 01:56:06 2017 gautamUpdateGeneralMICH NB - OL coupling

### Last night, I tried to estimate the contribution of OL feedback signal to the MICH length error signal.

In order to do so, I took a swept sine measurement with a few points between 50 Hz and 500 Hz. The transfer function between C1:LSC-MICH_OUT_DQ and the Oplev Servo Output point (e.g. C1:SUS-BS_OL_PIT_OUT etc) was measured. I played around with the excitation amplitude till I got coherence > 0.9 for the TF measurement, while making sure I wasn't driving the Oplev error point too hard that side-lobes began to show up in the MICH control signal spectrum.

#### The Oplev control signal is not DQ-ed. So I locked the DRMI again and downloaded the 16k data "live" for ~5min stretch using cdsutils.getdata on the workstation. The Oplev error point is DQ-ed at 2k, but I found that the excitation amplitude needed for good SNR at the error point drove the servo to the limiter value of 2000cts - so I decided to use the control signal instead. Knowing the transfer function from the Oplev *_OUT* channel to C1:LSC-MICH_IN1_DQ, I backed out the coupling - the transfer function was only measured between 50 Hz and 500 Hz, and no extrapolation is done, so the estimation is only really valid in this range, which looks like where it is important anyways (see Attachment #2, contributions from ITMX, ITMY and BS PIT and YAW servos added in quadrature).

I was also looking at the Oplev servo shapes and noticed that they are different for the ITMs and the BS (Attachment #1). Specifically, for the ITM Oplevs, an "ELP15" is used to do the roll-off while an "ELP35" is employed in the BS servo (though an ELP35 also exists in the ITM Oplev filter banks). I got lost in an elog search for when these were tuned, but I guess the principles outlined in this elog still hold and can serve as a guideline for Oplev loop tweaking.

Coil driver noise estimation to follow

 Quote: I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.

GV 10 May 12:30pm: I've uploaded another copy of the NB (Attachment #3) with the contributions from the ITMs and BS separated. Looks like below 100Hz, the BS coupling dominates, while the hump/plateau around 350Hz is coming from ITMX.

12981   Wed May 10 16:53:38 2017 ranaUpdateGeneralMICH NB - OL coupling

That's a good find.

1. The OL control signal can be gotten from the DQ error signal. You just need to multiply it by the digital filters and the gain. The state of the filters and the gain can be gotten using matlab tools like getFotonFilt.m. For python ChrisW wrote a tool called foton.py which is in the GDS SVN. You should ask him for it. It requires access to some ROOT libraries to run.
2. We should have sub budgets for everything like OL and thermal, etc. They should be automatically produced each time you run the main budget and should be separate pages in the same PDF file. Jamie / Chris may have something going along these lines so check to see if they are already on it.
12974   Fri May 5 10:13:02 2017 ericqUpdateGeneralMICH NB questions
Is suspension thermal noise missing? I take it "Thermal" refers just to thermal things going on in the optic, since I don't see any peaks at the bounce/roll modes as I would expect from suspension thermal noise.

What goes into the GWINC calculation of seismic noise? Does it include real 40m ground motion data and our seismic stacks?

I'm surprised to see such a sharp corner in the "Dark Noise" trace, did you apply the OLG correction to a measured dark noise ASD? (The OLG correction only needs to be applied to the in-lock error signals to recover open loop behavior, there is no closed loop when you're measuring the dark noise so nothing to correct for.)
12975   Fri May 5 12:10:53 2017 gautamUpdateGeneralMICH NB questions

 Quote: Is suspension thermal noise missing? I take it "Thermal" refers just to thermal things going on in the optic, since I don't see any peaks at the bounce/roll modes as I would expect from suspension thermal noise. What goes into the GWINC calculation of seismic noise? Does it include real 40m ground motion data and our seismic stacks? I'm surprised to see such a sharp corner in the "Dark Noise" trace, did you apply the OLG correction to a measured dark noise ASD? (The OLG correction only needs to be applied to the in-lock error signals to recover open loop behavior, there is no closed loop when you're measuring the dark noise so nothing to correct for.)

I've included the suspension thermal noise in the "Thermal" trace, but I guess the GWINC file I've been using to generate this trace only computes the thermal noise for the displacement DoF. I think this paper has the formulas to account for them, I will look into including these.

For the seismic noise, I've just been using the seis40.mat file from the 40m SVN. I think it includes a model of our stacks, but I did not re-calculate anything with current seismometer spectra. In the NB I updated yesterday, however, I think I was off by a factor of sqrt(3) as I had only included the seismic noise from 1 suspended optic. I've corrected this in the attached plot.

For the dark noise, you are right, I had it grouped in the wrong dictionary in the code so it was applying the OLG inversion. I've fixed this in the attached plot.
12976   Sat May 6 21:52:11 2017 ranaUpdateGeneralMICH NB questions

I think the most important next two items to budget are the optical lever noise, and the coil driver noise. The coil driver noise is dominated at the moment by the DAC noise since we're operating with the dewhitening filters turned off.

13984   Mon Jun 18 19:47:02 2018 gautamUpdateGeneralMICH actuator calibration

Summary:

The actuator (pendulum) gains for the Beam Splitter and the two ITMs were measured to be:

BS: 9.54 +/- 0.05 nm/ct [100 ohm series resistor in coil driver board]

ITMX: 2.44 +/- 0.01 nm/ct [400 ohm series resistor in coil driver board]

ITMY: 2.44 +/- 0.02 nm/ct [400 ohm series resistor in coil driver board]

Counts here refers to DAC counts at the output of the coil filter banks (as opposed to counts at the LSC servo output). The dominant (systematic) uncertainty (which isn't quoted here) in this measurement is the determination of the peak-to-peak swing of the dark port sensor, AS55_Q. I estimate this error to be ~1ct/33cts = 3%. These values are surprisingly consistent with one another once we take into account the series resistance.

Details:

The last time this was done, we used ASDC to do the measurement. But I don't know what signal conditioning ASDC undergoes (in PD or in readout electronics). In any case, in my early trials yesterday, ASDC was behaving unpredictably. So I decided to do redo the measurement.

[Attachment #1]- Flowchart describing the calibration procedure.

[Attachment #2] - AS55_Q output while the Michelson was freeswinging. I had first aligned the ITMs using ASS. The peak-to-peak value of this corresponds to $\lambda/4$. So we know AS55_Q in terms of cts/m of MICH displacement.

[Attachment #3] - Magnitudes of transfer function from moving one of the MICH optics, to the now calibrated AS55_Q. Fits are to a shape $a/f^2$, with $a$ being the fitted parameter. Coherence during the measurement is also plotted.

• Note that the excitation is applied to the channels C1:SUS-<optic>_LSC_EXC, for <optic> in [BS, ITMX, ITMY]. But since my de-whitening board re-work to remove the analog x3 gain, there is a digital x3 gain in the coil driver filter banks. So while the calibration numbers given above are accurate, be aware that when using them for sensing matrix measurements etc, you have to multiply these by x3.
• Furthermore, moving the BS by $x$ results in a Michelson length change of $\sqrt{2}x$, and this has been factored into the above number.

Next Steps:

1. Now that I have a calibration I trust more, re-analyze my DRMI sensing matrix data. Actually the sensing response numbers aren't significantly different from what I have been assuming. It's just that in terms of counts applied at the LSC input of a suspension, there is a digital x3 gain that has to be explicitly factored in.
2. Calibrate POX and POY by locking the arms and driving the now calibrated ITMs by a known number of counts.
3. Calibrate the ETMs, and MC1/MC2/MC3 by looking at calibrated POX/POY.
4. Lock DRMI, and calibrate SRM and PRM.

Reference:

9317   Wed Oct 30 03:36:51 2013 JenneUpdateLSCMICH and PRCL UGFs change with ALS enabled

Masayuki was able to hold both arms off-resonance with ALS long enough for me to lock the PRMI (arms still held off resonance), and take a set of transfer functions.

MICH gain is still -2.0, PRCL gain is still 0.070, which, with the ETMs misaligned, gave me UGFs of 70 for MICH and 180 for PRCL.

Now, however, with the ETMs aligned, but arms held off resonance with ALS, the UGFs have been lowered by a factor of 2 in frequency!  What is doing this??  MICH is now 40 Hz, and PRCL is now 80 Hz.

We measured the MICH and PRCL loops for several arm powers, and there was no change, at least until the arms were both resonating with powers of ~4 .

After misaligning the ETMs, I remeasured the loops, and the UGFs went back up to where they started.

ELOG V3.1.3-