40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 20 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  3531   Tue Sep 7 10:50:53 2010 josephbConfigurationComputersrossa notes

The controls group is user id 500 by default on most new machines. Unfortunately, the user ID used across the already existing machines is 1001. One method of doing this switch is in this elog.  You can also do the change of the controls ID by becoming root and using the graphical command system-config-users.  This will  let you change the user ID and group ID for controls to 1001.  This graphical interface also lets you change the login shell.

Unfortunately, I had some minor difficulty and I ended up removing the old controls and creating a new controls account with the correct values and using tcsh.  The .cshrc file has been recreated to source cshrc.40m.  The controls account now has correct permissions, although some of the preferences such as background will need to be reset.

 

 

Quote:

**** Deleted
apps/emacs
apps/linux64/firefoxold
apps/linux64/comsol      (old v. 3.5)

* running up2date on rossa

* rossa needs to be able move windows between monitors: Xinerama?

* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?

 

  3539   Tue Sep 7 23:17:45 2010 sanjitConfigurationComputersrossa notes

Quote:

* rossa needs to be able move windows between monitors: Xinerama?

 Xinerama support has been enabled on rossa using nvidia-settings.

  3557   Sat Sep 11 03:16:51 2010 ranaConfigurationComputersrossa notes

I wiped out the old CentOS install on rossa and installed CentOS 5.5 on there. The DVDs are on a spindle in the control room; there were 2 iso's, but I only needed the first to install most things.

It still needs to get all of the usual stuff (java, flash, nvidia) installed as well as setting up the .cshrc and the NFS mount of /cvs/cds. The userID and groupID are set to 1001 as before. Whoever

sees Sanjit first should steer him towards this elog entry.

 

  3559   Sun Sep 12 22:36:03 2010 ranaConfigurationComputersrossa notes

I found Sanjit's instructions for doing the Nvidia settings too complicated and so I followed these instructions from Facebook:

http://www.facebook.com/notes/centos-howtos/installing-nvidia-display-drivers-on-centos-55/399295987425

After installations, the monitors were autodetected and the Xinerama effect is working.

  6662   Tue May 22 20:24:06 2012 JamieUpdateComputersrossa is now running Ubuntu 10.04

Now same as pianosa and rosalba.  I'll upgrade allegra on Friday.

  14784   Sat Jul 20 11:24:04 2019 gautamUpdateGeneralrossa bricked

Summary:

SnapPy scripts made to work on Pianosa.

Details:

Of course rossa was the only machine in the lab that could run the python scripts to interface with the GigE camera. And it is totally bricked now. Lame.

So I installed several packages. The key was to install pypylon - if you go to the basler webpage, pypylon1.4.0 does not offer python2.7 support for x86_64 architecture, so I installed pypylon1.3.0. Here are the relevant lines from the changelog:

gstreamer-plugins-bad-0.10.23-5.el7.x86_64    Sat 20 Jul 2019 11:22:21 AM PDT
gstreamer-plugins-good-0.10.31-13.el7.x86_64  Sat 20 Jul 2019 11:22:11 AM PDT
gstreamer-plugins-ugly-0.10.19-31.el7.x86_64  Sat 20 Jul 2019 11:20:08 AM PDT
gstreamer-python-devel-0.10.22-6.el7.x86_64   Sat 20 Jul 2019 10:34:35 AM PDT
pygtk2-devel-2.24.0-9.el7.x86_64              Sat 20 Jul 2019 10:34:34 AM PDT
pygobject2-devel-2.28.6-11.el7.x86_64         Sat 20 Jul 2019 10:34:33 AM PDT
pygobject2-codegen-2.28.6-11.el7.x86_64       Sat 20 Jul 2019 10:34:33 AM PDT
gstreamer-devel-0.10.36-7.el7.x86_64          Sat 20 Jul 2019 10:34:32 AM PDT
gstreamer-python-0.10.22-6.el7.x86_64         Sat 20 Jul 2019 10:34:31 AM PDT
gtk2-devel-2.24.31-1.el7.x86_64               Sat 20 Jul 2019 10:34:30 AM PDT
libXrandr-devel-1.5.1-2.el7.x86_64            Sat 20 Jul 2019 10:34:28 AM PDT
pango-devel-1.42.4-1.el7.x86_64               Sat 20 Jul 2019 10:34:27 AM PDT
harfbuzz-devel-1.7.5-2.el7.x86_64             Sat 20 Jul 2019 10:34:26 AM PDT
graphite2-devel-1.3.10-1.el7_3.x86_64         Sat 20 Jul 2019 10:34:26 AM PDT
pycairo-devel-1.8.10-8.el7.x86_64             Sat 20 Jul 2019 10:34:25 AM PDT
cairo-devel-1.15.12-3.el7.x86_64              Sat 20 Jul 2019 10:34:25 AM PDT
mesa-libEGL-devel-18.0.5-3.el7.x86_64         Sat 20 Jul 2019 10:34:24 AM PDT
libXi-devel-1.7.9-1.el7.x86_64                Sat 20 Jul 2019 10:34:24 AM PDT
pygtk2-doc-2.24.0-9.el7.noarch                Sat 20 Jul 2019 10:34:23 AM PDT
atk-devel-2.28.1-1.el7.x86_64                 Sat 20 Jul 2019 10:34:21 AM PDT
libXcursor-devel-1.1.15-1.el7.x86_64          Sat 20 Jul 2019 10:34:20 AM PDT
fribidi-devel-1.0.2-1.el7.x86_64              Sat 20 Jul 2019 10:34:20 AM PDT
pixman-devel-0.34.0-1.el7.x86_64              Sat 20 Jul 2019 10:34:19 AM PDT
libXinerama-devel-1.1.3-2.1.el7.x86_64        Sat 20 Jul 2019 10:34:19 AM PDT
libXcomposite-devel-0.4.4-4.1.el7.x86_64      Sat 20 Jul 2019 10:34:19 AM PDT
libicu-devel-50.1.2-15.el7.x86_64             Sat 20 Jul 2019 10:34:18 AM PDT
gdk-pixbuf2-devel-2.36.12-3.el7.x86_64        Sat 20 Jul 2019 10:34:17 AM PDT
pygobject2-doc-2.28.6-11.el7.x86_64           Sat 20 Jul 2019 10:34:16 AM PDT
pygtk2-codegen-2.24.0-9.el7.x86_64            Sat 20 Jul 2019 10:34:15 AM PDT

Camera server is running on a tmux session on pianosa. But it keeps throwing up some gstreamer warnings/errors, and periodically (~every 20 mins) crashes. Kruthi tells me that this behavior was seen on Rossa as well, so whatever the problem is, doesn't seem to be because I missed out on installing some packages on pianosa. Moreover, if the server is in fact running, I am able to take a snapshot - but the camera client does not run.

  16075   Thu Apr 22 14:49:08 2021 gautamUpdateComputer Scripts / Programsrossa added to RTS authorized keys

This is to facilitate running of scripts like the CDS reboot script, mx_stream restart, etc, from rossa, without being pwd prompted every time, whereas previously it was only possible from pianosa. I added the public key of rossa to FB and the RT FE servers. I suppose I could add it to the Acromag servers too, but I haven't yet.

  14780   Fri Jul 19 17:42:58 2019 gautamUpdateGeneralrossa Xdisp bricked

For some reason, rossa's Xdisplay won't start up anymore. This happened right after the UPS reset. Koji and I tried ~1.5 hours of debugging, got nowhere.

  14794   Sun Jul 21 22:16:34 2019 ranaUpdateGeneralrossa Xdisp bricked

"bricked" is to mean that it has the functionality of a brick and can be tossed. But rossa seems to have just gotten some software config corruption. I spent a couple hours reinstalling SL7 today as per my previous elog notes and the X display seems to work as before.

i.e. it was fine with the default setup, except for the ole "X chrashes if the mouse goes to left side of screen". As before, I

  1. blacklisted the nouvaeu driver (which is used by default)
  2. download the NVIDIA driver as per the link
  3. run its installation from the no-X terminal

left side of screen is safe again

This time I installed SL7.6 and followed the K Thorne wiki. But its having trouble installing cds-root because it can't find root.frown

 

  6653   Mon May 21 19:16:55 2012 KojiUpdateGeneralrossa X config

I rebooted rossa and the X sever has stalled.

  6573   Thu Apr 26 16:35:34 2012 JamieSummaryCDSrosalba now running Ubuntu 10.04

This morning I installed Ubuntu 10.04 on rosalba.  This is the same version that is running on pianosa.  The two machines should be identically configured, although rosalba may be missing some apt-getable packages.

  2646   Sun Feb 28 23:47:52 2010 ranaUpdateComputersrosalba

Since Rosalba wanted to update ~500 packages, I let it do it. This, of course, stopped the X server from running. I downloaded and installed the newest Nvidia driver and its mostly OK.

The main problem with the auto-update on our workstations is that we've updated some packages by hand; i.e. not using the standard CentOS yum. So that means that the auto-update doesn't work right. From now on, if you want to install a fancier package than what CentOS distributes, you should commit to handle the system maintenance for these workstations for the future. Its not that we can't have new programs, we just have to pay the price.

 

At 23:45 PST, I also started a slow triangle wave on the AOM drive amplitude. This is to see if there's a response in the FSS-FAST which might imply a coupling from intensity noise to frequency noise via absorbed power and the dn/dT effect in the coatings.

Its a 93 second period triangle modulating the RC power from 100% down to 50%.

  3495   Tue Aug 31 13:31:00 2010 steveUpdatePEMroom temp lowered

I lowered room 101 thermostat setting from 74F to 72F

  3497   Tue Aug 31 15:26:46 2010 ranaUpdatePEMroom temp lowered

And I raised it back to 73F. The thermometers on the wall show 74-75F as the actual room temp. The dial on the temperature controller is not calibrated.

  11966   Mon Feb 1 14:08:06 2016 SteveUpdatePEMroof condtion is good

It rained hard yesterday. We have not had this strong downpoor for years. We got 0.7" and the roof did not leak.

  14266   Fri Nov 2 10:24:20 2018 SteveUpdatePEMroof cleaning

Physical plan is cleaning our roof and gutters today.

  1383   Wed Mar 11 01:16:40 2009 ranaSummaryIOOrogue trianglewave in the MC Servo offset slider

On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76

which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the

run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect

this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.

 

In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations

in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into

the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting

an AM laser signal and adjusting the digital gains.

 

Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot

shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.

Attachment 1: Untitled.png
Untitled.png
Attachment 2: Untitled.png
Untitled.png
Attachment 3: a.png
a.png
  7305   Wed Aug 29 09:35:03 2012 janoschMetaphysicsRingdownripples 2

Ok, so the whole idea that mirror motion can explain the ripples is nonsense. At least, when you think off the ringdown with "pump off". The phase shifts that I tried to estimate from longitudinal and tilt mirror motion are defined against a non-existing reference. So I guess that I have to click on the link that Koji posted...

Just to mention, for the tilt phase shift (yes, there is one, but the exact expression has two more factors in the equation I posted), it does not matter, which mirror tilts. So even for a lower bound on the ripple time, my equation was incorrect. It should have the sum over all three initial tilt angles not only the two "shooting into the long arms" of the MC.

Quote:

Laser frequency shift = longitudinal motion of the mirrors

Ringing: http://www.opticsinfobase.org/ol/abstract.cfm?uri=ol-20-24-2463

Quote:

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?

 

 

  7301   Tue Aug 28 18:28:21 2012 janoschMetaphysicsRingdownripples

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

  7302   Tue Aug 28 19:06:32 2012 KojiMetaphysicsRingdownripples

Isn't it just a ringing of the intracavity power as you shifted the laser frequency abruptly?

Quote:

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

 

  7303   Tue Aug 28 19:21:37 2012 janoschMetaphysicsRingdownripples

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?

Quote:

Isn't it just a ringing of the intracavity power as you shifted the laser frequency abruptly?

Quote:

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

 

 

  7304   Tue Aug 28 20:23:54 2012 KojiMetaphysicsRingdownripples

Laser frequency shift = longitudinal motion of the mirrors

Ringing: http://www.opticsinfobase.org/ol/abstract.cfm?uri=ol-20-24-2463

Quote:

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?

 

  7029   Wed Jul 25 15:33:55 2012 janoschUpdateLSCringdown measurement

We did our first ringdown measurement on the Y arm. First we tried to keep the arm locked in green during the ringdown, but for some reason it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only.

For the measurement we had to change the LSC model to acquire the C1:LSC-TRY_OUT_DQ at higher sampling frequency. We changed the sampling frequencies of C1:LSC-{TRX,TRY}_OUT_DQ from 2048Hz to 16384Hz.

The measurement was done at GPS 1027289507. The ringdown curve looks very clean, but there seem to be two time constants involved. The first half of the curve is influenced by the shutter speed, then curvature is changing sign and the ringdown is likely taking over. We will try to fit a curve to the ringdown part, but it would certainly be better to have a faster shutter and record a more complete ringdown.

Rindown1.png

 

  7033   Wed Jul 25 22:16:36 2012 KojiUpdateLSCringdown measurement

Is this the step response of the single pole low pass???
It should have an exponential decay, shouldn't it? So it should be easier to comprehend the result with a log scale for vertical axis...

I think you need a fast shutter. It is not necessary to be an actual shutter but you can use faster thing
which can shut the light. Like PMC or IMC actuators.

Another point is that you may like to have a witness channel like the MC transmission to subtract other effect.

  1452   Fri Apr 3 10:01:50 2009 steveUpdateVACrgascan with temp plot

Rga scan of day 231 since pumpdown pd66-m-d231

m stands for maglev pumping speed, vacuum normal condition of valves,

cc4 cold cathode gauge at the rga location,

cc1 is real ifo pressure from the 24" tube at the pumpspool,

PEM-count temp: vac envelope temp at the top of IOO chamber

 

 

Attachment 1: pd66tempow.jpg
pd66tempow.jpg
Attachment 2: rga-090403scan.png
rga-090403scan.png
  1227   Wed Jan 14 10:59:06 2009 steveBureaucracyVACrga waiting to be "connected"
We have no RGA data since old Dycor passed away in the middle of Oct, 2008
New SRS-RGA200 was installed on the vac envelope on Nov 14, 2008
It is waiting to be software connected to the 40m logging
  351   Mon Mar 3 09:25:33 2008 steveUpdateVACrga scan logging is working now

Quote:

Quote:
The rga head and controller are running fine, but the data logging is not.


It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script.




Thanks to Rob, it is working !

The baked, calibrated rga head
model# M206M, s/n #c128035 was reinstalled at the 40m ifo on Feb. 8, 2008
Faraday mode dwell time was increased from 2 to 16 sec
Rga head temp at top silver gaskit 45.2 C
The noise floor is at 1E-12 Torr

There is more detail in logbook VMI-14 p 107

pd65-m-d119
Attachment 1: rgalogworks.jpg
rgalogworks.jpg
Attachment 2: cc1.jpg
cc1.jpg
  14229   Thu Oct 4 08:25:50 2018 SteveUpdateVACrga scan pd81 at day 78

 

 

Attachment 1: pd81d78.png
pd81d78.png
  14291   Tue Nov 13 16:15:01 2018 SteveUpdateVACrga scan pd81 at day 119

 

 

Attachment 1: pd81-d119.png
pd81-d119.png
Attachment 2: pd81-560Hz-d119.png
pd81-560Hz-d119.png
  76   Wed Nov 7 09:38:01 2007 steveUpdateVACrga scan
pd65-m-d2 at cc1 6e-6 torr
Attachment 1: pd65d2.jpg
pd65d2.jpg
  887   Tue Aug 26 15:06:16 2008 steveConfigurationVACrga scan
Pumpdown 66 PRM-maglev vac normal -day 11
short form: pd66PRM-m-d11
Attachment 1: RGA-0808260125.png
RGA-0808260125.png
  344   Thu Feb 28 13:04:59 2008 robUpdateVACrga logging working again

Quote:
The rga head and controller are running fine, but the data logging is not.


It should run tonight at 1:25 AM. To get the cron job to work properly on op340m, I had to make wrapper sh script which defines the perl library before calling the actual RGAlogger script.
  129   Wed Nov 28 08:47:29 2007 steveOmnistructureVACrga is out of order
The rga is not working since Nov 10
The controller is broken.
pd65-m-d23
Attachment 1: pd65d23.jpg
pd65d23.jpg
  1085   Fri Oct 24 15:05:13 2008 steveUpdateVACrga is out of order
The old Dycor RGA is out of order.
I'm getting ready to purchase an SRS instrument.
  322   Tue Feb 19 10:14:13 2008 steveUpdateVACrga logging needs help
The rga head and controller are running fine, but the data logging is not.
  475   Tue May 13 10:38:28 2008 steveUpdateComputersrfm network is down
The RFM network went down yesterday around 5pm
Only c1susvme1 is alive but it's timing is off.
Andrey is bringing the network up.

Andrey wants to make an addition first that our situation is very much similar to that described by Rana in his elog entry # 353 (March 03). All of the rectangular boxes are red, except for SUS1-c1susvme1 and AWG (only these two rectangles are green).
  13282   Thu Aug 31 18:36:23 2017 gautamUpdateCDSrevisiting Acromag

Current status:

  • There is a single Acromag ADC unit installed in 1X4
  • It is presently hooked up to the PSL NPRO diagnostic connector channels
  • I had (re)-started the acquisiton of these channels on August 16 - but for reasons unknown, the tmux session that was supposed to be running the EPICS server on megatron seems to have died on August 22 (judging by the trend plot of these channels, see Attachment #1)
  • I had not set up an upstart job that restarts the server automatically in such an event. I manually restarted it for now, following the same procedure as linked in my previous elog.
  • While I was at it, I also took the opportunity to edit the Acromag channel names to something more appropriate - all channels previously prefixed with C1:ACRO- have now been prefixed with C1:PSL-

Plan of action:

  1. Hardware - we have, in the lab, in addition to the installed ADC unit
    • 3x 8 channel differential input ADC units
    • 2x 8 channel differential output DAC units
    • 1x 16 channel BIO unit
    • 2U chassis + connectors + breakout boards + other misc hardware that I think Johannes and Lydia procured with the original plan to replace the EX slow controls.
    • Some relevant elogs: Panel designs, breakout design, sketch for proposed layout, preliminary channel list.
      So on the hardware side, it would seem that we have everything we need to go ahead with replacing the EX slow controls with an Acromag system, although Johannes probably knows more about our state of readiness from a hardware PoV.
  2. Software
    • We probably want to get a dedicated machine that will handle the EPICS channel serving for the Acromag system
    • Have to figure out the networking arrangement for such a machine
    • Have to figure out how to set up the EPICS server protocol in such a way that if it drops for whatever reason, it is automatically restarted

 

Attachment 1: Acromag_EPICS.png
Acromag_EPICS.png
  13422   Thu Nov 9 15:33:08 2017 johannesUpdateCDSrevisiting Acromag
Quote:

We probably want to get a dedicated machine that will handle the EPICS channel serving for the Acromag system

http://www.supermicro.com/products/system/1U/5015/SYS-5015A-H.cfm?typ=H

This is the machine that Larry suggested when I asked him for his opinion on a low workload rack-mount unit. It only has an atom processor, but I don't think it needs anything particularly powerful under the hood. He said that we will likely be able to let us borrow one of his for a couple days to see if it's up to the task. The dual ethernet is a nice touch, maybe we can keep the communication between the server and the DAQ units on their separate local network.

  13536   Thu Jan 11 21:09:33 2018 gautamUpdateCDSrevisiting Acromag

We'd like to setup the recording of the PSL diagnostic connector Acromag channels in a more robust way - the objective is to assess the long term performance of the Acromag DAQ system, glitch rates etc. At the Wednesday meeting, Rana suggested using c1ioo to run the IOC processes - the advantage being that c1ioo has the systemd utility, which seems to be pretty reliable in starting up various processes in the event of the computer being rebooted for whatever reason. Jamie pointed out that this may not be the best approach however - because all the FEs get the list of services to run from their common shared drive mount point, it may be that in the event of a power failure for example, all of them try and start the IOC processes, which is presumably undesirable. Furthermore, Johannes reported the necessity for the procServ utility to be able to run the modbusIOC process in the background - this utility is not available on any of the FEs currently, and I didn't want to futz around with trying to install it.

One alternative is to connect the PSL Acromag also to the Supermicro computer Johannes has set up at the Xend - it currently has systemd setup to run the modbusIOC, so it has all the utilities necessary. Or else, we could use optimus, which has systemd, and all the EPICS dependencies required. I feel less wary of trying to install procServ on optimus too. Thoughts?

 

  3813   Thu Oct 28 20:08:26 2010 yutaUpdateGreen Lockingrevised RF amp cascading

Background:
  Yesterday, I said I will use ZHL-32A for amplifying beat note signal, but as Koji pointed out, ZHL-32A is for medium high power.
  So I changed my mind to use ZFL-1000LN instead. ZFL-1000LN is a low noise RF amp whose maximum power is 3dBm.
  Also, we included a splitter in our consideration.

What I did:

1. Set up a new setup. ZFL-1000LN has a gain of +24dB at 80MHz and splitter ZFRSC-42 has a loss of -6dB. So;

beat note signal -> ZFL-1000LN -> ZFL-1000LN -> ZFRSC-42 => SR620 and VCO

2. Measured frequency-output relation. When the input signal was 80MHz -48dBm, the output was -8.7dBm. For other frequencies;
       60MHz  -3.3dBm
       70MHz  -5.7dBm
       80MHz  -8.7dBm
       90MHz  -5.5dBm
      100MHz  -3.5dBm
  So, we can see frequency up to >100MHz by SR620 using this setup.

3. Checked harmonics peak levels of the output using an RF spectrum analyzer. When the input signal was 80MHz -48dBm, the height of the peaks were;
     80MHz -8.8dBm
    160MHz -30dBm
    240MHz -42dBm
  Other peaks were smaller than the 3rd harmonics. Also, RF PD that detects beat note signal has a cut-off frequency at around 100MHz. So, we don't need to worry about wave transformation for this setup.

Quote:

ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!).
It seems to be overkill.
Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab.

And the description:
"RF amplifier ZHL-32A has around +28dBm gain at 80MHz"
The unit is wrong.

Yes. I corrected my previous elog.

  4562   Sun Apr 24 21:37:40 2011 kiwamuUpdateIOOreview of triple resonant EOM : model looks fine

To design a new resonant EOM box I started reviewing the prototype that I've built.

As a part of reviewing I checked an important thing that I haven't carefully done so far :

I compared the measured input impedance with that of predicted from a circuit model. I found that they show a good agreement.

So I am now confident that we can predict / design a new circuit performance.


* * * (input impedance) * * *

 Performance of a resonant circuit is close related to its input impedance and hence, in other words, determined by the input impedance.

Therefore an investigation of input impedance is a way to check the performance of a circuit. That's why I always use impedance for checking the circuit.

The plot below is a comparison of input impedance for the measured one and one predicted from a model. They show a good agreement.

(Note that the input impedance is supposed to have 50 Ohm peaks at 11, 29.5 and 55 MHz.)
Input_impedance.png

 
* * * (circuit model) * * *

To make the things simpler I assume the following three conditions in my model:

 1. inductor's loss is dominated by its DC resistance (DCR)

 2. capacitor's loss is characterized only by Q-value

 3. Transformer's loss is dominated by DCR and its leakage inductance

All the parameters are quoted from either datasheet or my measurement. The model I am using is depicted in the schematic below.

Basically the Q-vaules for the capacitors that I used are quite low. I think higher Q capacitors will improve the performance and bring them to more 50 Ohm.

EOMcircuitmodel.png
 

  1553   Thu May 7 10:28:20 2009 steveUpdateVACretrofitted maglev's needs

 

 Our spare Osaka maglev purchased in Oct 2005 turned out to be having a viton o-ring seal connection on the intake.

It was shipped back to San Jose for retrofitting it with 6" conflat flange ( CF ) This CF is using copper gasket so there will be no permeation of He when you leak check the IFO

 

The digital controller and cable are here. The controller needs to be interfaced with the interlocks and computer system; those have been in a neglected condition lately.

see elog #1505  Historically after every REBOOT of c1vac2 the readbacks works for 3-4 days only. Fixing of this was postponed many times in the past as low priority or lack of knowledgeable

enthusiast.

 

The maglev TG390MCAB wil be back on Tuesday, May 4, 2009.  The mourning of our fateful 360 will only end at the first levitation of the 390.

 

  474   Tue May 13 10:15:52 2008 steveUpdateSUSrestored damping of BS & PRM
I think our janitor was cleaning too heavy handedly.
The BS and PRM sus damping were lost.
They were restored.
  10035   Fri Jun 13 09:20:37 2014 SteveUpdateSUSrestored damping at PRM and ETMY

ETMX medm screen values are blank.

  1510   Thu Apr 23 16:35:23 2009 YoichiSummaryComputer Scripts / ProgramsrestoreWatchdog script
When the IFO loses lock during the lock acquisition steps, it often kicks the MC2 (through the CM servo) and trips the watchdog.
I wrote a script to restore the tripped watchdog (/cvs/cds/caltech/scripts/SUS/restoreWatchdog).
The script takes the name of a mirror (such as MC2) as an argument.
It will enable the coils and temporarily increase the watchdog threshold to a value higher than the current OSEM RMS signals.
Then it will bring the watchdog back to the normal state and wait for the mirror to be damped. After the mirror is damped enough, the
watchdog threshold will be restored to the original value.
The script will do nothing if the watchdog is not tripped.
I put this script in the drdown_bang so that the MC2 watchdog will be automatically restored when a lock loss kicks out the MC2.
  7378   Thu Sep 13 07:36:41 2012 SteveUpdateGeneralrestore conditions

Quote:

 Summary: Recorded the presence of higher order modes in IMC

What I did: Misaligned the flat mirror MC1 by small amount in both pitch and yaw (it was needed to be done cause at the beginning of the experiment no higher order modes were present)  and scanned the cavity for frequency-range 32MHz to 45MHz.

I found the presence of higher order modes around 36.7MHz (1st order)  and 40.6MHz (2nd order) along with two other strong modes near 35MHz and 42.5MHz.

 

 Please, restore condition after you finished and update elog right away! People wasted hours yesterday not knowing the condition of the MC

  727   Wed Jul 23 21:48:30 2008 robConfigurationGeneralrestore IFO when you're done with it

when you are done with the IFO, please click "Restore last auto-alignment" on the yellow IFO portion of the C1IFO_CONFIGURE.adl screen. Failure to comply will be interpreted as antagonism toward the lock acquisition effort and will be met with excoriation.
  11930   Wed Jan 13 18:36:00 2016 gautamUpdateLSCrestoration of green beat electronics

In preparation for tonight's work, I did the following:

On the PSL table:

  • Powered the RF amplifiers for the green beat signal on
  • Reconnected the outputs of the Green beat PDs to the RF amplifiers
  • Restored wiring in the fiber box such that both IR beats go to the frequency counter.

At the IOO Rack area:

  • Restored wiring to the frequency counter module such that the IR beats from both arms go to the respective channels
  • Partially cleaned up the setup used for measuring AUX laser frequency noise - moved the SR785 to the X end along with one SR560 so that we can measure the end PDH OLTF
  • Brought the HP network analyzer back to the control room so that we can view the green beatnotes.

At the X-end:

  • Turned the function generator used for PDH locking back on
  • Checked that the AUX laser diode current is 1.90 A, and the crystal temperature is ~47.5 degrees, both of which I think are "good" values from our AUX laser frequency noise measurements
  • Did some minor manual alignment of the PZT mirrors

At the Y-end:

  • Restored the BNC connection from the PDH box to the laser's "FAST" control input. The long BNC cable used for the PLL is still running along the Y-arm, I will clean this up later.

Having done all this, I checked the green transmission levels for both arms (PSL green shutter closed, after running ASS to maximize IR transmission). GTRY is close to what I remember (~0.40) while the best I could get GTRX to is ~0.12 (I seem to remember it being almost double this value - maybe the alignment onto the beat PD has to be improved?). Also, the amplitudes of the beatnotes on the network analyzer are ~-50dBm, and I seem to remember it being more like -25dBm, so maybe the alignment on the PD is the issue? I will investigate further in the evening. It remains to measure the OLTF of the X-end PDH as well.

  11838   Wed Dec 2 15:52:28 2015 yutaroUpdateLSCrestoration of POXDC

I disconnected the cable that was connected to CH6 of the whitening filter in 1Y2, then connected POXDC cable to there (CH6). This channel is where POXDC used to connect.

Then I turned on the whitening filter for POXDC and POYDC (C1:LSC-POXDC FM1, C1:LSC-POYDC FM1) and changed the gain of analog whitening filter for POXDC and POYDC from 0 dB to 45 dB and from 0 dB to 39 dB, respectively (C1:LSC-POXDC_WhiteGain, C1:LSC-POYDC_WhiteGain).

  6443   Mon Mar 26 12:50:24 2012 ZachUpdateelogrestarted with script

On the plus side, it was the first time I've had to do it in a while..

ELOG V3.1.3-