40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 294 of 335  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  8182   Wed Feb 27 11:59:43 2013 yutaUpdateSUSPRM/BS coil re-balanced

I re-adjusted coil gains and f2a filters for PRM and BS.
I'm not sure what happened to PRM since I balanced on Feb 16(elog #8093).
Let's see if it helps PRMI locking or not.


========== PRM ==========

- Original DC coil gains

C1:SUS-PRM_ULCOIL_GAIN 1.049901772380000e+00
C1:SUS-PRM_URCOIL_GAIN -9.833961907160000e-01
C1:SUS-PRM_LRCOIL_GAIN 9.543042546630000e-01
C1:SUS-PRM_LLCOIL_GAIN -9.713568522590000e-01

- New DC coil gains


multiplier factors are :
UL = 0.928167
UR = 1.061448
LR = 0.941659
LL = 1.068726
Set C1:SUS-PRM_ULCOIL_GAIN to 0.974482231437
Set C1:SUS-PRM_URCOIL_GAIN to -1.04382410014
Set C1:SUS-PRM_LRCOIL_GAIN to 0.898628670041
Set C1:SUS-PRM_LLCOIL_GAIN to -1.03811466772

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.023968
P2Y(POS=>YAW) = 0.007075

PRM_f2a20130227.png



========== BS ==========

- Original DC coil gains

C1:SUS-BS_ULCOIL_GAIN 1.037692431800000e+00
C1:SUS-BS_URCOIL_GAIN -1.016268296990000e+00
C1:SUS-BS_LRCOIL_GAIN 9.660800075010000e-01
C1:SUS-BS_LLCOIL_GAIN -9.791833500410000e-01

- New DC coil gains


multiplier factors are :
UL = 1.017855
UR = 1.023207
LR = 0.956184
LL = 1.002755
Set C1:SUS-BS_ULCOIL_GAIN to 1.0562177496
Set C1:SUS-BS_URCOIL_GAIN to -1.03985422464
Set C1:SUS-BS_LRCOIL_GAIN to 0.923750146975
Set C1:SUS-BS_LLCOIL_GAIN to -0.981880297098

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.038251
P2Y(POS=>YAW) = -0.014677

BS_f2a20130227.png

  8193   Wed Feb 27 22:28:53 2013 BrettUpdateSUSGlobal Damping Update

 New excitation points were added after the global damping loops for more testing options. The updated c1sus.mdl model was re-committed to the svn. Two interesting simulink 'requirements' were found during this minor modification. First, excitation points must be placed on the top level of the diagram. If they are in a subsystem you will get compiling errors. Second, the excitation name must end in _EXC. It will compile OK if you don't do this, but the excitation points will not put out any excitations.

To do further investigation on the mysterious gain factor of 2.5 between the ETMY and ITMY POS damping loops, I measured TFs in the POS direction to the locked YARM signal for each. This provides an additional sensor, common to both, so we can see if the gain is coming from the actuation side or sensing side of the damping loops. The difference in these TFs is about 

2.895

So it seems the majority of the damping gain difference is on the actuation side with some small difference on the sensing side. In order to allow for the later splitting of YARM LSC control between ITMY and ETMY (global damping and the cavity control must be along the same coordinate system), I placed this gain of 2.95 in ITMY_LSC.

To get a first measure of the relative performance of global damping to local damping I measured some TFs between the sensor signal inputs and YARM. So first, while the cavity was still locked with just ETMY, I measured a TF between C1:SUS-ITMY_SUSPOS_EXC and C1:LSC-YARM_IN1. Second, I split the cavity control evenly between the ETMY and ITMY by adjusting C1:LSC-OUTPUT_MTRX. I turned off the local damping and turned on the common DOF global damping (called CARM at this point despite being on just one arm). I then repeated the same TF but driving from C1:SUS-GLOBAL_CARMDAMP_EXC.

The resulting TFs are displayed in the attached figure. The blue curve is then the TF from local damping sensor noise to YARM. The green is global damping sensor noise to YARM. The suppression between local to global is in red. The global damping curve is about 50 to 100 times lower (better) than local damping. This can probably be improved with further tuning to account for remaining differences between the ITMY and ETMY.

Note, the damping loop used in the filter modules for all of these is zpk(0,[15 15],1), with a gain of 30. This purposely has little high frequency filtering so it is easier to see the influence on YARM.

Attachment 1: DampNoise_to_YARM_fig_27Feb2013.png
DampNoise_to_YARM_fig_27Feb2013.png
  8207   Fri Mar 1 16:37:45 2013 BrettUpdateSUSGlobal Damping Update

Brett and Kamal

The global damping testing for the week is now complete. The c1sus.mdl simulink diagram settled on the attached screenshot. The top level of c1sus.mdl is shown on the left zoomed in over the new global damping block. The right shows the inside of that block. Also attached in the second screenshot are two of the modal damping MEDM screens. The left shows the main overview screen, the right shows the global damping filters. The overview screen is called C1SUS_GLOBAL.adl and is found in ...medm/c1sus/master/.

We have measured transfer functions and power spectra that show that global damping, with just a moderate amount of tuning (30 minutes of work) reduces the OSEM damping noise seen by YARM_IN1 by a factor between 50 and 80. Log 8193 highlights the transfer function measurements. The power spectra directly measure the noise in the cavity. I am not putting that data here because I have to catch. I will process the data and post it here later.

Overall the global damping tests appear to have been successful, isolating (not removing) the test mass damping noise from the cavity by almost 2 orders of magnitude. Presumably even more isolation is possible with more tuning.

Attachment 1: GlobalDamp_Simulink.png
GlobalDamp_Simulink.png
Attachment 2: GlobalDampScreens.png
GlobalDampScreens.png
  8220   Mon Mar 4 16:26:45 2013 BrettUpdateSUSGlobal Damping Noise Measurement

Here is an amplitude spectrum plot of y-arm cavity noise with a 50 Hz cutoff damping filter of the form zpk(0,[50;50],1). The low passing of this filter was intentionally extremely poor in order to see the damping noise in the cavity. The blue trace is the noise with no damping, which may be considered the 'best case' scenario from a noise point of view. The green has regular local damping on the ITMY. The ETMY has no damping for this measurement because the cavity control feedback to the ETMY takes care of its control when the cavity is locked. Notice the the large increase in noise from 40 Hz to 250 Hz, up to 1 order of magnitude. This noise is from the OSEM sensors passing through the damping loops. The red curve shows the y-arm noise with the exact same damping, except it is now applied in the global scheme. In this case, the damping noise falls completely below the baseline level of the cavity and becomes indistinguishable from the 'no damping' case.

If the damping injected enough noise I'd expect we would see a drop of 50 to 80 times switching from local to global. That is, the same factor measured in the transfer functions listed in log entry 8193.  However, the damping noise is only at most 1 order of magnitude above the baseline in this measurement. We would have to increase the damping noise by about another order of magnitude before we could expect to see the global damping noise in the cavity measurement.

The units of the cavity displacement in the plot were calculated using the 1.4e12 counts per meter calibration in log 6834. The measured UGF of the LSC loop at the time was 205 Hz. The peak in the plot above 200 Hz appears to be from this unity crossing. Moving the UGF also moves this peak.

Moral of the story: global damping can isolate the damping noise pretty well from the cavity signal.

Attachment 1: YARM_Noise.png
YARM_Noise.png
  8221   Mon Mar 4 16:46:31 2013 yutaUpdateSUSoplev calibration for PRM

[Manasa, Sendhil, Yuta]

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad


We needed these values for g-factor measurement of PRC using angle dithering method.

What we did:
  1. Adjusted QPD offsets (C1:SUS-PRM_OL[1-4]_OFFSET) by zeroing the output when turned oplev laser was turned off.
  2. Centered PRM oplev beam on QPD using steering mirror.
  3. Mounted PRM oplev QPD on a xy-stage and centered the beam on QPD.
  4. Moved QPD in x and y using micrometers and measured dependance of C1:SUS-PRM_OL(PIT|YAW)_IN1 on QPD displacement.
  5. Measured the path length of PRM oplev returning beam. We get the in-vac path length using optical layout CAD. We measured out of vac path using scale and tape measure.
  6. Dismounted PRM QPD from the stage and put it back to the original position.

Result:
  1. Figures below are OLPIT/OLYAW dependance on micrometer displacement moved in x and y. Error bars are measured fluctuation in the signal.


moved in x:PRM_PIT.png       moved in y:PRM_YAW.png


  2. We fitted the result by error function to get slope at zero crossing point. We also linear-fitted the other degree of freedom to get cross coupling between x and y. Slopes we get were;

micrometer    OLPIT          OLYAW
moved in x    4.68 +/- 0.08  0.01 +/- 0.03
moved in y   -5.32 +/- 0.10  0.11 +/- 0.03    (counts/mm)


  3. Measured the path length of PRM oplev returning beam was 3340 +/- 20 mm. This gives you the calibration factors above.

Discussion:
  [Precision] According to Jamie's calculation, expected g-factor for PRC in PR2-flipped PRMI is 0.966/0.939 (elog #8068). We care about the g-factor change in ~0.01. Also, intra-cavity power dependance on mirror angle is proportional to 1/(1-g). So, we need to calibrate mirror angle in ~few 10 % of precision in order to get useful g-factor from angle dithering measurement. Measurement precision here meets this requirement.

  [x/y coupling] Measured x/y coupling was less than 2 %. We assumed gains in 4 QPD quadrants are same, and assumed QPD is mounted well in x/y axes. These assumptions are OK considering precision we need.

  [x/y difference] Calibration factors for OLPIT/OLYAW are different by ~10 %. This is not so crazy considering the incident angle on the QPD (~20 deg) and elliptic beam shape.

  8223   Mon Mar 4 18:11:10 2013 JamieUpdateSUSCleaning up suspension POS inputs

I did a little bit of cleanup of the suspension POS inputs today, both in model and MEDM land.

model

sus_single_control.mdl was simplified such that now there are just two position inputs:

  • POS: with LSC filter
  • ALTPOS: unfiltered

The regular LSC inputs go into POS, and any optic-specific extra pos inputs go into ALTPOS after being properly filtered and summed.

So for instance, MC2_MCL and MC2_ALS are filtered and summed then go into MC2 ALTPOS.  The ETM ALS inputs go into ALTPOS.

I modified the GLOBAL DAMPING outputs so that they are filtered in the GLOBAL block before being sent to be summed before going into ALTPOS for {I,E}TM{X,Y}.

All suspension models were rebuilt/installed/restarted.

MEDM

The SUS_SINGLE.adl template screen was modified such that the POS button now points to optic-specific POS filter screens at:

/opt/rtcds/caltech/c1/medm/master/sus/SUS_$(OPTIC)_POS.adl

For MC1, MC3, PRM, BS, SRM these are links to SUS_SINGLE_POS.adl.  The rest of the suspensions (MC2, {I,E}TM{X,Y}) now have custom screens that are variations of SUS_SINGLE_POS but with their extra filter screens added in.  For instance, here is the new SUS_ETMX_POS.adl:

SUS_ETMX_POS.png

This gets rid of all the white screen crap that was in here before.

All of this has been committed to the SVN.  NOTE: symlinks were heavily used when sorting this stuff out, so check for symlinks when modifying in the future.

  8232   Tue Mar 5 17:09:30 2013 yutaUpdateSUSoplev calibration for ITMY

[Manasa, Sendhil, Yuta]

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
 
OLYAW: 5.74 +/- 0.09 counts/mrad

Note that there was ~10% of coupling between pitch and yaw.
This is large considering statistical error, but I think this is from QPD mounted rotated (by ~5 deg).

Method:
  Same as in elog #8221.

Result:
 
moved in y: ITMY_PIT.png      moved in x: ITMY_YAW.png

micrometer    OLPIT          OLYAW
moved in y    3.14 +/- 0.05  0.27 +/- 0.03
moved in x   -2.87 +/- 0.04  0.17 +/- 0.03    (counts/mm)


  Measured the path length of ITMY oplev returning beam was 2000 +/- 20 mm. This gives you the calibration factors above.

  ~10 % coupling between OLPIT and OLYAW can be explained by QPD rotation by ~ 5 deg, which seems not unreasonable.

  8236   Tue Mar 5 23:37:11 2013 yutaUpdateSUSPRM angular motion spectra

I measured PRM angular motion spectra (in daytime today).
PRM angular motion is ~ 10 urad in RMS when undamped and ~1 urad in RMS when damped.
If PR2/PR3 angular motions are something like this, and their motion are not enhanced when PRC is locked, measured g-factor of PRC looks OK. But considering the error we have, maybe we are not OK yet. We need calculation.

PRMangularmotion.png

  8362   Thu Mar 28 00:31:11 2013 JenneUpdateSUSPRMI optics' oplev servos tuned

[Rana, Gabriele, Jenne, Jamie, Lisa, Rana]

We have tuned the oplev servos for PRM, BS, ITMX, ITMY.  For each, we measured the servo transfer function.  Most had a UGF ~ 3Hz.  For those, we increased the gain by a factor of 2, and engaged the 3.3Hz resonant gains. The other case, such as PRM yaw, the gain was already okay, we just needed to engage the resonant gain.  We also checked the new phase margin, and for some of them switched the elliptic lowpass to 50Hz rather than 30 or 35.

Before and afters:

PRM_OLPIT_tuning_27Mar2013_RedIsAfter.pdf

PRM_OLYAW_tuning_27Mar2013_RedIsAfter.pdf

bs_pit.pdf

bs_yaw.pdf

ITMY_OLPIT_tuning_27Mar2013_RedIsAfter.pdf

ITMY_OLYAW_tuning_27Mar2013_RedIsAfter.pdf

itmx_pit1.pdf

itmx_yaw.pdf

We need to, as a last check, look at the spectra before and after to ensure that no modes (like bounce or roll) are newly excited.

  8389   Tue Apr 2 15:58:40 2013 JenneUpdateSUSoplev calibration for ITMX, BS

[Jenne, Gabriele]

Optical lever calibrations:

ITMX pit calibration = -9.07 cts/mrad

ITMX yaw calibration = -12.33 cts/mrad

ITMX plot:opl_itmx.png

BS pit calibration = -22.86 cts/mrad

BS yaw calibration = -24.14 cts/mrad

BS plot:opl_bs.png

 

Method:  Similar to Manasa and Yuta's method last month.  We mounted each oplev QPD on a micrometer translation stage, centered the beam using the steering mirror, then used tdsavg to get 10 second averages of the _INMON channel for various settings of the micrometer stage.  For BS, we had to take out the PRM oplev to make room for the translation stage.  All QPDs were remounted in their original positions, within less than 1mm.  Measured the out-of-vac distances with the laser disto-meter, and the invac distances from the optic to the window from the CAD drawing.

Copying from other elog entries,

elog 8232:

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
 
OLYAW: 5.74 +/- 0.09 counts/mrad

 

elog 8221:

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

  8390   Tue Apr 2 16:13:10 2013 ranaUpdateSUSoplev calibration for ITMX, BS

  Very good - now you need to just put the cal factor into the filter banks so that the PERROR and YERROR signals are in microradians all the time.

 

EDIT JCD:  In progress.

  8391   Tue Apr 2 16:55:34 2013 JenneUpdateSUSoplev calibration online for ITMs, BS, PRM

[Jenne, Gabriele]

We have put in a new EPICS input into the SUS library part, just before the OL_PIT and OL_YAW filter banks, so that the IN1 point is calibrated to microradians.  I recompiled all SUS-related models.  The OPTLEV_SERVO screen has been changed, so that you can see the calibration, and enter a value.  The gains have been reduced by a factor reciprocal to the calibration, so the loop gain is the same.

ETMs, SRM and MCs all have "calibration" numbers of 1, so the numbers aren't really calibrated, they're just the same as always.

It looks like the PRM and the BS are moving significantly (factor of ~30) more than the ITMs at a few Hz!  (Y-axis of plot is urad/rtHz)

comparison_opl.pdf

EDIT JCD:  We need to fix up the MEDM QPD indicators, and the OpLev red lights on the watchdog screen, so they match the new numbers.  Also, Rana turned on the output limiters to 2000 for all oplev servos.

  8393   Tue Apr 2 18:19:30 2013 JenneUpdateSUSBS, PRM oplev servos improved

 

[Gabriele, Jenne]

We have implemented 4Hz resonant gains for both PRM and BS yaw.  The filter was already in place for PRM Yaw, so we just turned it on, but we also copied the filter over to BS Yaw.  We also changed the 3.3Hz res gain and the ELP for the PRM servo to match the BS servo, since after implementing the 4Hz gain, PRM was still much noisier than BS.  Now the 2 servos match, and PRM is a little quieter.  We hope that tonight's locking might be a little more stable after this work.

PRM_servo_matches_BS.pdf

prm_bs_optical_levers_comparison.pdf

  8441   Thu Apr 11 03:25:29 2013 JenneHowToSUSIdea for how to properly balance SUS actuators
We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are 
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam 
appears to move if there is only POS motion is
d/cos(theta)
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS.  None of the of the steering mirrors in the 
oplev path matter. 

I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal 
goes into the lockin module.  Then we will be balancing the actuators based on only the actual angular motion.

The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also 
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then 
makes another apparent angular motion.  I suspect that we are close enough that we won't have to worry about this effect.
  8480   Tue Apr 23 22:59:05 2013 ranaConfigurationSUSOptical Lever Gains normalized

Due to the recent addition of cal factors in the OL error points, the OLPIT_GAIN and OLYAW_GAIN have been reduce to tiny numbers (e.g. 0.002).

Since our MEDM only shows 3 digits past the decimal point by default, it makes more sense to have the gains around 1.

So I reduced the gains in all of the FM1 filters from 1000 to 1 and multiplied the GAIN values by 1000 (using ezcastep) to compensate.

All of the active optics seem to be behaving as before. Haven't tested ETMs or SRM yet.

  8481   Wed Apr 24 00:42:07 2013 JenneUpdateSUSPRMI locked, ITMX pitch OpLev ringing up

Koji is working on PRMI locking, and while he was doing that I glanced at the oplevs' spectra for the ITMs and PRM.

I found that when the PRMI was locked (for only 1 second or so max lock time) on the 55MHz sideband, and the error signals show a big peak around 400Hz (definitely audible in the control room), the only OpLev that I see a similar peak in is ITMX pitch. 

In the plot below, I have grabbed a time when the PRMI was flashing as the black reference traces, and then a time when the PRMI was locked as the active traces.  You can see that there is a similar peak in both REFL55I and ITMX_OL_PIT when the cavity is locked. 

PRMI_locked_ITMXpitOpLevRingingUp.pdf

  8482   Wed Apr 24 00:44:33 2013 KojiUpdateSUSPRMI locked, ITMX pitch OpLev ringing up

I tried to reproduce the locking situation described in this entry tonight.
The momentary lock was regularly seen but there was no stable lock.

I wonder why the actuators are always saturated. The feedback signals have the dominant component at ~400Hz.

It would also be nice if the servos have some immunity to gain fluctuation.

I didn't check how the situation of the AP table is. I'll look into some details tomorrow.

  8510   Tue Apr 30 10:54:35 2013 JenneUpdateSUSETMX restored

I'm not sure why or when it was tripped, but I have restored the ETMX watchdog.

  8514   Tue Apr 30 22:40:57 2013 JenneUpdateSUSoplev XY-plots reflect new calibration

Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians.  A consequence of this is that all of the XY-plots on the medm screens were too small. 

I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1. 

I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians. 

While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.

  8527   Fri May 3 09:17:41 2013 SteveUpdateSUSETMX needs some help
Attachment 1: ETMX3.2eq.png
ETMX3.2eq.png
  8533   Tue May 7 03:14:06 2013 JenneUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

While looking over Koji's shoulder earlier, I noticed the big peak in the PRM yaw spectrum (and I was starting to get annoyed by the hum....the fibox is so useful in motivating tasks that otherwise get looked over!) 

I used DTT's peak find feature (cursor tab, enable both cursors, select Peak X/Y as your 'statistic', set the 2 cursors to be on either side of the desired peak) to find the frequency of the PRM's violin mode.  It is 627.75 Hz. I adjusted FM5 of the C1:SUS-PRM_LSC filter bank (the "violin" filter) to be centered around this frequency, with the start and stop freqs +\- 4Hz.  I plotted the filter linearly in frequency to ensure that my target freq was not too close to either side of the bandstop.  After loading and engaging the new filter, the hum slowly started to go away. 

Note, for posterity:  The bandstop used to be centered around ~645 Hz or so.  I assume this is a copy-and-paste situation, where we hadn't gone through to check the exact frequency for each optic.

  8612   Wed May 22 00:42:13 2013 KojiSummarySUSviolin Q

While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.

Error signal: REFL33I

The peak @628Hz became 0.372 to 0.303 in 60 sec.

-> Half life of the amplitude T_{1/2} is 203sec.

Q = 4.53 f0 T_{1/2} = 5.8 x10^5

  8617   Wed May 22 15:48:56 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

  8620   Wed May 22 18:24:19 2013 JenneUpdateSUSViolin mode survey

Quote:

It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?

 Ooops, definitely my bad.  I think I was the one who put in the PRM violin filter, so I should have recognized that frequency.  However, I couldn't think of a reason why violin mode filters should be in the LSC filter banks, since we usually put them in C1:SUS-optic_LSC filter banks. 

Anyhow, so that I don't make a mistake like that again, I was looking through all of the violin mode filters for all the optics, so I could write down the frequencies.  The result: confusion.

Violin filters in C1:SUS-optic_LSC filter banks:

The PRM's violin mode filter is set correctly to 627.75Hz:  elog 8533.

One of BS or SRM has probably been measured (presumably BS), since they have the same filters centered around 645Hz. 

Neither ITM has a violin filter.

The ETMs have violin filters in the 440's, which I assume was correct back in the MOS days, before 2010.

Vio2 filters in C1:SUS-optic_LSC filter banks:

PRM, SRM, BS, ITMX, ITMY:  Centered around 1285 Hz, which matches the violin notch frequencies in the BS and SRM.

ETMY:  Centered around 883.5Hz, which matches the old 440Hz frequency

ETMX:  Centered around 631Hz .  So, this could have been measured, but it was put into the wrong filter module.

 

Koji tells me that we don't really need to worry about all these violin filters unless they are required (as with the PRM and the obnoxious hum a few weeks ago), so I 'm not going to do any measuring / adjusting of these filters for now.

  8625   Thu May 23 10:20:33 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

Quote:

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

I have restarted all the suspension models with the new no_zero_pad flag for the DAC upsampling.  Everything came up fine and all optics are damped as expected (except for concerns about c1scy which I'll note in a followup).

  8668   Tue Jun 4 10:33:09 2013 ranaUpdateSUSETMY oplev path redone

 We also redid the oplev path.

Someone had used the illegal tactic of using aluminum dogs to hold down mounts which already have screw holes in the bases. This is too flimsy to use.

We then adjusted the position of the second lens to get a ~1 mm spot on the QPD. There is a lot of stray red light from extra reflections, but so be it.

Its possible that we are now clipping the IPANG path, but we will need to lock the Y arm and verify the input pointing to be sure. At this point we are ready to measure the ETMY OL loop gain and tune, etc.

  8719   Wed Jun 19 00:46:06 2013 JenneUpdateSUSsave/restore alignment scripts now also work for TTs, fixed a bug

I have done a quick update of the IFO_ALIGN screen's save and restore scripts, so that we can now also save, restore, and view the saved values for the input tip tilts. 

In the past, there was an "if" statement to check if the optic was a PZT, and if so, define the alignment channels accordingly (since all the SOS suspensions have the same format for the name, and the PZTs were the odd ones out).  I have removed the mention of PZTs, and replaced the if statement with an "if TTs" statement, and put in the correct channel names (C1:IOO-TT#_PIT_OFFSET, and the same for YAW). 

Also, I caught a bug in the code, which explains some confusing behavior that I had seen in the past.  When deciding if the restore script should take small steps or just do a big step, it looked at the difference between the saved value and the current value of the slider.  It was *not* looking at the absolute value of the difference.  So, if you had misaligned a slider by hand, and it was in the opposite direction of what the misalign script does, the restore script wouldn't realize that the optic needed to be restored in small steps.  I have now fixed this bug for both pit and yaw cases of the restore script.

  8734   Thu Jun 20 17:47:44 2013 AnnalisaConfigurationSUSETMY oplev servo

[Jenne, Annalisa]

The ETMY Oplev servo didn't work properly, when it was activated the ETMY moved too much.

We measured the oplev TF for Pitch and Yaw and it turned out that the gain was too low by a factor 3, so we increased the gain from -.250 to -.750 on both.

We also locked the Y arm and we could see that the mirror's oscillations are actually suppressed.

 

  8747   Tue Jun 25 22:50:12 2013 ranaUpdateSUSSUS Screens generation problems?

Untitled.png

From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.

Why are these different from the SUS screens I get from the sitemap?

  8749   Tue Jun 25 23:49:04 2013 AnnalisaUpdateSUSETMY Oplev

I had some problem with the Oplev Servo today. I was working at the mode matching fine tuning and I left the Oplev servo enabled while aligning.

When I opened the Yend table lids, the Oplev beam started moving on the QPD and the Oplev servo didn't help in stopping the mirror movement, but it increased it.

So, the mirror was oscillating at a frequency of a few Hz

Koji suggested that maybe the shaking is due to the air conditioning moving the beam, so the servo tries to feed back the signal to the mirror, even if the mirror doesn't actually move.

I also measured the transfer function for the Oplev, but it didn't show any strange behavior.

  8750   Tue Jun 25 23:57:30 2013 ranaUpdateSUSNDS2 Status

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

  8757   Wed Jun 26 15:11:08 2013 John ZweizigUpdateSUSNDS2 Status

Quote:

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2
     ./start-nds2

  * restarted nds2 with updated channel lists.

  8787   Fri Jun 28 17:33:33 2013 John ZweizigUpdateSUSNDS2 Status

Quote:

Quote:

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2
     ./start-nds2

  * restarted nds2 with updated channel lists.

 I have set the cron job up to restart the nds2 server automatically if the channel list changes. The only change is that the cron command was changes to /ligo/apps/nds2/nds2-megatron/test-restart.

 

  8802   Thu Jul 4 17:14:53 2013 ranaUpdateSUSNew SUS screen

 Now that the 3f locking looks so cool for the PRMI, I suppose that the PRMI + arm stuff will be very successful.

At LLO, I've just noticed the screens that they have for the single pendulums / TTs. I'm attaching a screenshot of the one Zach is using for the steering into the OMC. We should grab these and replace our existing SUS screens with them.

Attachment 1: OM1.png
OM1.png
  8803   Thu Jul 4 19:37:37 2013 KojiUpdateSUSNew SUS screen

Totally agree. The old suspension screen should be driven away.

  8916   Wed Jul 24 13:41:13 2013 JenneUpdateSUSSR2 flipped

[Jenne, Annalisa]

SR2 is flipped, and reinstalled.  We did that before lunch, and we're about to go in and work on SR3 and PR3.

EDITS / Notes:

I set dog clamps to have a reference position of where the tip tilt was, then I removed SR3 from the chamber.  Once out, I followed the same procedure I used for PR2 during the last vent - I removed the whole suspension (top mount, wires, optic) from the cage, and laid it down flat.  Then I loosened the set screw which pushes on the teflon nudge, removed the mirror, inspected it, and put it back in, with the HR side facing the back side of the ring.  Then I replaced the suspension system in the cage, and put the mirror back into the chamber. 

When I loosened the teflon nudge at the top of the mirror holder ring, the optic seemed to fall down a tiny bit.  I think this implies that the HR surface of the optic did not used to be parallel to the front face of the mirror holder ring.  When I put the suspension back onto the cage, the pitch balancing was very bad.  We checked the level of the table that I had the cage on, and it was miraculously pretty level, so I did the pitch balancing out of the chamber. 

Also, during my quick inspection of the mirror (not thorough, just using room lights), I noticed a small fleck of lint near the edge of the optic on the HR surface.  The HR surface is now on the outside of the SRC, but we should still blow at the optic with the ionized nitrogen to get it off.

I did not think to check the fine-tuning alignment of SR2....Koji did that after lunch (which I will elog about in a separate elog).

 

  8918   Wed Jul 24 15:07:54 2013 KojiUpdateSUSSR2 flipped

After the first flipping, X/Y arms were aligned and locked. Then the ASS aligned the arms.

  8919   Wed Jul 24 19:21:56 2013 JamieHowToSUSSUS MEDM screen modernization

I started poking around at what we want for new SUS MEDM screens.  Rana and I decided we'd start with the ASC TIPTILT screens:

newsusmedm.png

It's missing some things (like SIDE OSEMS) but it should provide a good starting point.

I copied the entire <userapps>/asc/common/medm/asctt directory to a new directory in our sus area:

controls@rossa:/opt/rtcds/userapps/release 0$ cp -a asc/common/medm/asctt sus/c1/medm/new

I then removed all the useless file name prefixes.  We still need to go through and sed out all the ASC stuff in the MEDM files themselves.

It makes heavy use of macro substitution, which is good (it's what we're using now).  So once we clean up all the channel names, we should just be able to swap out the pointers in our overview screens to the new screens (or rename things).  In the mean time, during development, you can run:

controls@rossa:/opt/rtcds/userapps/release 0$ medm -x -macro "IFO=C1,ifo=c1,OPTIC=ITMX" sus/c1/medm/new/OVERVIEW.adl 

  8924   Thu Jul 25 14:02:53 2013 JenneUpdateSUSSR3, PR3 flipped

Yesterday afternoon, I went back into the BS chamber, and flipped both PR3 and SR3. Now all of the recycling cavity folding mirrors have been flipped.

For PR3, I followed the same procedure as SR2, setting a reference position, removing the optic, flipping it, etc.  When I put it back in, I realized that since this has a 41 degree angle of incidence, the beam going to the BS had translated north by ~1cm.  After some fiddling, Koji pointed out that the 2 degree wedge probably had a more significant effect than just the HR surface having moved back a small amount.  Anyhow, we adjusted PR3 such that we were going through the BS aperture, as well as the ITMY aperture. 

During the flip of PR3, Annalisa and I noticed that the arrow on the barrel of the LaserOptik mirrors also indicates the thickest part of the wedgeThis is opposite of our SOS optics, where the arrow's position on the barrel indicates the thinnest part of the wedge.  For both PR3 and SR3, I kept the arrow on the same side of the optic as it was originally.

I then flipped SR3, following again the same procedure.  PR3 I had done a tiny bit of pitch rebalancing, although I think it was unneccessary, since it is within what we can do with the poking/hysterisis method.  SR3 I did not do any pitch rebalancing.  With PR3 aligned at least to the ITM, Koji and I aligned SR3 and SR2 so that the AS beam was hitting the center of all the SRC optics.  We also adjusted the steering mirrors after the SRM to get the beam centered on PZT3, the last optic on the BS table, which launches the beam over to the OMC chamber.  We scanned around a bit by turning the PZT's knobs, but we were unable to see the AS beam on the camera. 

 

  8981   Wed Aug 7 21:52:11 2013 JenneUpdateSUSSRM coils fine - problem with slow bias slider

[Koji, Jenne]

We have looked a little more at the SRM situation.  We aligned the SRM, and then aligned the oplev, so that we had a convenient monitor of the optic's motion.

When we use the _COMM channels, which are the usual ones on the IFO_ALIGN screen, the pitch slider makes pitch motion, but the yaw slider makes the oplev spot move ~45degrees from horizontal.

However, when we use the bias channels that are in the front end model, parallel to the ASC path, pitch moves pitch, and yaw moves pure yaw.

So, we conclude that the SRM coils are fine, and there is something funny going on with the slow part of the actuation. 

Koji restarted the slow computer susaux, and burt restored it, but that did not fix the situation.  We went inside and looked at all of the ribbon cable connections, and pushed them all in, but that also has not fixed things. 

We have been looking at D010001-b, the coil driver board, and we think that's where the summing resistor network between the slow bias slider, and the coil outputs from the fast model exists.  (It's not 100% clear, but we're confident that that's what is going on). 

Tomorrow, we will pull the SRM's coil driver board, and see if any of the components in the slow slider path, before the summing point, look burned / broken / bad.

  8991   Fri Aug 9 21:05:28 2013 KojiUpdateSUSfixed: SRM coils fine - problem with slow bias slider

Now the SRM Yaw bias in yaw is functional without any strage behavior.
The problem was found at the connector of the flat ribbon cable from the DAC to the cross connect.

I used the extender board to diagnose the SRM coil driver circuit at 1X4.
The UL coil input did not show any sign of voltage no matter how the bias slider was jiggled.

I opened the side panel of the rack and found the signal was absent at the cross connect which relays two flat ribbon cables
for the SRM coil driver. I checked the DAC output with a multimeter. All the bias outputs were OK at the DAC.

Then I opened the IDC connector at the DAC side of the crossconnect as the signal was already missing there.
I found that the flat ribbon cable was a half line shifted from the supposed location.
This resulted a short circuit of the DAQ +/- pins for the SRM UL coil.

I recrimped the connector and now the SRM Yaw slider is back.
This changed the nominal position of the SRM. The new slider values were saved.

  9024   Mon Aug 19 07:53:48 2013 SteveUpdateSUSETMX damping restored

ETMX sus damping restored

  9048   Wed Aug 21 23:50:40 2013 KojiUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

[Jenne Koji]

It seems that the PRM violin mode freqs shifted from 625-ish to 640Hz.
The peaks rang up because of the servo.

Once the notch freq was shifted to 640Hz, the violin mode started to decay.

ellip("BandStop",4,1,90,636,644) gain(1.12202)

  9057   Fri Aug 23 01:52:34 2013 JenneUpdateSUSViolin filters moved to LSC, from SUS

[Rana, Jenne]

We were meditating a little bit on what may be the story behind the PRM violin filter situation.  We locked the PRMI, and turned on and off the violin filters.  We noticed, very bizarrely, that when the violin filters were ON, the servos would oscillate.  Weird.  Also, probably because the oscillation was causing us to hit the limit we have in the MICH servo, we rung up a 3rd harmonic of one of the violin modes, which was at 1955 Hz. 

We took a transfer function of the PRCL servo, saw that the UGF was 300 Hz, and lowered it to ~180 Hz.  After later investigations, that high-ish UGF probably wasn't a problem.  Anyhow, we then took MICH servo transfer functions, and saw some very weird stuff. 

At frequencies where we had violin filter notches, we were seeing peaks in the transfer function, which came close to touching, or crossed the 0dB line!  We suspect that this may have something to do with the balancing of the drives to the optics, since we have PRCL driving PRM, but MICH driving BS and PRM.  What we did was move the violin filter notches into the LSC model.  There were already SUS filter banks in the LSC model (right side of the LSC screen).  In preparation for the DRMI, I have put the BS violin notches into the BS, PRM and SRM filter banks, as well as the PRM and SRM filters into all 3 banks.  Right now for PRMI, I have the BS and PRM notches (as well as the Vio3 notch) turned on in both BS and PRM.  All of the violin-related filters are turned off in the LSC filter bank inside the SUS models.  When we did this, the servo oscillations no longer are excited when we turn on the notches, and when we take a new transfer function, there are no longer weird peaks at the notch frequencies.  More meditation needs to be done.

Also, for the violin3 filter, Rana noted that at 1955 Hz, after we confirmed that the REFL 55 phase was set correctly (and we're using REFL 55 I&Q for PRMI locking), the I-phase had a response of 0.36, while the Q-phase had a response of 0.20.  I should be able to think about these numbers, and decide if the vio3 is for the BS or the PRM violin mode.

 MICHloopNotches_23Aug2013.pdf

the above series of Bode plots shows the MICH Open Loop Gain as the REFL55 phase is adjusted (PURPLE, ORANGE) with the notches in the SUS and then (RED) as the notches are moved to the LSC and made the same for all optics.

In other news, I have the parts that Jamie ordered to make a new 110 demod board, so that's one of my daytime activities now, so we can have both POP110 and AS110.

  9058   Fri Aug 23 14:19:28 2013 ranaUpdateSUSViolin filters moved to LSC, from SUS

  Just to rephrase somewhat:

  • We balance the BS & PRM actuators in the LSC Output matrix so that there is no MICH signal going into REFL_I @ 100 Hz.
  • REFL Phase is adjusted by driving PRM and minimizing Q/I to within ~1 deg (Q/I ratio of ~2%)
  • The REFL_I sensing matrix element is ~50x bigger than REFL_Q (in W/m)
  • When we turn ON the violin mode notch in the BS SUS, it changes the MICH drive into a purely PRCL drive at that frequency !!!
  • So, putting notches into the SUS screens is bad since it imbalances the drives.
  9065   Mon Aug 26 19:31:22 2013 manasaUpdateSUSPRM, ITMY watch dogs

PRM and ITMY were found with their watchdogs shutdown this afternoon (cause unknown). I re-engaged them.

  9088   Thu Aug 29 17:25:50 2013 JamieUpdateSUSSUS medm screen upgrade

Rana asked me to look at the SUS MEDM screen upgrade situation, and provide an upgrade prescription.  Unfortunately there not really a simple prescription that can be used, since our configuration diverges quite a bit from what's at the sites.  But here's what I can say:

It looks like we already have the beginnings of an upgrade in place, so I say we just run with that.  The new screens are in:

/opt/rtcds/userapps/release/sus/c1/medm/new

The primary screen is:

/opt/rtcds/userapps/release/sus/c1/medm/new/OVERVIEW.adl

This seems to be a copy of the site ASC_TIPTILT screens.  (In fact I think I remember putting this here).  I went ahead and did some ground work to make it easier to get these new screens into place.

  • I cleaned up all the channel name prefixes so that at least the channel prefixes will resolve to our SUS channels.
  • I made a link from the sitemap with some of the correct macros to fill some things in appropriately: "IFO SUS/NEW ETMX"
  • I fixed the names to the sub-screens, so that it correctly opens the correct sub-screens (although the macros seem to not be passed correctly)

At this point someone needs to just go through and fix all the channel names to match ours, and tweak the screen to our needs (there's no side OSEM, for instance).  The subscreens need to be cleaned up as well.

sed replace string

If there is a specific string you want to replace every instance of in the screen, you can do that easily from the command line like this:

sed -i 's/OLD/NEW/g'  

This will replace every instance of the string OLD with the string new in the file path/to/file.  Be careful: this will replace EVERY instance of OLD.  If OLD matches things you don't want, they will be replaced as well.

This construction is actually "regular expressions", so if you want to get fancy you can match against more complicated strings.  But just be careful.

If you leave out the "-i" the string-replaced text will go to stdout, instead of being replaced in the file "in place", so you can check it first.

query replace in emacs

If you want more fine-grained control of text replace, so that you can see what's being replaced, try using "query-replace" in emacs:

M-x query-replace

You can then type in the original string, followed by the replacement string.  When it starts to run it will highlight the string that will be replaced.  Hit "space" to accept or "n" to skip and go to the next.

 

 

  9102   Wed Sep 4 16:08:22 2013 manasaUpdateSUSMC2 tickler turned OFF

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.

 

EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

  9104   Wed Sep 4 20:39:23 2013 ranaUpdateSUSMC2 tickler turned OFF

Quote:

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.

 

EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

 Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.

The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.

  9107   Wed Sep 4 22:14:35 2013 JenneUpdateSUSMC2 tickler turned OFF

Quote:

 

 Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.

The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.

 Isn't that backwards?  Shouldn't the tickler be enabled by the down script, and disabled by the up script?  Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so.  Also, the WFS definitely couldn't be enabled by hand. 

Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again.

ELOG V3.1.3-