ID |
Date |
Author |
Type |
Category |
Subject |
7231
|
Sun Aug 19 19:56:20 2012 |
Yaakov | Update | STACIS | STACIS 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:
 
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.

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 |
rana | Update | STACIS | STACIS 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
|
|
34
|
Wed Oct 31 08:33:54 2007 |
rana | Problem Fixed | SUS | Vent 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 |
steve | Summary | SUS | vent 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
|
|
70
|
Tue Nov 6 15:37:34 2007 |
rob | Configuration | SUS | rampdown 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 |
rana | HowTo | SUS | MC 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 |
steve | Omnistructure | SUS | etmy 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
|
|
Attachment 2: etmyrmseq.jpg
|
|
133
|
Wed Nov 28 17:15:26 2007 |
rana | Configuration | SUS | ETMY 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 |
rana | Configuration | SUS | new 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 |
Andrey | Configuration | SUS | Suspension 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 |
rana | Update | SUS | ETMY 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
|
|
214
|
Wed Dec 26 15:12:48 2007 |
rana | Update | SUS | ETMY 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 |
rana | Update | SUS | ETMY 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
|
|
220
|
Thu Jan 3 08:53:55 2008 |
steve | Update | SUS | etmy 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
|
|
222
|
Thu Jan 3 09:55:11 2008 |
steve | Update | SUS | etmy sus damping restored |
ETMY watch dog was lost at midnight |
Attachment 1: etmy12h.jpg
|
|
225
|
Fri Jan 4 08:42:03 2008 |
steve | Update | SUS | etmy 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
|
|
Attachment 2: etmy120s.jpg
|
|
Attachment 3: etmysenV.jpg
|
|
226
|
Mon Jan 7 09:01:39 2008 |
steve | Update | SUS | BS sus damping restored |
The BS sus damping was lost at 8am Sunday morning. |
Attachment 1: bssdl.jpg
|
|
232
|
Thu Jan 10 10:38:02 2008 |
steve | Update | SUS | etmy 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
|
|
Attachment 2: sustrend16d.jpg
|
|
233
|
Thu Jan 10 12:08:23 2008 |
steve | Update | SUS | why did the BS move? |
|
Attachment 1: bshopped.jpg
|
|
235
|
Thu Jan 10 15:04:04 2008 |
steve | Update | SUS | illuminator 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
|
|
237
|
Mon Jan 14 14:41:09 2008 |
steve | Update | SUS | etmy 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
|
|
242
|
Wed Jan 16 18:24:41 2008 |
rana | Update | SUS | ETMY 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
|
|
256
|
Wed Jan 23 12:31:36 2008 |
Andrey | Summary | SUS | Dissapointing 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
|
|
260
|
Thu Jan 24 20:03:40 2008 |
Andrey | Configuration | SUS | Changes 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 |
rob | Configuration | SUS | Changes 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 |
Andrey | Update | SUS | New 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
|
|
Attachment 2: Accel-Seismic_10AM.pdf
|
|
305
|
Sat Feb 9 13:32:07 2008 |
John | Summary | SUS | All 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 |
Alan | Summary | SUS | All 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 |
Andrey | Update | SUS | Earthquake 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 |
Andrey | HowTo | SUS | Modification 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 |
alex | Update | SUS | end 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 |
rob | Update | SUS | end 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 |
rana | Summary | SUS | MC1 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
|
|
435
|
Tue Apr 22 10:59:24 2008 |
rob | Update | SUS | MC1 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 |
rob | Update | SUS | end 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 |
steve | Update | SUS | earthquake 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 |
steve | Update | SUS | ETMY 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 |
steve | Update | SUS | restored 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 |
rana | Summary | SUS | Optical 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
|
|
487
|
Mon May 19 11:49:57 2008 |
steve | Update | SUS | etmy 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 |
rana | Update | SUS | ETMY 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 |
steve | Update | SUS | etmy 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
|
|
Attachment 2: P1020420.png
|
|
507
|
Fri May 30 12:37:45 2008 |
rob | Update | SUS | etmy 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 |
Jonh | Summary | SUS | ETMY watchdog |
ETMY watchdog was tripped. I turned it off and re-enabled the outputs. |
676
|
Tue Jul 15 19:15:57 2008 |
rana | Summary | SUS | ETMX 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
|
|
755
|
Tue Jul 29 13:54:08 2008 |
rana | Update | SUS | ETMY 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
|
|
756
|
Tue Jul 29 14:38:02 2008 |
rob | Update | SUS | ETMY 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 |
Koji | Update | SUS | PRM 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
|
|
Attachment 2: PRM_from_South_Window2.jpg
|
|
762
|
Wed Jul 30 00:42:04 2008 |
rana | Update | SUS | Trends 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
|
|
763
|
Wed Jul 30 01:08:50 2008 |
rana | Summary | SUS | SUS 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
|
|