40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 317 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9100   Tue Sep 3 21:10:36 2013 JenneConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

Quote:

 

 I should actually stick in the SXBP-100's, which will band pass from 87-117 MHz.

 I have removed the 135 MHz low pass from my new AS110 demod board, but these SXBPs have different feet than the SCLFs, so I want to confirm with Koji or someone that I can solder them in the same way, before I get carried away and destroy anything.  I should be able to finish this up tomorrow, plug in the demod board and the distribution box, and try out AS110 triggering, etc, tomorrow night.

  4021   Tue Dec 7 17:19:33 2010 kiwamuUpdateComputerspyNDS available

I moved the Pynds package from Yuta's local directory to the public place.

Now the package is living under :

       /cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages

Also I added the PATH on cshrc.40m, so you don't have to setenv every time.

       (This package can not run on non-64bit linux)

Typing "import nds" on python allows you to use the nds functions.

 


 

 Quote from Yuta's  past entry

Quote: #3722 

3. I installed pyNDS to /cvs/cds/caltech/users/yuta/pynds

  3722   Thu Oct 14 20:31:15 2010 yutaUpdateComputerspyNDS installation

EDIT by kiwamu Dec.7th ;

The Pynds package has been moved to the appropriate place:

/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages

Background:
 We need the python module pyNDS to get the data directly from the server using python.
 Leo helped us install pyNDS today.

Installation:
1. Get pyNDS source tarball from here.
  https://www.lsc-group.phys.uwm.edu/daswg/download/software/source/pynds-0.3.tar.gz

2. All you need is Boost.Python and nds2-client. See README in the pynds-0.3 directory.

3. I installed pyNDS to /cvs/cds/caltech/users/yuta/pynds

4. You have to set environment variable to import the module. For example, run;
  setenv PYTHONPATH /users/yuta/pynds/lib64/python2.4/site-packages:${PYTHONPATH}

Notes:
 RPM will be available soon from Leo.

  13341   Thu Sep 28 23:32:38 2017 gautamHowToCDSpyawg

I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example):

exc=cds.awg.ArbitraryLoop(excChan,excit,rate=fs)

One could also explicitly do the import if cdsutils isn't automatically imported:

from cdsutils import awg

pyawg-away!


Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748

  13344   Fri Sep 29 09:43:52 2017 jamieHowToCDSpyawg

 

Quote:

I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example):

exc=cds.awg.ArbitraryLoop(excChan,excit,rate=fs)

One could also explicitly do the import if cdsutils isn't automatically imported:

from cdsutils import awg

pyawg-away!


Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748

?  Why aren't you able to just import 'awg' directly?  You shouldn't have to import it through cdsutils.  Something must be funny with the config.

  9135   Tue Sep 17 17:55:42 2013 Jamie.ConfigurationComputer Scripts / Programspyepics configured

Quote:
 controls@rosalba:~ 0$ cdsutils
Traceback (most recent call last):
  File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module>
    from cdsutils import CMDS
  File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module>
    from servo import servo
  File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module>
    from epics import PV
ImportError: No module named epics
controls@rosalba:~ 1$
Mon Sep 16 19:40:32 2013 

 I properly installed the python-pyepics package on all the workstations, so this should be working now.

And for posterity, the pyepics source is at:

  pianos:/home/controls/src/pyepics

From this debian packages were built:

  controls@pianosa:~/src/pyepics 0$ debuild -uc -us

The .deb was then moved into the /ligo/apps/deb nfs:

  controls@pianosa:~/src 0$ cp python-pyepics_*_all.deb /ligo/apps/debs/pyepics/

It was then installed on the various workstations:

  controls@rosalba:~ 0$ sudo dpkg -i /ligo/apps/debs/pyepics/python-pyepics*.deb

This will probably need to be repeated any time we upgrade the EPICS install.

  7243   Tue Aug 21 15:25:41 2012 JenneUpdateComputerspyepics installed

I installed pyepics version 3 (http://cars9.uchicago.edu/software/python/pyepics3/overview.html) in ..../scripts/pylibs    .   I also added an "epics.conf" file to /etc/ld.so.conf.d/ , which points to the place in /ligo/apps/epics/base/lib/linux-x86_64/ where the DLLs live.  All .conf files in /etc/ld.so.conf.d/   get included in the path, so python should always automatically be able to use epics now, after you "import epics" in a script.

This is supposed to give us direct channel access to all epics channels, rather than using Yuta's wrapper scripts for ezca stuff.  I was going to write a tdsavg equivalent using camonitor, since it's unclear whether tds tools are being supported anymore.

However, I'm not getting it to connect to the server that serves epics, so I can't get the values of any channels.  All of the info in the link above assumes that you automatically get a connection, and I'm out of ideas right now of things to try.  Does anyone else have any ideas?

  5710   Thu Oct 20 09:54:53 2011 jamieUpdateComputer Scripts / Programspynds working on pianosa again

Quote:

 

Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

 So I found that the NDS2 lib directory in (/ligo/apps/nds2/lib) was completely empty.  I reinstalled NDS2 and pynds, and they are now available again by default on pianosa (it should "just work", assuming you don't break your environment).

Why the NDS2 lib directory was completely empty is definitely a concern to me.  The contents of directories don't just disappear.  I can't imagine how this would happen other than someone doing it, either on purpose or accidentally.  If someone actually deleted the contents of this directory on purpose they need to speak up, explain why they did this, and come see me for a beating.

  9928   Thu May 8 01:33:21 2014 ericqUpdateCDSpython issues

On pianosa: The ezca.Ezca class somehow initializes with its prefix set to "C1:", even though the docstring says the default is None. This makes existing scripts act wonky, because they're looking for channels like "C1:C1:FO-BLAH".

In ligo/apps/linux-x86_64, I ran ln -sfn cdsutils-old cdsutils to get the old version back for now, so I don't have to edit all of our up/down scripts.

Also, Chiara can't find the epics package when I try to load Ezca. It exists in '/usr/lib/pymodules/python2.6/epics/__init__.pyc' on pianosa, but there is no corresponding 2.7 folder on chiara.

 

  9931   Thu May 8 15:55:43 2014 jamieUpdateCDSpython issues

Quote:

On pianosa: The ezca.Ezca class somehow initializes with its prefix set to "C1:", even though the docstring says the default is None. This makes existing scripts act wonky, because they're looking for channels like "C1:C1:FO-BLAH".

In ligo/apps/linux-x86_64, I ran ln -sfn cdsutils-old cdsutils to get the old version back for now, so I don't have to edit all of our up/down scripts.

Also, Chiara can't find the epics package when I try to load Ezca. It exists in '/usr/lib/pymodules/python2.6/epics/__init__.pyc' on pianosa, but there is no corresponding 2.7 folder on chiara.

I just pushed a fix to ezca to allow for having a truly empty prefix even if the IFO env var is set:

controls@pianosa:~ 0$ ipython
Python 2.6.5 (r265:79063, Feb 27 2014, 19:43:51) 
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: import ezca

In [2]: ezca.Ezca()
Out[2]: Ezca(prefix='C1:')

In [3]: ezca.Ezca(ifo=None)
Out[3]: Ezca(prefix='')

In [4]: ezca.Ezca(ifo=None).read('C1:LSC-DARM_GAIN')
Out[4]: 0.0

This is in cdsutils r232, which I just installed at the 40m.  I linked it in as well, so it's now the default version.  You will have to make a modification to any python scripts utilizing the Ezca object, but now it's a much smaller change (just in the invocation line):

-ca = ezca.Ezca()
+ca = ezca.Ezca(ifo=None)

 

  3835   Mon Nov 1 12:38:56 2010 Leo SingerConfigurationComputerspython-sqlite installed on Allegra

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

  11083   Fri Feb 27 10:25:24 2015 steveUpdateCamerasquad picture problem

MUX input 7 to ITMXF camera cable was replaced by temporary cable labeled as 888

The problem remains to be the same black stripe at the bottom of the image The single picture is OK.

Attachment 1: quadMUX.jpg
quadMUX.jpg
  7021   Tue Jul 24 21:16:55 2012 DenUpdatedigital noisequantization test

I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a1 and a2 gains should be switched. Other then that schemes correctly implement 2 order iir. 

The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ),  g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz

iir_2.png iir_8.png

For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms.

Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python.

  8544   Tue May 7 19:58:28 2013 ranaFrogsTreasurerabbitt whole

controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ ls
C1IOO_LKIN_OUT_MTRX.adl   C1IOO_MC_ASS_LOCKIN5.adl     C1IOO_WFS1_I.adl             C1IOO_WFS_LKIN.adl
C1IOO_LOCKMC.adl          C1IOO_MC_ASS_LOCKIN6.adl     C1IOO_WFS1_Q.adl             C1IOO_WFS_MASTER.adl
C1IOO_LOCKMC_BAK.adl      C1IOO_MC_ASS_PIT_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl      C1IOO_WFS_MASTER.adl~
C1IOO_MC_ALIGN.adl        C1IOO_MC_ASS_YAW_LOCKIN.adl  C1IOO_WFS1_SETTINGS.adl.old  C1IOO_WFS_MASTER_BAK.adl
C1IOO_MC_ALIGN.adl~       C1IOO_MC_LOCKINS.adl         C1IOO_WFS2_I.adl             C1IOO_WFS_OUTMATRIX.adl
C1IOO_MC_ALIGN_BAK.adl    C1IOO_MC_SERVO.adl           C1IOO_WFS2_Q.adl             C1IOO_WFS_QPD.adl
C1IOO_MC_ASS.adl          C1IOO_MC_TRANS_QPD.adl       C1IOO_WFS2_SETTINGS.adl      C1IOO_WFS_QPD.adl.old
C1IOO_MC_ASS_LOCKIN1.adl  C1IOO_Mech_Shutters.adl      C1IOO_WFS2_SETTINGS.adl.old  fmX
C1IOO_MC_ASS_LOCKIN2.adl  C1IOO_MODECLEANER.adl        C1IOO_WFS_HEADS.adl          junk
C1IOO_MC_ASS_LOCKIN3.adl  C1IOO_QPDS.adl               C1IOO_WFS_HEADS.adl.old      master
C1IOO_MC_ASS_LOCKIN4.adl  C1IOO_QPDS_BAK.adl           C1IOO_WFS_INMATRIX.adl       svn-commit.tmp~
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/caltech/c1/medm/c1ioo/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master 0$ cd master
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 0$ helppp
helppp: command not found
controls@rosalba:/opt/rtcds/userapps/trunk/isc/c1/medm/c1ioo/master/master/master/master 127$ help me
bash: help: no help topics match `me'.  Try `help help' or `man -k me' or `info me'.

  9458   Thu Dec 12 17:22:07 2013 SteveUpdateGeneralrack power supplies checked

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

Attachment 1: 1x1ps.jpg
1x1ps.jpg
Attachment 2: 1X5ps.jpg
1X5ps.jpg
Attachment 3: 1X9ps.jpg
1X9ps.jpg
Attachment 4: 1Y1ps.jpg
1Y1ps.jpg
Attachment 5: 1Y4ps.jpg
1Y4ps.jpg
Attachment 6: AuxLSCps.jpg
AuxLSCps.jpg
Attachment 7: AuxOmcSouthRackPs.jpg
AuxOmcSouthRackPs.jpg
Attachment 8: 1Y2.jpg
1Y2.jpg
  13649   Thu Feb 22 10:49:11 2018 SteveUpdateElectronicsrack power supplies checked

All rack power supplies labeled if their load changed.

 

Attachment 1: 1X1_DC.jpg
1X1_DC.jpg
Attachment 2: 1X5_DC.jpg
1X5_DC.jpg
Attachment 3: 1X9_DC.jpg
1X9_DC.jpg
Attachment 4: 1X8_DC.jpg
1X8_DC.jpg
Attachment 5: 1Y2_DC.jpg
1Y2_DC.jpg
Attachment 6: 1Y1_DC.jpg
1Y1_DC.jpg
Attachment 7: AUX_1Y2_DC.jpg
AUX_1Y2_DC.jpg
Attachment 8: AUX_OMC_DC.jpg
AUX_OMC_DC.jpg
  2064   Wed Oct 7 11:18:40 2009 kiwamuSummaryElectronicsracks of electronics

 

I took the pictures of all racks of electronics yesterday, and then uploaded these pictures on the wiki.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics

You can see them by clicking "pictures" in the wiki page.

 

  4290   Mon Feb 14 17:16:47 2011 steveUpdateGeneralracks, breakers labeled

The south arm labels were changed from y to x to reflect reality.

So racks, manual disconnects and breakers now have their actual name. The east arm will be changed over tomorrow.

Please remove incorrect labels if you see any !

I can not find 1X4 breaker so it will be  traced.

  70   Tue Nov 6 15:37:34 2007 robConfigurationSUSrampdown script
/cvs/cds/caltech/scripts/SUS/rampdown.pl is now in the crontab for op340m, running every half-hour at 15&45. It checks the suspension watchdog trip levels, and reduces them by 20 if they are above 150.
  4100   Sat Jan 1 16:36:16 2011 ranaConfigurationSUSrampdown.pl was not running

The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.

This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.

I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.

However, out test points are gone again, so who knows how things are behaving.

  4871   Thu Jun 23 22:53:02 2011 kiwamuUpdateCDSran activateDQ.py

I found some DQ channels (e.g. SENSOE_UL and etc.) for C1SUS haven't been activated, so I ran activateDQ.py.

Then I restarted daqd on fb as usual. So far the DQ channels look working fine.

  1897   Thu Aug 13 09:22:06 2009 ranaUpdatePEMranger

Rana, Jan, Jenne

We noticed that the Ranger data was all bogus at low frequencies. So we checked it and found that the proper procedure had not been used when changing it from horizontal to vertical last week. So the huddle test data from the weekend is not valid for the ranger; we will have to repeat it sometime.

So we used the manual, and extended the hanger rod on top of the Ranger to free the mass. It now has good response and coherence with the Guralps down to 0.1 Hz. See attached plot soon.

 

  12629   Mon Nov 21 11:30:01 2016 SteveUpdatePEMrat is cut and removed

Last jump at rack Y2.

Attachment 1: rat#2.png
rat#2.png
  2838   Sat Apr 24 15:50:47 2010 KojiUpdatePSLre: 2W Vertical Beam Profile

1. The vertical axis should start from zero. The horizontal axis should be extended so that it includes the waist. See Zach's plot http://nodus.ligo.caltech.edu:8080/40m/2818

2. Even if you are measuring only the linear region, you can guess w0 and z0, in principle. w0 is determined by the divergence angle (pi w0/lambda) and z0 is determined by the linear profile and w0. Indeed your data have some fluctuation from the linear line. That could cause the fitting prescision to be worse.

3. Probably the biggest reason of the bad fitting would be that you are fitting with three parameters (w0, z0, zR) instead of two (w0, z0). Use the relation ship zR= pi w0^2/lambda.

  2846   Mon Apr 26 16:51:37 2010 KevinUpdatePSLre: 2W Vertical Beam Profile

I tried Koji's suggestions for improving the fit to the vertical beam profile; however, I could not improve the uncertainties in the fit parameters.

I started retaking the data today with the same laser settings used last time and noticed that the photodiode was saturating. We were using an ND 4.0 neutral density filter on the photodiode. Koji and I noticed that the coating on the filter was reduced in the center and added an additional ND 0.6 filter to the photodiode. This seemed to fix the photodiode saturation.

I think that the photodiode was also saturating to a lesser extent when I took the last set of data. I will take another vertical beam profile tomorrow.

[Edit by KA: Metallic coating started being evaporated and the ND filters reduced their attenuation. We decided to use absorptive one as the first incident filter, and put a thinner one behind. This looked fine.]

  2847   Mon Apr 26 17:34:31 2010 KojiUpdatePSLre: 2W Vertical Beam Profile

Give me the plot of the fit, otherwise I am not convinced.

Quote:

I tried Koji's suggestions for improving the fit to the vertical beam profile; however, I could not improve the uncertainties in the fit parameters.

  2851   Tue Apr 27 15:29:16 2010 KevinUpdatePSLre: 2W Vertical Beam Profile

I thought that the micrometer I was using to move the razor through the laser beam was metric; however, it is actually english.

After discovering this mistake, I converted my previous measurements to centimeters and fit the data to

w = sqrt(w0^2+lambda^2*(z-z0)^2/(pi*w0)^2) with the following results:

reduced chi squared = 14.94

z0 = (-4.2 ± 1.9) cm

w0 = (0.013 ± 0.001) cm

Attachment 1: vbp.jpg
vbp.jpg
Attachment 2: vbp_residuals.jpg
vbp_residuals.jpg
  2857   Wed Apr 28 14:22:36 2010 KevinUpdatePSLre: 2W Vertical Beam Profile

I used the Mathematica CurveFit package that we use in Ph6/7 to make the fits for the beam profile data. I wrote two functions that use CurveFit shown in the attachment to make the fits to the error function and square root.

Attachment 1: BeamFit.nb.tar
  11080   Thu Feb 26 20:02:46 2015 JenneUpdateLSCre: some thoughts

I have clarified my elog from last night to indicate that the sensing matrix in the "33MHz cancellation" configuration was measured with the PRMI held on REFL55 I&Q.

Also, I just re-read my control room notes from yesterday, and I typed the wrong demod phases into the table last night.  The elog has been edited.  Most significantly, the REFL33 demod phase did not change by 70 degrees.  It did change by 10 degrees, but that is likely from the fact that it was formerly tuned for PRCL in PRFPMI, and last night I tuned it for PRCL in PRMI-only.

  9305   Mon Oct 28 18:57:27 2013 MasayukiHowToLSCread 'scope and spectrum analyser datas

 

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

 

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

  7487   Fri Oct 5 00:29:34 2012 DenUpdatePEMreadout box power

Guralp readout box received +13.7 /0/ -15V instead +15V because of the broken fuse. Power provided by the source is normal.

Edit by Den: I've found a similar fuse on one of the tables and borrowed it. Guralp is not working again.

  7490   Fri Oct 5 11:11:00 2012 DenUpdatePEMreadout box power

Quote:

Guralp readout box received +13.7 /0/ -15V instead +15V because of the broken fuse. Power provided by the source is normal.

Edit by Den: I've found a similar fuse on one of the tables and borrowed it. Guralp is not working again.

 I've meant Guralp is NOW working again 

  4710   Fri May 13 01:42:35 2011 kiwamuUpdateLSCready for Schnupp asymmetry measurement

[Valera / Kiwamu]

 We are able to lock each arm smoothly.  It is ready for the Schnupp asymmetry measurement.

( to be done )

 - Manual D-phase adjustment of the AS55 channel.

 - A script to adjust the D-phase.

 - Trigger logic for the boost filters.

 - Modification of some old alignment scripts to adopt them to the new LSC channels

  6357   Mon Mar 5 17:07:58 2012 kiwamuUpdateIOOrealigned MC

I have slightly shifted the MC beam pointing to relax the PZT1 PITCH. As a result the TRY value went to 0.97 in a first lock trial.

However another issue arose:

   The polarity for controlling the PZT1 PITCH seems to have flipped for some reason.

Since it is still sort of controllable, I am leaving it as it is.

If I remember correctly, sliding the PZT1 pitch value to the positive side brought the beam spot upward in the AS CCD. But now it moves in the opposite way.

Also the ASS feedback looks tending to push the PZT1 pitch to the wrong direction.

I am not 100 % sure if the polarity really flipped, but this is my current conclusion.

 

 

(MC pointing)

  1. Locked the Y arm and aligned ITMY and ETMY with the ASS servos such that the beam spot on each test mass is well centered on the test mass.
    • With this process the eigen axis of the Y arm cavity is well prepared.
  2. Checked the beam positions of the prompt reflection light and cavity leakage field in the AS CCD.
    • It looked the incident beam needed to go upward in the CCD view.
  3. Offloaded the MC WFS feedback values to the MC suspension DC biases in a manual way.
  4. Disabled the MC WFS servos. The MC transmitted light didn't become worse, which means the suspensions were well aligned to the input beam
  5. Changed the DC bias in the MC2 PITCH, to bring the beam spot upward. I changed the DC bias by ~ 0.1 or in the EPICS counts.
  6. Aligned the zig-zag steering mirrors on the PSL table to match the incident beam to the new MC eigen beam axis.
    • The transmitted DC light and reflected DC values went back to 27000 counts and 0.58 counts respectively without the WFS servos.
  7. Re-engaged the WFS servos.

Quote from #6351

PZT1 started railing in the pitch direction and because of this TRY doesn't go more than 0.7. I will leave it as it is for tonight.

Tomorrow I will shift the alignment of the MC to make the PZT1 happier. 

 

  3923   Mon Nov 15 15:01:51 2010 kiwamuUpdateIOOrealigned the wideband EOM

Since we are going to lock the MC today, I aligned it back to the default place.

Quote: #3888

For Yuta's business, I intentionally misaligned the wideband EOM slightly to Yaw direction. 

  16650   Mon Feb 7 16:14:37 2022 TegaUpdateComputersrealtime system reboot problem

I was looking into plotting temperature sensor data trend and why we currently do not have frame data written to file (on /frames) since Friday, and noticed that the FE models were not running. So I spoke to Anchal about it and he mentioned that we are currently unable to ssh into the FE machines, therefore we have been unable to start the models. I recalled the last time we enountered this problem Koji resolved it on Chiara, so I search the elog for Koji's fix and found it here, https://nodus.ligo.caltech.edu:8081/40m/16310. I followed the procedure and restarted c1sus and c1lsc machine and we are now able to ssh into these machines. Also restarted the remaining FE machines and confirm that can ssh into them. Then to start models, I ssh into each FE machine (c1lsc, c1sus, c1ioo, c1iscex, c1iscey, c1sus2) and ran the command

rtcds start --all

to start all models on the FE machine. This procedure worked for all the FE machines but failed for c1lsc. For some reason after starting the first the IOP model - c1x04, c1lsc and c1ass, the ssh connection to the machine drops. When we try to ssh into c1lsc after this event, we get the following error :  "ssh: connect to host c1lsc port 22: No route to host".  I reset the c1lsc machine and deecided to to start the IOP model for now. I'll wait for Anchal or Paco to resolve this issue.


[Anchal, Tega]

I informed Anchal of the problem and ask if he could take a look. It turn out 9 FE models across 3 FE machines (c1lsc, c1sus, c1ioo) have a certain interdependece that requires careful consideration when starting the FE model. In a nutshell, we need to first start the IOP models in all three FE machines before we start the other models in these machines. So we turned off all the models and shutdown the FE machines mainly bcos of a daq issue, since the DC (data concentrator) indicator was not initialised. Anchal looked around in fb1 to figure out why this was happening and eventually discovered that it was the same as the ms_stream issue encountered earlier in fb1 clone (https://nodus.ligo.caltech.edu:8081/40m/16372). So we restarted fb1 to see if things clear up given that chiara dhcp sever is now working fine. Upon restart of fb1, we use the info in a previous elog that shows if the DAQ network is working or not, r.e. we ran the command

$ /opt/mx/bin/mx_info
MX:fb1:mx_init:querying driver:error 5(errno=2):No MX device entry in /dev.

 The output shows that MX device was not initialiesd during the reboot as can also be seen below.

$ sudo systemctl status daqd_dc -l

● daqd_dc.service - Advanced LIGO RTS daqd data concentrator
   Loaded: loaded (/etc/systemd/system/daqd_dc.service; enabled)
   Active: failed (Result: exit-code) since Mon 2022-02-07 18:02:02 PST; 12min ago
  Process: 606 ExecStart=/usr/bin/daqd_dc_mx -c /opt/rtcds/caltech/c1/target/daqd/daqdrc.dc (code=exited, status=1/FAILURE)
 Main PID: 606 (code=exited, status=1/FAILURE)

Feb 07 18:01:56 fb1 systemd[1]: Starting Advanced LIGO RTS daqd data concentrator...
Feb 07 18:01:56 fb1 systemd[1]: Started Advanced LIGO RTS daqd data concentrator.
Feb 07 18:02:00 fb1 daqd_dc_mx[606]: [Mon Feb  7 18:01:57 2022] Unable to set to nice = -20 -error Unknown error -1
Feb 07 18:02:00 fb1 daqd_dc_mx[606]: Failed to do mx_get_info: MX not initialized.
Feb 07 18:02:00 fb1 daqd_dc_mx[606]: 263596
Feb 07 18:02:02 fb1 systemd[1]: daqd_dc.service: main process exited, code=exited, status=1/FAILURE
Feb 07 18:02:02 fb1 systemd[1]: Unit daqd_dc.service entered failed state.


NOTE: We commented out the line

Restart=always

in the file "/etc/systemd/system/daqd_dc.service" in order to see the error, BUT MUST UNDO THIS AFTER THE PROBLEM IS FIXED!

  2619   Fri Feb 19 16:40:43 2010 kiwamuUpdateGreen Lockingrearrange the optics on the end table

Koji and kiwamu

The existing optics on the ETMX/ETMY end table were rearranged in this morning.

 


The main things we have done are -

1. relocation of the optical levers for ETMs ( as mentioned in koji's entry )

This relocation can make a space so that we can setup the green locking stuffs.

The optical path of the green locking is planed to start from the right top corner on the table, therefore we had to relocate the oplevs toward the center of the table.

2. relocation of the lens just before the tube

Because we are going to shoot the green beam into the arm cavity, we don't want to have any undesired lenses before the cavity.

For this reason we changed the position of the lens, it was standing just in front of the tube, now it's standing on the left side of the big mirror standing center top.

Since we did not find a significant change in its the spot size of the transmitted light, we did not change the position of all the TRANS_MON_PDs and its mirrors. And they are now well aligned.

Attachment1: ETMX end table

Attachment2: ETMY end table

Attachment 1: DSC_1202.JPG
DSC_1202.JPG
Attachment 2: DSC_1207.JPG
DSC_1207.JPG
  6145   Thu Dec 22 19:15:22 2011 kiwamuUpdateGreen Lockingrearrangement of PSL green optics
 As planed (#6143), rearrangement of the PSL green setup has begun.
It required to move approximately half of the green optics on the PSL table
and I finished displacing and installing the necessary optics coarsely.
So far I just have recovered the Y arm beat-note between the PSL green light.
 
 I will do a fine alignment of the X arm path on the PSL table and try obtaining the X arm beat-note tonight.
  6147   Fri Dec 23 01:07:41 2011 kiwamuUpdateGreen Lockingrearrangement of PSL green optics part II

After I did a fine alignment of the X green beam path on the PSL table, the X arm beat-note was also obtained.

Here is a picture of the latest setup. The blue lines represent S-polarizing green beams.

newLayout.png

During I was working on the PSL table HEPA was at 80 %, and after the work I brought it to 20 %.

Quote from #6145
 I will do a fine alignment of the X arm path on the PSL table and try obtaining the X arm beat-note tonight.

  10576   Tue Oct 7 16:17:15 2014 SteveUpdateGeneralreason for 8 sec power outage

Quote:

We had a unexpected power shutdown for 5 sec at ~ 9:15 AM.

Chiara had to be powered up and am in the process of getting everything else back up again.

Steve checked the vacuum and everything looks fine with the vacuum system.

 

There was an equipment malfunction in one of Pasadena's substation that caused the outage. After about an 8 second delay, back up circuits restored power. This affected about 1/2 of the campus.

Mike 

-----Original Message-----
From: Steve Vass [mailto:steve@ligo.caltech.edu] 
Sent: Tuesday, October 07, 2014 2:18 PM
To: Anchondo, Michael
Subject: 5s

Hi Mike,

Can you tell me about yesterday's power outage?

Thanks, Steve
  9668   Tue Feb 25 00:00:01 2014 rana, jenneUpdateLSCreasons that the REFL signals may be degenerate now

We're exploring some effects which may give some funny macroscopic detuning and cause a near phase degeneracy in the REFL RF signals (see radar plot from Jenne below).

1) Alignment: we centered the oplevs to reduce fluctuations and then tweaked the BS and PRM alignment to build up the power. No significant change in the RF phases of the DOFs.

2) Measuring RAM: we set the dark offsets (by hand since the Masayuki script doesn't really work well anymore) to with 1 counts. We then locked the MC, misaligned the ITMs, and looked at the REFLOUT16 channels using the following command line:

z avg 12 C1:LSC-REFL11_I_OUT16 C1:LSC-REFL11_Q_OUT16 C1:LSC-REFL33_I_OUT16 C1:LSC-REFL33_Q_OUT16 C1:LSC-REFL55_I_OUT16 C1:LSC-REFL55_Q_OUT16 C1:LSC-REFL165_I_OUT16 C1:LSC-REFL165_Q_OUT16
C1:LSC-REFL11_I_OUT16     -12.04
C1:LSC-REFL11_Q_OUT16     -14.34
C1:LSC-REFL33_I_OUT16       0.43
C1:LSC-REFL33_Q_OUT16      -0.28
C1:LSC-REFL55_I_OUT16       2.84
C1:LSC-REFL55_Q_OUT16       5.64
C1:LSC-REFL165_I_OUT16      4.40
C1:LSC-REFL165_Q_OUT16      0.10

So these offsets are small in counts. In meters this corresponds to....less than 3 pm for any of the I signals.

Refl11I = 2.06e-12 meters

Refl11Q = 2.94e-10 meters

Refl33I = 5.28e-13 meters

Refl33Q = 1.07e-11 meters

Refl55I = 2.71e-12 meters

Refl55Q = 3.55e-11 meters

Refl165I = 3.07e-13 meters

Refl165Q = 8.63e-14 meters

 

 

3) Next we want to put large offsets into the error points of the loops

4) Change modulation depth

5) Check IMC length (todo for Q/Manasa for Tuesday - Wednesday)

  4023   Tue Dec 7 19:34:58 2010 kiwamuUpdateCDSrebooted DAQ and all the front end machines

I found that all the front end machine showed the red light indicators of DAQ on the XXX_GDS_TP.adl screens.

Also I could not get any data from both test points and DAQ channels.

First I tried fixing by telneting and rebooting fb, but it didn't help.

So I rebooted all the front end machines, and then everything became fine.

 

  4393   Wed Mar 9 23:19:04 2011 kiwamuUpdateCDSrebooted c1ioo

For some reason the c1ioo machine suddenly died just 30 miteus before.

It died after we added a DAQ channel for c1gcv and rebooted the frame builder.

It didn't respond to a ping command. Therefore I rebooted the machine by clicking the physical reset button.

Now it seems fine.

  10989   Mon Feb 9 08:40:49 2015 SteveUpdateSUSrecent earthquake 4.9

Baja 4.9 m earth quake tripped suspentions, except ETMX Sus damping recovered. MC is locking.
 

Attachment 1: M4.9Baja.png
M4.9Baja.png
  10850   Sun Jan 4 12:49:18 2015 SteveUpdateSUSrecent earthquakes

All suspensions were tripped. Damping were restored. No obvious sign of damage. BS OSEM-UR may be sticking ?

Attachment 1: recentEQ.png
recentEQ.png
  10846   Mon Dec 29 21:30:25 2014 ranaUpdateGeneralrecovery
  1. Control room is at +66 F. Brrrr.
  2. Alignment of input beam into the IMC was wacky; locked on HOM.
  3. Re-aligned beam into the PMC first.
  4. Restarted mxstream for c1sus.
  5. Power cycled Martian router; all laptops were lost. Now better.
  6. Aligned launch beam from PSL to get onto the MCWFS better, MC is locking OK now. Moved MC SUS a little to get back to OSEM values from 6 days ago.
  7. Fixed LOCK_MC screen quad displays to be cooler.
  8. changed many of the ezcawrite calls in the mcup / mcdown to be 'caput -l' for more robustness. Still need ezcawrite for the binbary calls.
  9.  I didn't touch the mirrors on the MC REFL path, so we can still use that as a reference once the temperature returns to normal; the PSL room temp is down to 20C from 22 C a couple days ago.
  10. TRX values coming in to the LSC were frozen and the TRY_OUT16 was going to huge values even though camera flashes were reasonable. Tried restarting c1lsc model. No luck.
  11. Also tried shutdown -r now on c1lsc. No luck. Probably needs a RFM boot.
  12. Increased the FSS SLOW servo threshold to 9999 counts to avoid it running on some misaligned TEM01 mode locks. Increased the PID's I gain from 0.05 to 0.356 by tuning on some step responses as usual.
  13. By midnight the control room temperature is back around 71 F.
  9760   Fri Mar 28 22:10:00 2014 rana, kojiUpdateSUSrecovery from

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

Attachment 1: Screenshot.png
Screenshot.png
  9763   Mon Mar 31 08:11:00 2014 SteveUpdateSUSrecovery from earthquakes

Quote:

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

Local earthquake activity is up. Our suspensions are holding well.    ETMX and ETMY sus damping restored.

Attachment 1: local5.1eq.png
local5.1eq.png
Attachment 2: EQ4.4-5.1-3.3-16days.png
EQ4.4-5.1-3.3-16days.png
  5963   Sun Nov 20 14:48:55 2011 kiwamuUpdateGeneralrecovery from the power shutdown

Recovery from the power shutdown

 - Turned on the raid disk of linux1.

 - Woke linux1 up. No fsck this time.

 - Woke up all the lab machines.

 - Turned on all the electronics racks' AC powers

 - Woke up fb and then front end machine (the raid for fb had been already up as I turned on the AC powers)

 - Turned on all the electronics racks' DC powers (Sorensens, Kepcos, and etc.)

 - Turned on the Marcnois which is driving the RF generation box.

 - Woke up all the lasers (PSL and End lasers)

 - Some burtrestoring (c1ioo, c1sus, c1susaux, c1msc, c1psl, c1iool0, c1auxey, c1auxex, c1oaf, c1pem)

 - Ran autolockMC scripts on op340m => After relocking of PMC a lock of MC was acquired immediately.

 - Turned on the PZT HV drivers.

 

Some issues

 - One of the Sorensens in 1X8 rack is showing the current limit sign. This is exactly the same situation as we saw before (#5592).

       Currently it's off. It needs an investigation to find who is drawing such a large amount of current.

 - C1SCX is not properly running. Rebooting the machine didn't help. This needs to be fixed.

       The symptom is : (1) all the values are frozen in the screens. (2) the c1scx status screens shows NO SYNC sign. (3) however the timing board looks blinking happily.

 - One of the VME rack on 1X3 is not showing the +/-15V green LED lights.

   This is the one on very upper side of the rack, which contains the old c1lsc machine and c1iscaux2. If we are still using c1iscaux2, it needs to be fixed.

  5965   Sun Nov 20 15:33:37 2011 ranaUpdateGeneralrecovery from the power shutdown

 restarted Apache on Nodus for the SVN as per wiki instructions

ELOG V3.1.3-