40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 295 of 355  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  7231   Sun Aug 19 19:56:20 2012 YaakovUpdateSTACISSTACIS signal box made

I made the signal box as described in eLog 7210. It adds the geophone signal and an external signal.

It has six switches, for x, y, and z signals from both an external and local (geophone) source. The x signals add if both x switches are flipped down (and the same for the other directions). For example, if you want to feed in only an external signal in the x direction, flip down the external x direction switch (it's labeled on the box), leaving all others flipped up.

The x, y, and z outputs are wired to the pins from the preamplifier that go to the high voltage board. These I disconnected from the preamplifier by cutting at their base (there are spare connectors if this wants to be undone, or, a wire can just be soldered from the pin to its old spot on the board). The power (plus/minus) and ground are wired to the respective pins from the geophone preamplifier (naturally, the STACIS must be turned on for the box to work since the box shares its power source). Below, the front (switches and geophone/external inputs) and back (power, ground, outputs) of the box are shown:

SAM_0276.JPGSAM_0277.JPG

The preamplifier can plug into its regular connectors- the x,y,and z signals will all be redirected to the signal box with these modifications. The box sits outside the STACIS, there is room to feed the wires out from underneath the STACIS platform.

SAM_0275.JPG

NOTE: The geophone z switch is a little different than the others, just make sure it's flipped all the way down if you want that signal to be seen in the z output.

 

  7258   Thu Aug 23 15:42:48 2012 ranaUpdateSTACISSTACIS signal box made

 

 I found this entry in the old 40m ilog which describes the STACIS performance. It shows that even though the STACIS is bad for the differential arm motion below 3 Hz. It has quite a big and positive effect at 10-30 Hz. The OSEMs show a bigger effect than what the single arm does. I think this is because the single arm is limited by the MC frequency noise above 10 Hz.

We should figure out how to turn on the STACIS but set the lower UGF to be ~5 Hz.

Attachment 1: vsanni-1107222997.pdf
vsanni-1107222997.pdf
  34   Wed Oct 31 08:33:54 2007 ranaProblem FixedSUSVent measurements
There was a power outage during the day yesterday; whoever was around should post something here about the
exact times. Andrey and David and Tobin got the computers back up - there were some hiccups which you can
read about in David's forthcoming elog entry.

We restarted a few of the locking scripts on op340m: FSSSlowServo, MCautolocker. Along with the updates
to the cold restart procedures we have to put an entry in there for op340m and a list of what scripts
to restart.

David tuned up the FSS Slow PID parameters a little; he and Andrey will log some entry about the proper
PID recipe very soon. We tested the new settings and the step response looks good.

We got the MC locking with no fuss. The 5.6 EQ in San Francisco tripped all of the watchdogs and I upped
the trip levels to keep them OK. We should hound Rob relentlessly to put the watchdog rampdown.pl into
the crontab for op340m.
  66   Tue Nov 6 09:45:22 2007 steveSummarySUSvent sus trend
The mc optics dragwippings were done by locking optics by eq stops and rotating-moving
cages so access were good. This technic worked well with mc1 & mc2
MC3 osems were reoriented only.
Attachment 1: ventsustrend.jpg
ventsustrend.jpg
  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.
  91   Sun Nov 11 21:05:55 2007 ranaHowToSUSMC Touching or not
I wrote a script: SUS/freeswing-mc.csh, which gives the MC mirrors the appropriate kicks
needed to make a measurement of the free swinging peaks in the way that Sonia did.
#!/bin/csh

set ifo = C1
set sus = ${ifo}:SUS-

foreach opt (MC1 MC2 MC3)

  set c = `ezcaread -n ${sus}${opt}_PD_MAX_VAR`
  ezcastep ${sus}${opt}_PD_MAX_VAR +300

  ezcaswitch ${sus}${opt}_ULCOIL OFFSET ON
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_LATCH_OFF 0

  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  ezcaswitch ${sus}${opt}_ULCOIL OFFSET OFF

  ezcawrite ${sus}${opt}_PD_MAX_VAR $c

end

echo
date
echo

It basically ups the watchdog threshold, wacks it around at the pendulum frequency, and then disables the
optic so that there are no electronic forces applied to it besides the bias. The date command at the end
is so that you know when to start your DTT or mDV or lalapps code or whatever.
  122   Mon Nov 26 10:17:31 2007 steveOmnistructureSUSetmy sus damping restored
20 days plot is showing etmy loosing damping 4 times.
I zoomed in with each event. Three of them could of been triggered
by garbage loading just outside. However attachment 2 plot demonstrating that small earthquake or seismic event
did not tripped etmy damping.
The fourth event was preceded by a 4-5 hrs of continous rise of the rms motion at C1:SUS-ETMY_LLPD_VAR
Attachment 1: etmyrms20d.jpg
etmyrms20d.jpg
Attachment 2: etmyrmseq.jpg
etmyrmseq.jpg
  133   Wed Nov 28 17:15:26 2007 ranaConfigurationSUSETMY damping / watchdogs
Steve has noted that ETMY was often tripping its watchdog. I saw this again today.

So I checked the damping settings. Someone had set the SIDE gain to +1. The gain which gives
it a Q of ~10 is +10. I set the SIDE gain to +20. I checked and the ETMX gain is -16 so now
they're at least similar. I have updated the snapshot to reflect the new value.

Hopefully now it will be more well behaved.
  148   Fri Nov 30 19:29:14 2007 ranaConfigurationSUSnew screen
Andrey is working on a new screen to show us the drift of the optics by alarming on
their osem values. You can find it under SUS as 'Drift Mon' from the site map.

To aid in this I ran the following csh commands which effect all optics:
foreach opt (ETMX ETMY ITMX ITMY MC1 MC2 MC3 BS PRM SRM)
  foreach dof (POS PIT YAW)
     ezcawrite C1:SUS-${opt}_SUS${dof}_INMON.PREC 0
  end
end

This should make the DOF readouts more readable.
  176   Thu Dec 6 19:19:47 2007 AndreyConfigurationSUSSuspension damping Gain was restored

Suspension damping gain was disabled for some reason (all the indicators in the most right part of the screen C1SUS_ETMX.adl were red), it is now restored.
  213   Wed Dec 26 15:00:06 2007 ranaUpdateSUSETMY tripping
Steve mentioned to me that ETMY is still tripping more than ETMX. The attached DV plot
shows the trend of the watchdog sensors; essentially the RMS fluctuations of the shadow
sensors. (note** DV can make PNG format plots directly which are much better than JPG
when making plots and much smaller than PS or PDF when plotting lots of points).
Attachment 1: etm.png
etm.png
  214   Wed Dec 26 15:12:48 2007 ranaUpdateSUSETMY tripping
It turned out that the ETMY POS damping gain was set to 1.0 while the ETMX had 3.8.

I put both ETMs to a POS gain of 4 and then also set the PIT, YAW and SIDE gains for
ETMY. Let's see if its more stable now.

In the next week or so Andrey should have perfected his damping gain setting technique
and the numbers should be set more scientifically.
  216   Thu Dec 27 13:08:04 2007 ranaUpdateSUSETMY tripping
Here's a trend from the last 2 days of ETMX and ETMY. You can see that the damping gain increase
has made them now act much more alike. Problem fixed.
Attachment 1: Untitled.png
Untitled.png
  220   Thu Jan 3 08:53:55 2008 steveUpdateSUSetmy vs etmx
Rana have corrected sus gain damping setting of ETMY 8 days ago

gain settings: pos, pit, yaw & sd
etmx: 4,2,2,& -16
etmy: 4,2,2,& 50
Attachment 1: sus.jpg
sus.jpg
  222   Thu Jan 3 09:55:11 2008 steveUpdateSUSetmy sus damping restored
ETMY watch dog was lost at midnight
Attachment 1: etmy12h.jpg
etmy12h.jpg
  225   Fri Jan 4 08:42:03 2008 steveUpdateSUSetmy trips again
ETMY sus damping tripped at 6am this morning
It was reset. We should put an accelerometer to the south end to see
the garbage dumping effect.
Attachment 1: etmy20m.jpg
etmy20m.jpg
Attachment 2: etmy120s.jpg
etmy120s.jpg
Attachment 3: etmysenV.jpg
etmysenV.jpg
  226   Mon Jan 7 09:01:39 2008 steveUpdateSUSBS sus damping restored
The BS sus damping was lost at 8am Sunday morning.
Attachment 1: bssdl.jpg
bssdl.jpg
  232   Thu Jan 10 10:38:02 2008 steveUpdateSUSetmy damping restored
The IST building onstruction has really started yesterday and continuing today with big heavy ground breaking
machinary. The MC is holding lock and the suspentions are hanging on.

ETMY does not like this.

SUS-MC2_LLPD_VAR monitor is a good indicator of seismic activity on this 12 days plot
Attachment 1: etmysus.jpg
etmysus.jpg
Attachment 2: sustrend16d.jpg
sustrend16d.jpg
  233   Thu Jan 10 12:08:23 2008 steveUpdateSUSwhy did the BS move?
Attachment 1: bshopped.jpg
bshopped.jpg
  235   Thu Jan 10 15:04:04 2008 steveUpdateSUSilluminator light effect on BS position
The bs chamber illuminator light was turned on this morning and left on.
Earlier on Rana noticed that the bs moved.
I follwed up to see what happened. I turned off oplev servo and tried to recenter on oplev pd
by adjusting pitch and yaw biases. It did not move. I looked at suspention and realized that the
illuminator was still on. I turned it off and to my amazement the the AP spot started flashing
Attachment 1: bssusilum.jpg
bssusilum.jpg
  237   Mon Jan 14 14:41:09 2008 steveUpdateSUSetmy sus damping restored & mz relocked
Tree days trend of MZ HV drift is typical these days.
So as the etmy sus inability to hold damping for longer then 2-3 days.
Attachment 1: etmysus&mzhvtrend.jpg
etmysus&mzhvtrend.jpg
  242   Wed Jan 16 18:24:41 2008 ranaUpdateSUSETMY Watchdog
Because Steve keeps complaining about ETMY, I looked at some minute trend to see if there was something exotic happening at that time. It looks like there is some tremendous seismic activity to make it happen.

The trend shows that there is nothing special happening on the ETMX accelerometer or the ETMX suspension. At the same time, however, there is a huge jump in the ETMY sensors and therefore the watchdog signal. Whenever the watchdog value goes above 140, it trips.

After Andrey moves some accelerometers over to the Y end we can see the effect more directly.
Attachment 1: A.pdf
A.pdf
  256   Wed Jan 23 12:31:36 2008 AndreySummarySUSDissapointing Results of XARM optimization (PDF-file)

I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain,

and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)),
but now those dependences are plotted in Q-ITMX and Q_ETMX axes.

Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry).

The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting.
Attachment 1: Sad_Results_XARM.pdf
Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf Sad_Results_XARM.pdf
  260   Thu Jan 24 20:03:40 2008 AndreyConfigurationSUSChanges to Dataviewer channels (XARM)

1) Good news. I added a chanel "C1:SUS-ETMX_POS" to Dataviewer.

I followed the instructions from WIKI-40:

modify the file "C1SUS_EX.ini" in /cvs/cds/caltech/chans/daq,
then telnet to fb40m,
then "click the appropriate blue button on the DAQ MEDM screen".

So, I can now read a signal from the channel "C1:SUS-ETMX_POS" in Dataviewer,

and this allows me to measure Q-factors of ETMX this evening (make similar work for what I did on Tuesday for ITMX).


2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

Again, I apologize and hope that the problem is not very serious.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.


I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  286   Wed Jan 30 13:09:55 2008 AndreyUpdateSUSNew results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!
Attachment 1: New_Results_XARM.pdf
New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf New_Results_XARM.pdf
Attachment 2: Accel-Seismic_10AM.pdf
Accel-Seismic_10AM.pdf
  305   Sat Feb 9 13:32:07 2008 JohnSummarySUSAll watchdogs tripped
When I arrived this afternoon the watchdogs had tripped on all optics. I reset them and enabled the coil currents.

I had to adjust the alignment of the mode cleaner to get it to lock.
  306   Sun Feb 10 20:47:01 2008 AlanSummarySUSAll watchdogs tripped
A moderate earthquake occurred at 11:12:06 PM (PST) on Friday, February 8, 2008.
The magnitude 5.1 event occurred 21 km (13 miles) NW of Guadalupe Victoria, Baja California, Mexico.
http://quake.wr.usgs.gov/recenteqs/Quakes/ci14346868.html
  323   Tue Feb 19 15:21:47 2008 AndreyUpdateSUSEarthquake tripped watchdogs in ETMY, ITMY

According to the web-page http://earthquake.usgs.gov/eqcenter/recenteqsus/Quakes/ci14351140.php ,

there was a 5.0 earthquake in northern Baja California in Mexico at 02.41PM earlier today.

This earthquake made an effect on our watchdogs for ETMY and ITMY (their currents exceeded maximal values).
Watchdogs for ITMY are now restored back,
and it is taking more time for a "side degree" for ETMY to calm down,
it is still (40 minutes after the kick) swinging a lot with amplitude ~ 200mV.
  404   Wed Mar 26 13:41:53 2008 AndreyHowToSUSModification of ''C1DRIFT_MONITOR''
I learned how to modify the drift-monitor in MEDM so that values on it change colors from green to yellow to red depending how much is the fluctuatioin (deviation) of the value from its mean nominal value.

In order to do this, I used the following eight commands:

tdswrite CHANNEL_NAME.HIHI VALUE
tdswrite CHANNEL_NAME.HIGH VALUE
tdswrite CHANNEL_NAME.LOW VALUE
tdswrite CHANNEL_NAME.LOLO VALUE
tdswrite CHANNEL_NAME.HHSV 2
tdswrite CHANNEL_NAME HSV 1
tdswrite CHANNEL_NAME LSV 1
tdswrite CHANNEL_NAME LLSV 2

where CHANNEL_MAME is the name of the channel the value of which is indicated on the MEDM screen C1DRIFT_MONITOR, for example
C1:SUS-MC1_SUSPOS_INMON, and VALUE is numerical value that I assigned to the channel parameters.

By now I modified nine mode-cleaner channels (POS, PITCH and YAW channels for MC1, MC2 and MC3) and 6 channels for ITMX and ITMY.

Note that as we have problems this week with computer C1SUSVM, namely ''c1susvme2'' is not working, indicators for MC2 in the drift-monitor do not change colors today although they should.

In order to judge which values should be established as reasonable deviations from the average nominal values, I was looking into Dataviewer trends for the channels that are in the drift-monitor.


In the future indicators for channels ETMX and ETMY, BS, PRM, SRM should be modified in complete analogy with what I did already for MC and for ITM. So, I have modified 3*5 = 15 channels, and 3*5 = 15 channels are left for the future.

Note that (as far as I understand) instead of commands "tdswrite" it is absolutely legitimate to use commands "ezcawrite".
  425   Fri Apr 18 16:02:58 2008 alexUpdateSUSend station sus front-end bug fix
installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.
  426   Fri Apr 18 16:27:04 2008 robUpdateSUSend station sus front-end bug fix

Quote:
installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.


But where is the code?
  431   Sun Apr 20 23:39:57 2008 ranaSummarySUSMC1 electronics busted
I spent some time trying to fix the utter programming fiasco which was our MCWFS diagonalization script.

However, it still didn't work. Loops unstable. Using the matrix in the screen snapshot is OK, however.

Finally, I realized from looking at the imaginary part of the output matrix that there was something
wrong with the MC1 drive. The attached JPG shows TFs from pit-drives of the MC mirrors to WFS1.

MC1 & MC3 are supposed to have 28 elliptic low pass filters in hardware for dewhitening. The MC2
hardware is different and so we have given it a software 28 Hz ELP to compensate. But it looks like
MC1 doesn't have the low pass (no phase lag). I tried switching its COIL FM10 filters to make it
switch but no luck.

We'll have to engage the filters to make the McWFS work right and to get the MC noise down. This
needs someone to go check out the hardware I think.

I have turned the gain way down and this has stabilized the MC REFL signal as you can see from the StripTool screen.
Attachment 1: mcwfs.jpg
mcwfs.jpg
  435   Tue Apr 22 10:59:24 2008 robUpdateSUSMC1 electronics busted

Quote:
I spent some time trying to fix the utter programming fiasco which was our MCWFS diagonalization script.

However, it still didn't work. Loops unstable. Using the matrix in the screen snapshot is OK, however.

Finally, I realized from looking at the imaginary part of the output matrix that there was something
wrong with the MC1 drive. The attached JPG shows TFs from pit-drives of the MC mirrors to WFS1.

MC1 & MC3 are supposed to have 28 elliptic low pass filters in hardware for dewhitening. The MC2
hardware is different and so we have given it a software 28 Hz ELP to compensate. But it looks like
MC1 doesn't have the low pass (no phase lag). I tried switching its COIL FM10 filters to make it
switch but no luck.

We'll have to engage the filters to make the McWFS work right and to get the MC noise down. This
needs someone to go check out the hardware I think.

I have turned the gain way down and this has stabilized the MC REFL signal as you can see from the StripTool screen.


This was just because the XYCOM was set to switch the "dewhites" based on FM9 rather than FM10. To check whether the hardware ellipDW filters were engaged, I drove MC1 & MC3 in position (using the MCL bank), and looked at the transfer functions MC2_MCL/MC1_MCL and MC2_MCL/MC3_MCL. This method uses the mode cleaner length servo to enable a relatively clear transfer function measurement of the ellipDW, modulo the loop gain of MCL and the fact that it's really hard to measure an ELP cascaded with a suspension. The hardware and the switching appear to be working fine.

It's now set up such that the hardware is ENGAGED when the coil FM10 filters are OFF, and I deleted all the FM10 filters from the coils of MC1 and MC3. Since we don't switch these filters on and off regularly, I see no need to waste precious SUS processor power on filters that just calculate "1".
  436   Tue Apr 22 16:17:48 2008 robUpdateSUSend station sus front-end bug fix

Quote:
installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.


What Alex means is that the EPICS values for the ETMY optical levers were being clobbered in the RFM. The calculations were being done correctly in the FE, so the DAQ/testpoints were working--it was just the EPICS/RFM communication via c1losepics that was bugged. This was a result of the recent SUS code changes to accept inputs from the ASS for adaptive feedforward.
  462   Thu May 1 08:31:51 2008 steveUpdateSUSearthquake trips etmy & mc1
Earthquake at Lake Isabel magnitude 4.4 at 1am today shakes the 40m
ETMY and MC1 watchdogs tripped.
Sus damping restored.
  472   Fri May 9 08:40:24 2008 steveUpdateSUSETMY sus damping restored
ETMY lost damping at 19:10 last night.
There was no seismic event than.
Sus damping was restored this morning.
  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.
  485   Sun May 18 18:44:48 2008 ranaSummarySUSOptical Lever SUM Trend - 80 days
I used the OL-Trend.xml dataviewer template to make this plot. Looks like the ETMY optical lever
slowly degraded over the last few months and then finally died 10 days ago. Would someone please
replace this laser and tune the lens position to minimize the spot size on the quad?
Attachment 1: e.pdf
e.pdf
  487   Mon May 19 11:49:57 2008 steveUpdateSUSetmy oplev laser replaced
The 9 years old Uniphase HeNe was replaced by a new JDSU 1103P
Power output ~3.5 mW, reflected light back on qpd ~140 microW, 12,800 counts
Andrey will get the ~2.5 mm od spot on the qpd smaller by replacing
the f1000 lens
  499   Sun May 25 22:33:00 2008 ranaUpdateSUSETMY Oplev Work
I found the ETMY table in disarray and put the panels back on and put the ETMY OL laser back on the quad.

The next thing to do is clean up the table (there's a lot of junk on it) and then put in a lens within
6" of the laser to focus the beam on the quad (no metal diving boards and the lens should be either
uncoated (from our Edmunds collection) or a red lens, not 1064).

Then we have to put the beam cover back on between the viewport and the table.
  504   Thu May 29 16:32:09 2008 steveUpdateSUSetmy oplev is back
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd
Attachment 1: P1020417.png
P1020417.png
Attachment 2: P1020420.png
P1020420.png
  507   Fri May 30 12:37:45 2008 robUpdateSUSetmy oplev is back

Quote:
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd


I turned on the servo. UGFs in PIT and YAW are ~3Hz. I had to flip the sign of the YAW.
  629   Thu Jul 3 12:36:05 2008 JonhSummarySUSETMY watchdog
ETMY watchdog was tripped. I turned it off and re-enabled the outputs.
  676   Tue Jul 15 19:15:57 2008 ranaSummarySUSETMX Dewhitening characterization
Since the boys found that the ETM dewhitening transient was kicking the IFO out of lock we
decided to investigate.

First, we wrote a script to diagnose and then tune the DC gain of the dewhitening filters'
digital compensation filter (a.k.a. FM9 or SimDW). It is in the scripts/SUS/ directory
and is called dwgaintuner. It puts in an offset on each coil's DAC channel and
then reads back the Vmon on the coil driver with the DWF on and off. It reports the ratio of these
voltages which you can then type into the FM9/SimDW filter's gain field. We learned that the
difference between the analog DWF path and the bypass path was ~3% (which is consistent with
what you expect from the use of 1% resistors). We need to repeat this for all of the rest of
the suspended optics except for MC1 and MC3.

This Vmon method is better than what's used at the sites so we will export this new technology.

The attached plot shows some switching transients with only the local damping on:
BLUE:   Output of filter bank during an FM9 turn off. This is the transient which goes to the DAC.
        The transients are mostly of the same magnitude as this.
RED:    This is the input of the filter module during another such transient.
GREEN:  Tried another switch; this time I filtered the time series in DTT by typing the SimDW into
        the Triggered Time Series filter field. This should be simulating what comes out of the
        output of the DW board - to convert to volts multiply by 15/32768.
PURPLE: Same kind of filtering as the GREEN, but with also a double 30 Hz highpass to remove the low
        frequency damping control signals. You can see that the total transient is only ~5 counts
        or ~1 mV at the coil driver output. This is comparable to the relative offset in the bypass
        and filter paths.
Attachment 1: etmx-dw-transient.pdf
etmx-dw-transient.pdf
  755   Tue Jul 29 13:54:08 2008 ranaUpdateSUSETMY and PRM have EQ related problems
The attached trend shows that ETMY and PRM both had large steps in their sensors
around the time of the EQ and didn't return afterwards. The calibration of the
OSEM sensors is ~0.5 mm/V. The PRM sensors respond when we give it huge biases
but there is very little change in the ETMY. Almost certainly true that the
optics have shifted in their wire slings and that we will have to vent to
examine and repair at least ETMY.

Jenne is looking at the spectra of the other suspensions to see if there is
other more subtle issues.
Attachment 1: Untitled.png
Untitled.png
  756   Tue Jul 29 14:38:02 2008 robUpdateSUSETMY and PRM have EQ related problems

Quote:
The attached trend shows that ETMY and PRM both had large steps in their sensors
around the time of the EQ and didn't return afterwards. The calibration of the
OSEM sensors is ~0.5 mm/V. The PRM sensors respond when we give it huge biases
but there is very little change in the ETMY. Almost certainly true that the
optics have shifted in their wire slings and that we will have to vent to
examine and repair at least ETMY.

Jenne is looking at the spectra of the other suspensions to see if there is
other more subtle issues.


Some additional notes/update:

ETMY, PRM, & MC2 had OSEM signals at a rail (indicating stuck optics). Driving the optics with full scale DAC output freed ETMY and MC2, so while these may have shifted in their slings it may be possible to avoid a repair vent. PRM is still stuck. One OSEM appears to respond with full range to large drives, but the other three face OSEMS remain disturbingly near the rail (HIGH, which is what would happen if a magnet fell off).
  759   Tue Jul 29 19:53:19 2008 KojiUpdateSUSPRM photos from the south window
Steve and Koji

We took some photos of PRM from the south window.
You can see one of the side magnets, a wire stand-off, and the wire itself from the round hole.
So, the wire looks OK.

For the coils, we could see only one coil. The magnet is apparently too high.
Attachment 1: PRM_from_South_Window1.jpg
PRM_from_South_Window1.jpg
Attachment 2: PRM_from_South_Window2.jpg
PRM_from_South_Window2.jpg
  762   Wed Jul 30 00:42:04 2008 ranaUpdateSUSTrends and file formats
I propose that we do not use .eps format but .pdf instead. For images like the plots Sharon
has below we should use only .png and for pictures like what Steve posted, use JPG or PNG.

PDF is a standard and light weight. PNG is very good for plots/lines and is lossless. JPG does
a good job with regular camera pictures because we don't really care about the compression
loss on those.

Here's a trend of the UL sensors for all the optics - conversion is 32768 cts / mm. You can see
that the quake was just before 19:00 UTC (noon our time). The events an hour after are when
Rob, Jenne, and I start exciting the optics to shake them loose - wanging the pit/yaw sliders
around is not violent enough and so I injected a 130000 count sine wave at 0.5 Hz so as to
create a high force square wave. This seems to have worked for ETMY but no such luck yet with
the others.
Attachment 1: Untitled.png
Untitled.png
  763   Wed Jul 30 01:08:50 2008 ranaSummarySUSSUS Drift Screen
This is a snap of the SUS Drift screen with all of the optics biases set back to their nominal
values except for the MC which Rob aligned and I didn't feel like mis-aligning. The reference
on the screen is from 3/25 when Andrey felt that Rob had a good IFO alignment.

Anything more than a few thousand is significant and more than 10k means something is wrong:



I wailed on the PRM for awhile and was able to loosen it up a little. The LL & LR sensors now
show some life one the dataviewer. The UL & UR are still railed ~1.6 V so that means that the
optic is pitched back. With aggressive pitch wailing I can see the PRM's ULR/UR sensors go
rail to rail so that means that the magnets are still on - although they may be half busted.
If they're OK we should be able to just re-sling this guy.


Did the same on SRM. The OSEM values have shifted on these, but not disastorously. The SIDE,
however, is completely unresponsive. The little signal I see when driving is is probably just
capacitive pickup in the cables. Have to vent to fix this one.


ITMX Has good life in all but the LR & UR channels. They respond, but the signal is very weak.
Seems like these magnets have not fallen off but that they are not between the LED/PD anymore.


ITMY seems ok. Check the spectra to be sure.


BS seems ok as well. Swings freely and no kinks in the swinging sensor waveforms. Check the spectra.
Attachment 1: infection-2.png
infection-2.png
ELOG V3.1.3-