40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 39 of 344  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  5822   Sat Nov 5 21:19:08 2011 ZachUpdateSUSDr. SUS paths updated--question of human oversight remains

Ok, here's the deal:

  • For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
  • Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
  • I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
  • I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

  1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
  2. Cron runs runDrSUS at 8am that Sunday. This:
    1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
    2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
  3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
    1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
    2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

Quote:

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

 

  5823   Sun Nov 6 09:39:25 2011 Dr. SUSUpdateSUSOptics kicked
All suspended optics have been kicked at Sun Nov 6 09:39:25 PST 2011. Watchdogs will be reengaged in 5 hours. Please refrain from disturbing the optics in the meantime.

EDIT ZK: After all that, I left the 'doirun' bit off in runDrSUS. I ran it manually at the above time.
  5824   Sun Nov 6 16:58:25 2011 ZachUpdateSUSDr. SUS failed--NDS2 problems again

 Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

 

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

 

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this. 

 

 

  5844   Wed Nov 9 07:57:39 2011 steveUpdateSUSETMX oplev is down and sus damping restored

The ETMX oplev returning beam is well centered on the qpd. We lost this signal 2 days ago. I will check on the qpd.

ETMX sus damping restored.       c1iscex computer is down

Attachment 1: etmxtripped.png
etmxtripped.png
Attachment 2: etmxOpl.png
etmxOpl.png
  5845   Wed Nov 9 10:35:30 2011 jamieUpdateSUSETMX oplev is down and sus damping restored

Quote:

The ETMX oplev returning beam is well centered on the qpd. We lost this signal 2 days ago. I will check on the qpd.

ETMX sus damping restored

 As reported a couple days ago, the ETMX IO chassis has no timing signal.  This is why we there is no QPD signal and why we turned off the ETMX watchdog.  In fact, I believe that there is probably nothing coming out of the ETMX suspension controller at all.

I'm working on getting the timing board replaced.  Hopefully today.

  5862   Thu Nov 10 12:28:31 2011 JenneUpdateSUSMC2 is being a little wild...WFS to blame

Mirko and  Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now.  It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC.  I disabled the MC autolocker before they started working. 

Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp.  I think it's the WFS.  The yaw output from the WFS is truely crazy. 

I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp.  My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy. 

SURESH: FIX ME!  (signed, The WFS)

WFSscreenshot.png

  5865   Thu Nov 10 19:41:24 2011 JenneUpdateSUSMusings on SUS dewhitening, and MC ELP28's

The following will be a stream-of-consciousness, approximately chronological story of my last hour or so of looking at screens....

In the old OAF days, we used to bypass the analog dewhitening in the coil driver path, using the XYCOMS.  See, ex. elog 2548.

I began to wonder if we needed to do the same thing now.  I checked several optics, to see how the switching works. 

For the whitening on the OSEM sensor input, FM1 is linked to the Contec binary I/O.  FM1 is the inverse whitening filter.  Turn it on, and the analog whitening is on (bit in the binary I/O screen turns red).  Turn it off, and the analog whitening is bypassed (bit in the binary I/O screen turns gray).  Good.  Makes sense.  Either way, the net transfer function is flat.

The dewhitening is not so simple.  In FM9 of the Coil Output filter bank, we have "SimDW", and in FM10, we have "InvDW".  Clicking SimDW on makes the bit in the binary I/O screen gray (off?), while clicking it off makes it red (on?).  Clicking InvDW does nothing to the I/O bits.  So.  I think that for dewhitening, the InvDW is always supposed to be on, and you either have Simulated DW, or analog DW enabled, so that either way your transfer function is flat.  Fine.  I don't know why we don't just tie the analog to the InvDW filter module, and delete the SimDW, but I'm sure there's a reason.

All optics have this setup, except MC1 and MC3.  They don't have the SimDW or InvDW filter modules.  Instead, in FM9 (which on all the other suspensions is SimDW, and controls the binary I/O) there is a 28Hz Elliptic Low Pass filter.  The only thing I can find about these is elog 1405 where Rana talks about implementing ELP28's in MC2.  But right now there is no ELP in the MC2 coil output filters.  So, if Rana's old elog is to be believed, we need to fix up the ELP28 situation.  But that elog was from a long time ago, so maybe things are different now?  If MC1 and MC3 need the SimDW and InvDW (why wouldn't they?) then the ELP28 needs to move to another filter module.  Because right now, when I click the ELP28's on and off, it changes bits in the binary I/O.  Which I don't think it should.  Maybe.  I don't really know.

Okay. So. Now we know where everything is, and which buttons do what.  Maybe not why, but at least what.

In the old world, Rob had lots and lots of trouble (elog 2027) with locking when the analog dewhitening was bypassed.  But right now, I think that all of the analog dewhitening filters are bypassed, for every single optic we have.  So.  Which way do we want things?  What's the new game plan.  What's going on??

\end{stream-of-consciousness}

  5873   Fri Nov 11 13:26:24 2011 jamieUpdateSUSMusings on SUS dewhitening, and MC ELP28's

Quote:

For the whitening on the OSEM sensor input, FM1 is linked to the Contec binary I/O.  FM1 is the inverse whitening filter.  Turn it on, and the analog whitening is on (bit in the binary I/O screen turns red).  Turn it off, and the analog whitening is bypassed (bit in the binary I/O screen turns gray).  Good.  Makes sense.  Either way, the net transfer function is flat.

The dewhitening is not so simple.  In FM9 of the Coil Output filter bank, we have "SimDW", and in FM10, we have "InvDW".  Clicking SimDW on makes the bit in the binary I/O screen gray (off?), while clicking it off makes it red (on?).  Clicking InvDW does nothing to the I/O bits.  So.  I think that for dewhitening, the InvDW is always supposed to be on, and you either have Simulated DW, or analog DW enabled, so that either way your transfer function is flat.  Fine.  I don't know why we don't just tie the analog to the InvDW filter module, and delete the SimDW, but I'm sure there's a reason.

The input/whitening filters used to be in a similarly confused state as the output filters, but they have been corrected.  There might have been a reason for this setup in the past, but it's not what we should be doing now.  The output filters all need to be fixed.  We just haven't gotten to it yet.

As with the inputs, all output filters should be set up so that the full output transfer function is always flat, no matter what state it's in.  The digital anti-dewhitening ("InvDW") and analog dewhitening should always be engaged and disengaged simultaneously.   The "SimDW" should just be removed.

This is on my list of things to do.

  5877   Fri Nov 11 21:09:30 2011 SureshUpdateSUSMC2 is being a little wild...WFS to blame

Quote:

Mirko and  Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now.  It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC.  I disabled the MC autolocker before they started working. 

Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp.  I think it's the WFS.  The yaw output from the WFS is truely crazy. 

I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp.  My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy. 

SURESH: FIX ME!  (signed, The WFS)

WFSscreenshot.png

 

The Problem

Turning off the WFS servo loops usually should be done using the 'mcwfsoff' script.  The script takes care of switching off the integrators and Clears the History.  

'mcdown' and 'mcup' scripts run the 'mcwfsoff' and 'mcwfson' scripts so when the MC unlocks the WFS servos are shutdown and restarted properly.  However if the MC autolocker script is suspended by pressing the Enable/Disable switch in the LOCKMC screen and then the MC unlocks, it results in the WFS servo integrators accumulating large values.  If these values are passed through the ASC filter banks the optic will get a pretty huge kick.

The Solution

I have added some indicators which will let us know if the WFS Servo Filter outputs are larger than +/-1000.  When engaging the WFS loops the user has to take care to Clear History in the servo filter banks if these indicators are steadily Red.   before engaging the WFS Servo loops ensure that the servo filter outputs are zeroes. 

Koji and I discussed whether it would be useful to run the 'mcwfsoff' script when the Disable button is pressed in the autolocker.  His recommendation is that we should keep  the autolocker script simple and that user has to be cautious when switching on the WFS servos and when directing the ASC outputs to the suspensions.

LOCKMC_screen.png

 

  5909   Wed Nov 16 10:25:57 2011 steveUpdateSUSPRM damping restored

The  PRM lost damping about a day ago. It was restored.

  5927   Thu Nov 17 15:19:06 2011 steveUpdateSUSTi spring plunger to hold OSEM is not affortable

Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.

Problems:  1, they become magnetized after years being close to the magnets

                     2, they oxidize by time so it is hard to turn them

                    

I looked around to replace them.

Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.

Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50

Attachment 1: 20111116111042405.pdf
20111116111042405.pdf
Attachment 2: P1080216.JPG
P1080216.JPG
  5974   Tue Nov 22 00:19:10 2011 kiwamuUpdateSUSc1auxey hadware rebooted

I found that the slow machine c1auxey, which controls and monitoring the ETMY suspension things, were not responding.

The machine responded to ping but I wasn't able to telnet to it.

I went down there and power-cycled it by keying the power of the VME rack, and then it came back and seems working properly.

I have no idea why it ran into such condition.

  5982   Tue Nov 22 23:06:13 2011 kiwamuUpdateSUSMC watchdogs

[Rana / Mirko / Kiwamu]

 The watchdogs on the MC suspensions are not working.

Switching off the watchdogs doesn't stop feeding signals to the suspensions.

For tonight, we will leave the controller of the MC suspensions switched off so that the computer won't smash the optics accidentally.

  6007   Fri Nov 25 18:45:31 2011 Den, RanaSummarySUSExcess Noise in Digital Filtering

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

Attachment 1: FiltNoise.png
FiltNoise.png
  6008   Fri Nov 25 19:45:36 2011 Mirco, DenSummarySUSExcess Noise in Digital Filtering

Quote:

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

 We have done the following on the c1sus and c1lsc computers : provided excitation, let the signal pass through filters 30:0.0 and Cheby and plotted the coherence between in and out signals.

c1sus computer - coherence is corrupted

c1lsc computer - coherence is not corrupted

Attachment 1: sus_coh-crop.pdf
sus_coh-crop.pdf
Attachment 2: lsc_coh-crop.pdf
lsc_coh-crop.pdf
  6010   Fri Nov 25 20:41:48 2011 ranaUpdateSUSMC watchdogs

It seems as if someone was looking into this on Wednesday, but as there's no elog, I think probably not.

Tonight we noticed that, in fact, the watchdogs don't work for any of the corner optics (I confirmed that they do work for the ETMs).

Whether the switch for the coil drivers is enabled or disabled, the voltage monitor on the coil drivers responds to the digital signals.

I tried restarting the c1susaux process, hitting reset on the crate, and also keying the crate. The +5V light on the front of the crate is flickering somewhat, but I'm not sure if this is new or not since the power outage. The next step is to track the Xycom signal from the card over to the coil driver to find where the signal is failing to happen.

Since its not working for any of the corner optics, I suspect the crate and not the cards. If that's the issue this will be a painful fix. We are sort of assuming that this is due to the power outage, but in fact, I cannot tell when the last time was that someone rigorously verified the working of these switches. [

I][B]We had better get ready for upgrading our SLOW controls, Jamie.[/B][/I]

Quote:

[Rana / Mirko / Kiwamu]

 

The watchdogs on the MC suspensions are not working.

 

Switching off the watchdogs doesn't stop feeding signals to the suspensions.

For tonight, we will leave the controller of the MC suspensions switched off so that the computer won't smash the optics accidentally.

 

 

  6014   Sat Nov 26 02:15:42 2011 MirkoUpdateSUSNot adaptive, still cool

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

 

 

Attachment 3: SetupVirtualPendulumV2.png
SetupVirtualPendulumV2.png
  6021   Mon Nov 28 10:54:40 2011 ranaUpdateSUSF2A filter for MC

Our approach to making the F2A or F2P filters for the MC is to use the measured resonant frequencies and then calculating the appropriate mechanical dimensions of each suspension. This is basically because we don't have optical levers with normal incidence on these optics, but the method should be fine.

To find the formulas, I asked Gaby for her old cheat sheet: Its now in the DCC. Its only for Large optics, but you should be able to reconstruct the right ones for SOS by just changing the parameters.

  6057   Thu Dec 1 03:27:39 2011 MirkoUpdateSUSNot adaptive, still cool

Quote:

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

 

 

In the above entry MC_f  signal is improved off of resonance by the implementation of the pendulum compensation. It should be checked if this is actually due to the implementation of the virtual pendulum at 0.1Hz. A way to check that might be to implement a simple double LP at 0.1Hz instead and look at the resulting MC_f signal. A projection of the OSEM FB noises with the compensation active might be interesting.
The physical resonance at 1Hz is clearly not compensated correctly, which is probably the reason for the lock losses after a few minutes. It might be a good start to measure the residual resonance with the compensation in place. The filters in bank 7 of C1:SUS-MC?_SUSPOS have both the compensation of the 1Hz resonance( really the inverse actuator TF ) and the virtual pendulum in them. The ‘pure’ compensation can be found in the InvTF module in the C1:OAF-ADAPT_MCL_CORR filter.
The fact that the beam swings in yaw at lock loss indicates that the separation of the DOFs might not be perfect. One should have a look into the yaw and pitch DOFs with the compensation active.

  6060   Thu Dec 1 17:33:18 2011 kiwamuUpdateSUSwatchdogs fixed

The watchdogs' issue has been solved and they are now working fine.

It was just because one of the Sorensens had been off.

The Sorensen is the one supplying +5 V in the 1X5 rack.
This +5 V is actually used as a pull-up-current to properly drive the MAX333As (CMOS analog switch) in the coil drivers (D010001).
So this was it.

Quote from #6010

Tonight we noticed that, in fact, the watchdogs don't work for any of the corner optics (I confirmed that they do work for the ETMs).

  6128   Sat Dec 17 01:56:16 2011 KojiSummarySUSHysteresis test

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

 

 -- EDIT by KI:
I found the ITMY watchdogs tripped around 2:40 AM and then re-engaged it.
  6129   Sat Dec 17 03:59:32 2011 kiwamuUpdateSUSAborted Hysteresis test

Quote from #6128

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.
  6130   Sat Dec 17 11:53:46 2011 ZachUpdateSUSAborted Hysteresis test

Do you guys have timestamps for when you started/ended the test? I have been trying to take some long-term RAM data but keep getting foiled by stuff (this test, RTS upgrade, switching of RAMmon channels, etc.)

Quote:

Quote from #6128

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The hysteresis test has been aborted.

All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.

In fact the ITMX and ITMY mirrors started being stacked to their OSEMs.
The script process has been force-quit and I have restored all the DC biases to their nominal points.
They still look okay: MC can be locked at the 00 mode, DRMI fringe is visible at AS, the green beams are resonating the arm cavities
Need another trial.

 

  6131   Sat Dec 17 12:41:46 2011 KojiUpdateSUSAborted Hysteresis test

The test was from: 2011-12-17 09:48 to 11:49 (UTC).
This corresponds to the period from 2011-12-17 01:48 to 3:49 (PST).

ZK: Thanks

  6132   Sun Dec 18 16:16:55 2011 kiwamuUpdateSUSAnother trial of Hysteresis test

Koji has modified the script for the hysteresis measurement.

A new test started from 16:05 PT, Dec 18th and takes a couple of hours to finish the measurement.

Do not touch the suspensions until further notice.

Quote from #6129

The hysteresis test has been aborted.

Need another trial.

  6134   Sun Dec 18 19:56:00 2011 kiwamuUpdateSUSAnother trial of Hysteresis test

The measurement finished at ~ 21:50 PT.

Quote from #6132

A new test started from 16:05 PT, Dec 18th and takes a couple of hours to finish the measurement.

Do not touch the suspensions until further notice.

  6135   Sun Dec 18 23:00:22 2011 kiwamuUpdateSUSoplve recenterd

I have recentered the oplev beams, including BS, ITMs and ETMs.

  6136   Mon Dec 19 01:54:35 2011 kiwamuUpdateSUSanother trial of hystersis test

Another hysteresis test has begun at 1:50 PT, Dec/19.

It will finish after 3 or 4 hours. During the measurement the PSL mechanical shutter will be kept closed.

Time record                       
   Start:  Dec/19 1:50 PST
   End :  Dec/19  5:30 PST
  6142   Wed Dec 21 14:23:08 2011 ranaConfigurationSUSHysteresis in suspensions?

While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.

Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.

In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.

 

  6180   Mon Jan 9 08:47:35 2012 steveUpdateSUSETMX damping restored

ETMX sus damping restored

  6181   Mon Jan 9 13:19:09 2012 kiwamuUpdateSUSETMX damping restored

No we can't do that because the c1scx model is not working properly.

If you look into the real time controller screen you will find what I mean.

Quote from #6180

ETMX sus damping restored

  6188   Thu Jan 12 07:44:21 2012 steveUpdateSUSsapphire wire standoff quote


On Tue, Dec 20, 2011 at 11:37 PM, Rana Adhikari wrote:
Steve,

We are thinking of replacing a few metal parts in the suspension with sapphire/ruby. We want to replace the standoff (which is Al) with sapphire and also the top plate where the wire is clamped.

For the top, we should make a cutout for a little plate in the existing crossbar. In the cutout would go a little mounting plate. Then the clamping plate (which is now steel) we would also replace with a Sapphire one.

I don't think it matters whether its sapphire or ruby, just has to be very hard.

Can you please get some quotes on the parts?

rana

Attachment 1: standoff.PDF
standoff.PDF
  6194   Thu Jan 12 23:19:56 2012 KojiUpdateSUSc1iscex is fine now

c1iscex is working as before and the optic is damped.


What I checked

1. I went to the X-end rack. I found the io-chassis was turned off.

2. I shutdown c1iscex, turned off, and turned on everything. Again, we did not have any signal from the ADC into c1scx model.

However, I found that c1x01 indicates healthy ADC signals.
This means that the connection between the IOP and the c1scx model was wrong ==> Simulated Plant

3. Burtrestored X'mas eve snapshot. This restored the gains and matrices as well as C1:SCX-SIM_SWITCH
which switches the input between the real ADCs and simulated plant.

4. The signals came back to c1scx.

  6232   Fri Jan 27 09:05:41 2012 steveUpdateSUSOSEM locking plunger

Quote:

Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.

Problems:  1, they become magnetized after years being close to the magnets

                     2, they oxidize by time so it is hard to turn them

                    

I looked around to replace them.

Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.

Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50

 In order to get a better price from Vlier's Tom Chen I changed Ti body back to SS304L-siver plated and music wire spring. The price is still ~$120 ea. at quantity 50

I will talk to Mike G about modifying the  McMaster plunger with a hex nut.

  6233   Fri Jan 27 13:13:03 2012 JenneUpdateSUSITMs tripped

Sitting down to start cavity measurements, I found both ITMs tripped.  It must have happened a while ago (I didn't bother to check dataviewer trends) because both had rms levels of <5 counts, so they've had a while to sit and quiet down.

  6238   Mon Jan 30 23:10:02 2012 kiwamuUpdateSUSdrift mon script needs to be fixed

[Rana / Kiwamu]

We tried to set some parameters for the suspension drift monitor but the old matlab script, which automatically sets the values, didn't run because it uses the old mDV protocol.

The attached link below is a description about the script.

https://wiki-40m.ligo.caltech.edu/Computers_and_Scripts/All_Scripts#Drift

It needs to be fixed or upgraded by pynds.

  6252   Fri Feb 3 19:57:26 2012 ranaConfigurationSUSPSL Shutter closed for SUS hysteresis test

Fri Feb 03 19:57:20 2012

Fri Feb 03 20:25:19 2012 :   Aligned all SUS to center their OL beams

Fri Feb 03 20:29:21 2012:    Aligned all SUS to make OL_PIT = 0.5

  6253   Fri Feb 3 20:19:38 2012 ranaUpdateSUSOplev QPD Sum Trends are suspicious

The attached trend shows a problem with the QPD sums.

Why are ETMX and ITMX so much lower than ETMY and ITMY? Are the laser's dying? Or is it the gain inside the QPD? Or the reflectivity of the coatings?

Steve - please check on Monday the laser powers and the ETM/ITM reflectivity for HeNe lasers. Maybe we have to increase the transimpedance gain in the heads.

Attachment 1: a.png
a.png
  6255   Fri Feb 3 23:19:22 2012 ZachUpdateSUSOSEM testing begins

I took one of the spare OSEM satellite amps (schematic) from the cabinet down the Y arm this afternoon to begin testing. I spent most of the day amassing the melange of adapters and connectors I needed to talk to the relic. The most elusive was the über-rare 64-pin IDE connector, for which neither the 40m nor Downs or Bridge had a breakout (despite there being several Phoenix boxes on each electronics rack at the 40m---hmm...). The solution I came up with was to make a breakout cable myself, only there was no 64-pin ribbon. So, I carefully fed a 50-pin and most of a 16-pin ribbon side by side into one push-down connector, and that was that:

IDE64_homestyle.png

I also finally found a 25-pin D-sub breakout just after figuring out the proper pinout for a 25-to-9 adapter, which I thought I was going to have to use. OH WELL.

Science

The first thing I figured I'd do is measure the LED drivers' current noise and see how it compared with LISO. I powered the box up and found that the TO-3 7815 regulator was putting out +20V---bad. I assumed it was broken, so I got another one from Downs and replaced it. Powered it up again and the output was still at +20V (WTF?). My suspicion is that one of the shielding capacitors has failed in some bizarre way, but I didn't have time to check this before I was beckoned to another task. This is where I'll start again next.

Another thing Frank and I noticed as we were figuring out how the driver worked was that the current-specifying resistor of one of the driver stages had not been properly modified along with the others, so it was forcing the feedback loop to rail. This mod was done precariously by adding two perpendicular sandwiched "Radd" resistors on top of the main one, so it's also possible that the ones for this stage had just been knocked off somehow (perhaps by the massive gender-switching ribbon chain hanging down on it). Steve and I noticed that there was a label on the box complaining that some part of the amp for one of the OSEMs wasn't working, but we peeled it off and threw it away because he figured it was outdated.

Anyway, in short, the plan going forward is as follows:

  • For this box
    • Measure the LED driver and PD transZ amp noises with dummy components
    • Compare with LISO to make sure they make sense
    • Measure the noise again with an OSEM connected
    • Based on the above and more LISO modeling, decide if it's a good idea to replace the LT1125's with OP497's
    • Increase the dynamic range by allowing +/-10V output, rather than +/-2V as was needed for old ADCs
  • After
    • Systematically mirror the changes in all other boxes by switching one out at a time

Comments welcome.

  6256   Mon Feb 6 11:07:21 2012 steveUpdateSUSOplev QPD Sum Trends are suspicious

Quote:

The attached trend shows a problem with the QPD sums.

Why are ETMX and ITMX so much lower than ETMY and ITMY? Are the laser's dying? Or is it the gain inside the QPD? Or the reflectivity of the coatings?

Steve - please check on Monday the laser powers and the ETM/ITM reflectivity for HeNe lasers. Maybe we have to increase the transimpedance gain in the heads.

ETMX and ETMY have 0.2 mW returning to their QPDs........so the gain must lower at  ETMX

ITMX laser 1103P has only 0.67 mW output and 0.025 mW returning to the QPD.

ITMX and ETMX oplev lanching paths  have lenses without AR coating. This is my fault. I will buy them.

          ETMX   0.2 mW           900 counts

         ITMX     0.025           1300

         SRM      0.04            2600

          BS      0.05            3500

          PRM     0.06            4000

         ETMY     0.2             9000

        ITMY      0.3            14500

Attachment 1: oplevsums.png
oplevsums.png
  6257   Mon Feb 6 17:06:11 2012 steveUpdateSUSoplev transferfunction of PIT: ETMY & ETMX

Kiwamu showed me how to do transferfunction of oplev pitch

Attachment 1: ETMX_PIT.png
ETMX_PIT.png
Attachment 2: ETMY_PIT.png
ETMY_PIT.png
  6258   Tue Feb 7 03:05:08 2012 ZachUpdateSUSOSEM sat amp measurements

I did some more investigation on the OSEM box today.

Troubleshooting:

After removing some capacitors and still finding that the +15V rail was at over +20V, I decided to see if the TO-3 7815 that I removed behaved properly all by itself. It did. After some more poking around, I discovered that whoever assembled the board isolated the case of the regulator from the board. It is through the case that this package gets its grounding, so I removed the mica insulator, remounted the regulator, and all worked fine.

Since I had gotten a spare from Downs, I also replaced the LT1031 (precision 10-V reference), for fear that it had been damaged by the floating voltage regulator.

 

Noise measurements:

sat_amp_measurement_setup.png

LED Driver

With the above out of the way, I was finally able to take some measurements. The first thing I did was to look at the LED drivers. I fixed the one stage that I mentioned in my last post by adding two 820-ohm resistors in parallel with the 1k, such that it was very close to all the others (which are 806 || 806 || 1k). With that, using a red LED, I measured a current of 34.5 mA (+/- 0.1) out of each of the 5 stages (UL, UR, LL, LR, S).

I then measured the current noise of each one by monitoring the voltage across the 287-ohm resistor in series with the LED. The driver works by putting the LED in the feedback path of an inverting amp. There is a 10-V input from the LT1031, and the values of the input and feedback resistors determine the current drawn through the LED. There is a buffer (LM6321) in the path to provide the necessary current.

The LISO model I made according to that description seems to make sense. I simply modeled the LED as a small resistor and asked LISO for the current through it. The transfer function shows the proper DC response of -49.15 dB(A/V) -->  34.8 mA @ 10 V, but, the estimated current noise doesn't add up with the measured levels:

LED_driver_vs_liso.png

I have to get to the bottom of this. Two possibilities are: 1) The buffer adds noise, and/or 2) I am modeling this invalidly.

PD Amp

I also began measuring the PD amplifier noise levels, though I only measured two of them for lack of time. I find it odd that there is a 100-ohm input series resistor on what I thought would be just a transimpedance amplifier. For that reason, I want to look into how the OSEMs are connected to this guy.

In any case, I measured the output noise of two of the PD amps by shorting the input side of the 100-ohm resistors to ground, and then I divided by their TF to get the input noise level. Here it is compared with the LISO estimate. I have plotted them in units of voltage noise at the input side of the resistors for lack of a way to infer the equivalent photocurrent noise level.

pd_amp_vs_liso.png

Above 2 Hz or so, the measured level agrees with the prediction. Below this, the measured noise level increases as 1/f, while it should go as the standard 1/sqrt(f) (the manufacturer-quoted 1/f corner is at 2 Hz). Another thing to get to the bottom of.

  6259   Tue Feb 7 16:30:46 2012 steveUpdateSUS ALL oplev PIT transfer functions

SUS- BS, ITMX, ITMY, PRM, SRM, ETMX & ETMY_OLPIT transfer funtion with sine wave excitation 0.1 amplitude:

 

Attachment 1: BS_PIT.png
BS_PIT.png
Attachment 2: ITMX_PIT.png
ITMX_PIT.png
Attachment 3: itmy_pit.png
itmy_pit.png
Attachment 4: PRM_PIT.png
PRM_PIT.png
Attachment 5: SRM_PIT.png
SRM_PIT.png
Attachment 6: ETMX_PIT.png
ETMX_PIT.png
Attachment 7: ETMY_PIT2.png
ETMY_PIT2.png
  6260   Wed Feb 8 16:37:02 2012 steveUpdateSUSITMX OSEM LL is sick

I'm driving C1:SUS-ITMX_OLYAW and PIT_EXC with amplitude 0,1-0.3 while taking transfer funtions of oplev.

The transfer functions are normal. However I noticed that the LL osem is not responding to this excitations

Healthy sensor respons should be like Atm3

Attachment 1: ITMXsensorLL.png
ITMXsensorLL.png
Attachment 2: ITMXsensorLLyaw.1.png
ITMXsensorLLyaw.1.png
Attachment 3: ETMX.2amplPIT2.png
ETMX.2amplPIT2.png
  6261   Thu Feb 9 12:38:15 2012 ZachUpdateSUSOSEM LED driver noise

Frank pointed out to me that I had dumbly forgotten to include the voltage reference's noise. The LT1031 has an output noise level of ~125 nV/rHz above 10 Hz or so, and this at least makes the estimate much closer. I had also not included an extra LT1125 stage between the reference and the other stages. I guess I was tired.

LED_driver_vs_liso.png

The estimate is now within a factor of a few of the measured level, and it has roughly the right shape. Around 1 Hz, it looks like the measured data begin to roll up away from the model, though it's tough to say due to the effect of the AC coupling on the analyzer less than a decade below. If there is indeed extra noise here, Frank thinks it could be due to resistor current noise.

I'll switch one or two out for nicer ones and see if things change.

  6263   Thu Feb 9 16:46:02 2012 steveUpdateSUS ALL oplev YAW transfer functions

Quote:

SUS- BS, ITMX, ITMY, PRM, SRM, ETMX & ETMY_OLPIT transfer funtion with sine wave excitation 0.1 amplitude:

 

OL_YAW transfer functions are here.

 I had two PHDs helping me to overlap the EXML files in DTT. We failed. This job requires professorial help.

Attachment 1: BS-OLYAW.1ampl.png
BS-OLYAW.1ampl.png
Attachment 2: ITMX-OLYAW.1ampl.png
ITMX-OLYAW.1ampl.png
Attachment 3: ITMY-OLYAW.1ampl.png
ITMY-OLYAW.1ampl.png
Attachment 4: PRM_OLYAW.1.png
PRM_OLYAW.1.png
Attachment 5: SRM_OLYAW.1ampl.png
SRM_OLYAW.1ampl.png
Attachment 6: ETMX-OLYAW.1ampl.png
ETMX-OLYAW.1ampl.png
Attachment 7: ETMY-OLYAW.1ampl.png
ETMY-OLYAW.1ampl.png
  6264   Thu Feb 9 17:11:05 2012 steveUpdateSUSmore OSEM problems

These observations of the OSEMs  were taken while taking transfer functions of oplev YAW at excitation amplitude 0.1

 

 Atm1,  C1:SUS-ETMX_SENSOR_SIDE cross coupling

Atm2,   C1:SUS-ITMX_SENSOR_LL   not excitable

Atm3-4,   BS and PRM  insensitive

 

Good OSEM list: ITMY, ETMY and SRM

 

Attachment 1: ETMXosemEXC0.1ampl.png
ETMXosemEXC0.1ampl.png
Attachment 2: IMTX-YAW0.1.png
IMTX-YAW0.1.png
Attachment 3: BSosemEXC.1ampl.png
BSosemEXC.1ampl.png
Attachment 4: PRMosemEXC.1ampl.png
PRMosemEXC.1ampl.png
  6267   Fri Feb 10 02:43:37 2012 ZachUpdateSUSOSEM LED driver noise *reduced*

I worked on the OSEM box a little more today, with the hopes of reducing the measured output current noise. I succeeded, at least modestly. It turns out that most of the noise was indeed caused by the crappy resistors.

Below is the circuit for one of the 5 LEDs. The output of the op-amp structure directly after the LT1031 reference is split between 5 stages identical to the structure on the right. I have shown just one (UR) for clarity. The various measurement points are explained below.

circuit.png

I started from the beginning of the circuit, directly after the LT1031, to make sure that the excess noise seen the other day wasn't just from a noisy reference. Below is the measured output voltage noise along with the LISO estimate. Clearly, the LT1031 is performing to spec (as it should, since it's a new part that I just put in). Note that the apparent better-than-spec performance at low frequencies is just from the AC coupling, which I needed due to the high DC level.

LT1031_vs_liso.png

Since the reference was in order, the next step was to switch out some of the crappy old resistors for nicer thin-film ones. In case anyone is interested, Frank has done some detailed investigation of excess 1/f current noise in resistors. I measured the voltage noise level at the point labeled "inter-stage measurement" above, first without any modifications and then after swapping the old 10k resistors (R1 & R2) out for nice Vishay thin-film ones. There is clearly a big improvement, and the modified circuit essentially agrees with LISO now down to 1 Hz. Below this, it looks like there could still be an issue.

interstage_vs_liso.png

I wanted to see what the improvement was in the overall output current noise of the system, so I went about measuring the current noise as I had the other day (by measuring the voltage noise across R55 and dividing by the resistance). The performance was already better than the old measurement, but not at the LISO level. So, I replaced the current-setting resistors (R54 & R55)---which were actually 3 parallel resistors on a single pad in each case---by nice Vishay ones, as well. I didn't have any that were close to the original resistance of ~287 ohms, so I put three 1k ones in parallel. This of course shifts the resistance up to 333 ohms, but that only causes a ~16% change in current. I was sure to convert voltage noise into current noise with this new resistance, though.

With this change, the total output current noise is now very close to the LISO estimate as well down to ~1 Hz.

LED_driver_vs_liso.png

Some notes:

  • First, I apologize for the noise margin at higher frequencies. I redid the higher frequency measurements with an SR560 as a preamp, but I must have screwed up the calibration because the data don't match up quite right with the LF measurements. It was clear while I was taking them that they followed the LISO trace.
  • There still seems some excess noise below 1 Hz. It could be that the noisy resistors in the parallel stages were somehow still contaminating the cleaned-up channel. I'll look into this more soon.
  6270   Fri Feb 10 15:46:59 2012 steveUpdateSUSruby wire standoff

Finally I found a company who can do Koji's improved  -hard to make-  specification on ruby or sapphire wire standoff.

NOT POLISHED excimer laser cut, wire groove radius R 0.0005" + - 0.0002"

$250 ea at 50 pieces of order

  6278   Tue Feb 14 08:22:27 2012 steveUpdateSUSsus damping restored

ITMX, PRM and BS watchdogs are tripped. They were restored.

Stable MC was disabled so I can use MC_REFL 1 W beam to measure green glass .

ELOG V3.1.3-