40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 195 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  7539   Fri Oct 12 22:44:49 2012 DenUpdatePEMETMY table

Quote:

Seismic noise on the ETMY table measured to be a few times higher then on the floor in horizontal direction in the frequency range 50 - 200 Hz. Attached are compared spectrums of X, Y and Z motions.

Accelerometers were installed on the ETMY table and nearby ground to measure amplification of the seismic noise due to the table. During this experiment ground and table motions were measured simultaneously.

DSC_4734.JPG     DSC_4736.JPG

Attachment 1: etmy_x_psd.pdf
etmy_x_psd.pdf
Attachment 2: etmy_y_psd.pdf
etmy_y_psd.pdf
Attachment 3: etmy_z_psd.pdf
etmy_z_psd.pdf
Attachment 4: etmy_coh.pdf
etmy_coh.pdf etmy_coh.pdf etmy_coh.pdf
  7538   Fri Oct 12 16:59:26 2012 steveUpdateSUSTT PITCH damping

Quote:

Quote:

 We can only decide the need of pitch damping when the coils are activated.

Could you tell us why? Are you thinking about induced current damping?

      I  was wrong The instability will be the same when the coils are actuated.

  7537   Fri Oct 12 15:31:03 2012 RijuparnaConfiguration cavitymode scan

 Rijuparna, Manasa

Today I have checked the optical layout of the MC transmission RFPD table and measured the laser powers at different points. Manasa helped me for that. I found the power entering the RF photodiode is 0.394mW while the transmitted power of the cavity is 2.46mW. (I will give the diagram later).

  7536   Fri Oct 12 14:01:33 2012 KojiUpdateSUSTT PITCH damping

Quote:

 We can only decide the need of pitch damping when the coils are activated.

Could you tell us why? Are you thinking about induced current damping?

  7535   Fri Oct 12 10:39:45 2012 SteveUpdateSUSTT PITCH damping

Quote:

Quote:

  [Koji, Steve, Den]

TT alignment is fine, yaw damping is satisfactory, pitch damping is slow. We might want to add magnets to the mirror and attach blades to the frame for pitch edge current damping.

We are moving towards electronics testing.

Atm1,  TT 1.5" high adaptor base will be back from the shop in 10 days.

Atm2,  There is no PITCH damping, YAW edie current damping works well at 0.5 mm gap

Atm3,  Adjustable Al -disc that contains a small magnet is purely designed.

We have to come up with a solution to have damping in PITCH

 We can only decide the need of pitch damping when the coils are activated.

Attachment 1: IMG_1709.JPG
IMG_1709.JPG
  7534   Fri Oct 12 01:56:26 2012 kiwamuUpdateGeneralAlignment situation of interferometer

[Koji / Kiwamu]

 We have realigned the interferometer except the incident beam.

 The REFL beam is not coming out from the chamber and is likely hitting the holder of a mirror in the OMC chamber.

So we need to open the chamber again before trying to lock the recycled interferometers at some point.

 

--- What we did

  •  Ran the MC decenter script to check the spot positions.
    • MC3 YAW gave a - 5mm offset with an error of about the same level.
    • We didn't believe in this dither measurement.
  •  Checked the IP-POS and IP-ANG trends.
    • The trends looked stable over 10 days (with a 24 hours drift).
    • So we decided not to touch the MC suspensions.
  • Tried aligning PRM
  • Found that the beam on the REFL path was a fake beam
    • The position of this beam was not sensitive to the alignment of PRM or ITMs.
    • So certainly this is not the REFL beam.
    • The power of this unknown beam is about 7.8 mW
  • Let the PRM reflection beam go through the Faraday
    • This was done by looking at the hole of the Faraday though a view port of the IOO chamber with an IR viewer.
  • Aligned the rest of the interferometer (not including ETMs)
    • We used the aligned PRM as the alignment reference
    • Aligned ITMY such that the ITMY reflection overlaps with the PRM beam at the AS port.
    • Aligned the BS and SRM such that their associated beam overlap at the AS port
    • Aligned ITMX in the same way.
    • Note that the beam axis, defined by the BS, ITMX  and SRM, was not determined by this process. So we need to align it using the y-arm as a reference at some point.
    • After the alignment, the beam at the AS port still doesn't look clipped. Which is good.

 

---- things to be fixed

   - Align the steering mirrors in the faraday rejected beam path (requires vent)

   - SRM oplev (this is out of the QPD range)

   - ITMX oplev (out of the range too)

  7533   Thu Oct 11 21:26:40 2012 janoschUpdateGeneralPRC phase maps

Just some plots. There is nothing new here except for the fact that I learned how to analyze phase maps myself and how to prepare them for Finesse. In other words, everything is ready for a Finesse simulation.

These phase maps show the raw measurement of ITMY, ITMX and PRC:

ITM03_HR_raw.pngITM04_HR_raw.pngPRM02_HR_raw.png

Subtracting out the tilt from all phase maps, and the curvature from the PRC (I found the fit 121m consistent with previous fits), the one obtains the following residuals that can be used in Finesse (order is again ITMY, ITMX and PRC):

ITM03_HR_untilted.pngITM04_HR_untilted.pngPRM02_HR_untilted_uncurved.png

Attachment 3: PRC_40m.png
PRC_40m.png
  7532   Thu Oct 11 14:40:20 2012 DenUpdateSUSdiagonalization

Quote:

MC1 diagonalization is poor, better then before, but still pitch is seen in pos and yaw. Either smth is malfunctioning or flags touch sensors and do not move freely. On the plot mc1_new black lines - before, red - after rediagonalization.

 I've manually corrected MC1 input matrix by looking at UL, UR, LL, LR transfer functions between each other. This improved pos significantly and slightly yaw.

Attachment 1: mc1.pdf
mc1.pdf
  7531   Thu Oct 11 12:11:23 2012 jamieUpdateIOOc1ass with new DAC0 output has been recompiled/install/restarted

I rebuilt/install/restarted c1ass.  It came up with no problems.  It's now showing DAC0 with no errors.

After lunch I'll test the outputs.

  7530   Thu Oct 11 12:02:15 2012 DenUpdateIOOFSS

FSS SLOW control did not drift during the lock at night with MCL path working and AC coupled.

fss.png

  7529   Thu Oct 11 11:57:40 2012 jamieUpdateCDSall IOP models rebuild, install, restarted to reflect fixed ADC/DAC layouts

Quote:

As Rolf pointed out when he was here yesterday, all of our IOPs are filled with parts for ADCs and DACs that don't actually exist in the system.  This was causing needless module error messages and IOP GDS screens that were full of red indicators.  All the IOP models were identically stuffed with 9 ADC parts, 8 DAC parts, and 4 BO parts, even though none of the actual front end IO chassis had physical configurations even remotely like that.  This was probably not causing any particular malfunctions, but it's not right nonetheless.

I went through each IOP, c1x0{1-5}, and changed them to reflect the actual physical hardware in those systems.  I have committed these changes to the svn, but I haven't rebuilt the models yet.  I'll need to be able to restart all models to test the changes, so I'm going to wait until we have a quiet time, probably next week.

I finally got around to rebuilding, installing, and restarting all the IOP models.  Everything went smoothly.  I had to restart all the models on all the screens, but everything seemed to come back up fine.  We now have many fewer dmesg error messages, and the GDS_TP screens are cleaner and don't have a bunch of needless red.

A frame builder restart was also required, due to name changes in unused (but unfortunately still needed) channels in the IOP.

  7528   Thu Oct 11 11:36:52 2012 SteveUpdateSUSTT pitch adjustment

Tip Tilt pitch adjustment on existing-in vacuum suspension. This can be added by a simple installation of a 1.25" long 2-56 threaded rod with nuts.

Attachment 1: IMG_1702.JPG
IMG_1702.JPG
  7527   Thu Oct 11 11:20:05 2012 janoschUpdateGeneralbeam shape simulation, PRC

I started to create a Finesse model of the PRC cavity. We have the phase maps for the PRC and the two ITMs. I could not find anything for PR2,3 and BS. All files can be found in my SVN folder /janosch/PRC40m. I used the AutoCAD model to determine angles of incidence and distances. These numbers are largely inconsistent with numbers that you can find elsewhere on the 40m wiki, but this certainly depends on what accuracy is required for interferometer alignment and I don't understand anything about alignment.

The phase maps come in a format that needs to be modified before they can be used in Finesse. I have started with this work, but maybe someone else can take over. The phase maps show tilts and the PRC also has the curvature. These have to be subtracted out before the maps can be loaded into Finesse. I asked GariLynn for the code that they use. The Finesse model (MichPRC_40m.kat) does not load the phasemaps yet, and I just wrote some random parameter values for the TEM00 input beam to the PRC. So these Gauss parameters need to be corrected.

I will only go on with this work if Rana tells me that I should do so, otherwise it is on hold until we have a volunteer.

  7526   Thu Oct 11 01:30:11 2012 DenUpdateSUSdiagonalization

Quote:

MC1 diagonalization is poor, better then before, but still pitch is seen in pos and yaw. Either smth is malfunctioning or flags touch sensors and do not move freely. On the plot mc1_new black lines - before, red - after rediagonalization.

 I've actuated on MC1 with UL, UR, LR, LL coils in turn and measured sensor readings. All coils separately work fine from the first look.

On the plot: black - free mirror, blue - UL coil actuation, green - UR, grey - LR, red - LL.

Attachment 1: mc1_coils.pdf
mc1_coils.pdf
  7525   Thu Oct 11 00:28:30 2012 DenUpdateSUSdiagonalization

I've written MC123 input matrixes to the front-end.

MC1 diagonalization is poor, better then before, but still pitch is seen in pos and yaw. Either smth is malfunctioning or flags touch sensors and do not move freely. On the plot mc1_new black lines - before, red - after rediagonalization.

Attachment 1: mc1_new.pdf
mc1_new.pdf
Attachment 2: mc123_new.pdf
mc123_new.pdf
  7524   Thu Oct 11 00:22:58 2012 SUS_DiagonalizerUpdateSUSOptics kicked

Quote:
All suspended optics have been kicked at Wed Oct 10 21:50:39 PDT 2012. Watchdogs will be reengaged in 90 minutes.


New SUS input matrix diagonalization complete.
  7523   Wed Oct 10 21:50:39 2012 SUS_DiagonalizerUpdateSUSOptics kicked
All suspended optics have been kicked at Wed Oct 10 21:50:39 PDT 2012. Watchdogs will be reengaged in 90 minutes.
  7522   Wed Oct 10 20:27:40 2012 DenUpdateIOOMCL, WFS triggers

I've added MCL and WFS stop triggers into C1MCS/SUS model. Threshold value of MC_TRANS can be changed in the text entry located in MC2_POSITION medm screen. I tried 2 cases: trigger either blocks signal before MCL filter bank input or after output. Due to filter history in the 1 case MC2 was still slightly disturbed (C1:SUS-MC2_ULPD_VAR ~= 15) right after unlock. In the second case there was no disturbance as we zero output signal, but then I had to add "clear history" command to the mcup script.

WFS triggers block the signal before ASCPIT/YAW filter bank.

MC2_POS.png

Attachment 2: mcl.pdf
mcl.pdf
  7521   Wed Oct 10 19:22:03 2012 jamieUpdateIOOAdded control for input tip-tilts to c1ass

I have added some control logic and appropriate output DAC channels for the input tip-tilts (TT1 and TT2) to the c1ass model.

The plan is for all the tip-tilt drive electronics to live in a Eurocrate in 1Y2.  They will then interface with a DAC in c1lsc.

c1ass runs on the c1lsc front-end machine, and therefore seemed like an appropriate place for the control logic to go.

I added and interface to DAC0, and a top_named IOO block, to c1ass:

2012-10-10-185707_566x330_scrot.png

The IOO block includes two TT_CONTROL library parts, one for each of TT1 and TT2:

2012-10-10-191013_470x277_scrot.png

This is just a start so that I can start testing the DAC output.

I have not recompiled c1ass yet.  I will do that tomorrow.

  7520   Wed Oct 10 15:46:23 2012 JenneUpdate cavitymode scan

Quote:

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

 Also, when I walked through the control room later, the WFS were driving the MC crazy.  I turned off / disabled the WFS from the WFS screen.   In my infinite spare time, I need to put in the real-time triggering, so that the WFS turn off as soon as the cavity unlocks. 

  7519   Wed Oct 10 15:31:59 2012 RijuparnaUpdate cavitymode scan

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

  7518   Wed Oct 10 10:55:56 2012 SteveOmnistructureIOOaccess connector at athmoshere

Quote:

Quote:

Quote:

We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

 It is in the shop. It will be ready for the next vent. Koji's dream comes through.

 24" diameter clear acetate access connector is in place. The 0.01" thick plastic is wrapped around twice to insure air and bug tight barrier for the MC to lock overnight. The acetate transmission for 1064 nm is 90 % This was measured at 150 mW   2.5 mm beam size.

 

 Aluminum sheet as shown will replace the acetate. Side entries for your arms and "window" on the top will be covered with acetate using double- sided removable-no residue tape 3M 9425

Attachment 1: 10101202.PDF
10101202.PDF
  7517   Wed Oct 10 08:36:47 2012 SteveUpdateCOCspecial mirror mounts holder

Quote:

After looking at the in-vacuum layout I think we should make two changes during the next vent:

1) Reduce the number of mirrors between the FI and its camera. We install a large silvered mirror in the vacuum flange which holds the Faraday cam (in the inside of the viewport). That points directly at the input to the Faraday. We get to remove all of the steering mirror junk on the IO stack.

2) Take the Faraday output (IFO REFL) out onto the little table holding the BS and PRM Oplevs. We then relocate all 4 of the REFL RFPDs as well as the REFL OSA and the REFL camera onto this table. This will reduce the path length from the FI REFL port to the diodes and reduce the beam clutter on the AS table.

1)  Mirror mount holder for "large silvered mirror" inside of the 8" OD tube vacuum envelope.

Attachment 1: 10101201.PDF
10101201.PDF
  7516   Wed Oct 10 02:20:34 2012 ranaUpdateSUSOptical Lever QPD mods

 Since we upgraded the CDS system, I guess our ADC ranges have gone up but we never did anything to the OLs to match the ADC ranges. From Liz's daily summary page of the OL, I see this:

C1-CORE_OPTICS_SUM_DATA_ALL_TIME_0-1033801216-86400.png

So we need a factor of 5-10 increase in the electronics gain (why isn't the BS SUM on there?). This might be accomplished in the head, but for the ones with whitening boards, might be better to do there.

(** add to Jamie's list of long term tasks **)

  7515   Wed Oct 10 02:15:14 2012 ranaUpdateLSC11 MHz reconnected to EOM

 Absolutely hokey. What are our requirements for this RFPD? What are the power levels and SNR that we want (I seem to remember that its for 22 as well as 110 MHz)? Perhaps we can test an aLIGO one if Rich has one sitting around, or if the aLIGO idea is to use a broadband PD I guess we can just keep using what we have.

  7514   Wed Oct 10 00:18:58 2012 JenneUpdateLockingREFL camera aligned

I moved some of the REFL optics on the AS table by a teeny bit to accomodate the new place that the REFL beam exits the chamber (none of this was done while we were at air....we were only dealing with the AS beam at the time, and were happy that REFL came out of the vacuum).

The REFL beam is now on the REFL camera (with PRMI aligned), and the beam is going toward the 4 REFL RF PDs, but it's not aligned to any of them.

I have some questions as to mystery optics on in the REFL path.  There is a 90% BS, and I don't know where the 10% reflection goes....is it going to beat against the AUX Stochino laser?

I have to go, and I didn't fix the videocapture script today, so pix tomorrow, I promise.

  7513   Tue Oct 9 23:12:56 2012 JenneUpdateLSC11MHz reconnected to EOM

Riju hasn't been in the lab in a long time to do any measurements, so I put the signals back to how they should be. 

I turned off / confirmed off the things which were sending signal to the EOM:  the network analyzer, the RF generator box, and the Marconi which supplies the 11MHz. 

I removed the cavity scanning cable, and terminated it, and put the regular 11MHz cable back on the splitter.

I then turned on the RF gen box and the Marconi.  The Marconi had been off, so we were not getting any 11MHz or 55MHz out of the RF gen. box.  This is why I couldn't lock any cavities last night (duh). 

On to locking!

----------------- In other news,

While swapping out the EOM cable, I noticed that the DC power supply sitting under the POX table was supplying a weird value, 17 point something volts.  I checked on the table to remind myself why that power supply is there...it's powering an RF amplifier right after the commercial PD that is acting as POP22.  The amplifier wants +15 and GND, so I reset the power supply to 15V.  We should add this to the list of things to fix, because it's dumb.  Either we need to put in the real POP22 (long term goal), or we need to get this guy some rack power, and do the same for any amplifiers for the Beat setup.  It's a little hoakey to have power supplies littering the lab.

  7512   Tue Oct 9 17:33:37 2012 jamieUpdateSUSdiagonalization

Quote:

I went inside to align the beam on WFS and noticed that oscillations in yaw are ~10 times stronger then in pitch. I've plot rms of pitch and yaw measured by LID sensors and saw that MC3 yaw rms motion is a few times larger then pitch.

What are "LID" sensors?  Do you mean the OSEM shadow sensors?  I'm pretty sure that's what you meant, but I'm curious what "LID" means.

 

  7511   Tue Oct 9 17:16:14 2012 DenUpdateSUSdiagonalization

I went inside to align the beam on WFS and noticed that oscillations in yaw are ~10 times stronger then in pitch. I've plot rms of pitch and yaw measured by LID sensors and saw that MC3 yaw rms motion is a few times larger then pitch.

Also MC1 input diag matrix does not diagonalize signals for pitch and yaw. In the spectrums of these signals all 4 resonance are equally seen during the free swinging. I think we should rediagonalize MC1.

Another thing is that if MC1 and MC3 are on the same stack,  pitch and yaw spectrums of these mirrors should be comparable. But MC1 signal is ~2-3 times larger then of MC3. I think we should correct calibration.

Attachment 1: mc123_rms.pdf
mc123_rms.pdf
Attachment 2: mc1_diag.pdf
mc1_diag.pdf
Attachment 3: mc123_rms.pdf
mc123_rms.pdf
  7510   Tue Oct 9 09:29:10 2012 SteveUpdateIOOthis is where we are

Quote:

Quote:

 The new cold cathode gauge CC1 is in place. We were at atmosphere for 28 days ......more later

 

 cc1 = 2.3e-5 Torr at day 6 vacuum normal

 

Attachment 1: 15days.png
15days.png
  7509   Tue Oct 9 00:25:33 2012 JenneUpdateIOOPZTs - hacky solution in place!!

[Evan, Jenne]

We applied some volts across both the pitch and yaw pin sets of the ribbon cable that goes to PZT2.  We ended up with ~40V yaw and ~14.5V pitch.  That was the nice happy center of the clipping that we can see on the AS camera.  Once we found the center of the PZT clipping range with the ITMY beam, we recentered the AS camera (actually, this took a few iterations, but now it's good). 

We then aligned MICH, but aren't able to get it to lock.  Before falling asleep, we have decided to align the PRM and SRM, so right now we have a flashing DRMI.  Both the SRMI and PRMI look a little funny the closer you get to 'good' alignment, so I'll investigate a little more tomorrow, and include pictures.  (The video capture script has barfed again, and I'm not in the mood to deal with it today.)

  7508   Mon Oct 8 23:58:57 2012 JenneUpdateSAFETYControl room emergency lights came on

[Evan, Jenne]

We were sitting trying to lock MICH (hooooorraaaayy!!!), and the emergency lights above the control room door came on, and then ~1 minute later turned off.  Steve, can you see what's up?

  7507   Mon Oct 8 22:07:46 2012 ranaUpdateSUSDoors on, ready to pump

Quote:

All oplevs need a little realignment, especially ETMY, which had it's lens removed (Rana has a Wall of Shame photo of this, which is why it was removed by him).  Steve will look into this tomorrow, after he starts pumping.

 The shame:

20120921_200637.jpg

There is no situation in which it is OK to install a mount like this. Steve had installed this flaky and shaky mount to optimize the beam size on the OL QPD.

Everyone in the lab should know better. Putting in something like this is just like sabotage - it creates extra noise in our interferometer in a sneaky way and just makes locking harder. All mounts for anything useful (including QPDs) must have highly rigid mounts. 

Use the example from the PSL relayout: use the 3/4" steel mounts and the wide aluminum bases from Newport. No more art projects using home made mounting crap, Steve.

  7506   Mon Oct 8 21:42:17 2012 JenneUpdateIOOPZT diagnosis - not fixed yet, possible solution

Note to self:

The ENV-40 amplifiers that we have supply -10V through +150V .... so don't exceed those limits.

piezojena link

  7505   Mon Oct 8 18:45:48 2012 JenneUpdateIOOPZT diagnosis - not fixed yet, possible solution

After the fuse-blowing fiasco earlier this afternoon, Koji and I took another look at the PZT controllers.

We put an ammeter in place of the fuse, and watched the current as we turned on the transformer module.  The steady-state current with no other modules plugged in is ~15mA.  However, there is a surge current right when you turn on the box which sometimes goes as high as 330mA.  Since the fuse is 250mA, this explains the fuse blowing, even though Koji had already checked out the low voltage path.

The high voltage line was connected, with +180V to the HV out pin of the backplane connector, and the (-) terminal of the power supply connected to signal ground on the board.

We inserted the PITCH module for PZT2, and we started with ~10V as our "high" voltage, and slowly increased the value (current at this time was ~60mA).  We also had a function generator plugged into the "MOD" input, which is where the epics slider goes, so that we should see a changing output voltage.  We never saw a changing output voltage.  Increasing the HV power supply didn't help. 

When Koji spun the "DC offset" knob really fast and then stopped, sometimes the output voltage as measured on the connector-converter board between the white and red wires would jump up, and then settle back down. It came back to the same value that it always was, but it was bizzarre that it would jump like that.  We suspect that that knob is an offset for use with the closed loop setting, so it isn't relevant for us anyway.  Watching the MON output, the value never changed, even when Koji did his fancy knob twirling.

We switched to the other PITCH module, and watched the output voltage on the MON output.  This time, with the function generator unplugged, so no modulation input (so we were expecting a steady DC output voltage) the number on the LCD and the MON output fluctuated wildly.  We plugged in the function generator, and the fluctuations did not change in approximate amplitude or DC offset.  They kind of looked the same. 

So, we have concluded that (a) the PZT drivers don't work, and (b) we don't understand why.  Therefore, we don't know how to fix them.

With that in mind, we are thinking of totally circumventing the PZT drivers. 

I plugged in the PZT1 connector converter board, which has Koji's circuit that he made last time when PZT1 died.  I plugged the ribbon cable which goes to the PZT, and the +\- 30V power supply, and the PZT responded!  Just plugging in the power supply puts the PZTs near the center of their nominal range.  I then put a function generator on the epics inputs for pitch and yaw (one at a time), and saw the spot move around at the ~1Hz that I was applying.  Yay!

What I think I'll do for tonight - modify the other connector converter board so that I can just use 2 HV power supplies (current limited) to steer the PZT.  I set up a TV monitor next to the PZT electronics (1Y3? 1Y4?  I forget), and it's connected to output 20 of the video switch, so I can watch the AS camera and move the PZTs by hand.  Then maybe I can try to align some stuff. (Evan is coming to work tonight, so if I electrocute myself, someone will be here to call 5000)  Koji suggested buying 2 single-channel thorlabs piezo drivers, like we have on the PSL table for the FSS loop.  These take in 0-10V and output either 0-75V, 0-100V or 0-150V (depending on which setting you choose).  These cost $712 each. This would be a more permanent solution than me just sitting out there, since we could once again control PZT2 via epics.

  7504   Mon Oct 8 14:19:17 2012 JenneUpdateIOOPZT diagnosis - not fixed yet

Quote:

What I will do tomorrow (when there is someone here to rescue me if I crispy-fry myself) is solder a wire to the now open pin of the backplane connector on the HV driver board, so that we can supply an external 180V to the pitch / yaw modules (although, obviously we won't be using the burnt yaw modules as-is).  Tomorrow I'll start by applying a nice small voltage, check that things still look okay, no shorts, and then I'll slowly increase the voltage until I get to the nominal 180V.

 I connected a thick wire to pin 22 of the backplane connector of the transformer / power supply module of the PZT box.  This is the pin that +180V is supposed to go on, to be distributed to the other boards in the crate.  Last week I had drilled a hole in the front panel so the wire can come out (since no one on campus seems to have HV panel mount connectors in stock). 

While the transformer module was isolated, not touching anything else, I applied (slowly ramping up) 180V DC, and it all looked good.

When I plugged the module back into the crate (first turning off and disconnecting the HV), I blew the 250mA fuse again.  No HV yet, just the low voltage stuff that Koji had fixed last week.  :( 

We're now out of 250mA fuses, we're supposed to get a box of them tomorrow.

  7503   Mon Oct 8 12:34:52 2012 DenUpdateModern Controlstate estimation

Quote:

 

 I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

 I think state estimation and optimal control are two different techniques that are often used together. Sometimes (as for pendulum) we can use LQG without state estimation as we need only position and velocity. But for more complex systems (like quad suspension) the states of all 4 masses can be reconstructed in some optimal way using information from only one of them if the dynamics is sufficiently well known. When current system states are measured/estimated we can apply control where all our filters are hidden.

 The algorithm needs to know about expected seismic noise transmission from the ground to the optic, but it might be not very precise. I gave it some rough estimate, there are better ways to do it. I think that we'll understand whether we need state estimation or not when we'll move to more complex systems. Brett uses a similar approach for his modal control. Interesting if these methods + seismometer readings will be able to say if one of your sensors is noisier then others.

 

 

 

 

 

 

 

 

 

  7502   Mon Oct 8 11:44:21 2012 JenneUpdateSUSETMX slow machine fine

Quote:

I think the ETMX slow machine might be dead.  All of the regular FE readbacks are fine, and the c1iscex FE computer looks fine, but the slow readbacks are all whited out. 

I turned off the damping loops for ETMX, since I don't have access to the watchdog disable/enable switch.  I guess checking this out will be task #1 for Monday morning.

 For lack of a better idea, I keyed the crate.  The computer came back up just fine, ETMX is happily damped again.

  7501   Mon Oct 8 11:15:53 2012 JenneUpdatePSLPMC and FSS had a weird weekend

Something bizarre-o was going on with the PMC and FSS over the weekend.  On the striptool, PMC's PZT looks like it was doing a sawtooth pattern for several hours.  I opened up the FSS screen, and the FSS SLOWDC had walked itself up to +10.  It's not supposed to get that far from 0. 

Here are some trends, so you can see what was going on.

10 day trend:  This weird behavior began ~Friday evening (FSS_SLOWDC ramps quickly).

PMC_sawtooth_FSSweird_8Oct2012_10dayTrend.png

1 day trend:  You can see the sawtooth pattern in PMC_PZT more clearly here.  It's at the same time as the FSS_SLOWDC is ramping rapidly, and the FSS_FAST is saturated.

PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png

Attachment 2: PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png
PMC_sawtooth_FSSweird_8Oct2012_1dayTrend.png
  7500   Mon Oct 8 10:56:59 2012 JenneUpdateSUSETMX slow machine dead??

I think the ETMX slow machine might be dead.  All of the regular FE readbacks are fine, and the c1iscex FE computer looks fine, but the slow readbacks are all whited out. 

I turned off the damping loops for ETMX, since I don't have access to the watchdog disable/enable switch.  I guess checking this out will be task #1 for Monday morning.

  7499   Mon Oct 8 09:51:30 2012 ranaUpdateModern Controlstate estimation

 

 I guess that the estimated state has the same low pass filter, effectively, that we use to low pass the feedback signal in SUSPOS. I wonder if there is an advantage to the state estimation or not. Doesn't the algorithm also need to know about the expected seismic noise transmission from the ground to the optic?

  7498   Mon Oct 8 09:45:28 2012 jamieUpdateComputersRebooted cymac0

Quote:

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

For context, there's a is stand-alone cymac test system running at the 40m.  It's not hooked up to anything, except for just being on the martian network (it's not currently mounting any 40m CDS filesystems, for instance).  The machine is temporarily between the 1Y4 and 1Y5 racks.

  7497   Sun Oct 7 23:39:10 2012 DenUpdateModern Controlstate estimation

I've applied online state estimation technique using Kalman filter to LQG controller. It helps to estimate states that we do not measure. I've considered MC2 local damping, we measure position and want to estimate velocity that we need for control. We can either differentiate the signal or apply state estimation to avoid huge noise injection at high frequencies. In state estimation we need to know noise covariance, I've assumed that LID sensor noise is 0.1 nm. Though covariance can be calculated better.

In the time-domain figure C1:SUS-MC2_SUSPOS_IN1 = MC2 postion, C1:SUS-MC2_SUSPOS_OUT = MC2 velocity obtained by differentiation, 2 other channels are estimations of position and velocity.

Attachment 1: est_time.png
est_time.png
Attachment 2: est_freq.pdf
est_freq.pdf
  7496   Sun Oct 7 15:05:42 2012 DenUpdateSUS MC2 sus damping restored

Quote:

This is the third morning in a row that the MC2 was tripped.

 MC2 was tripped again. I think the answer is that watchdog's critical value was too small C1:SUS-MC2_PD_MAX_VAR = 10, so seismic could trip MC2. I've changed the value to 100.

mc2.png

  7495   Sun Oct 7 12:11:00 2012 AidanUpdateComputersRebooted cymac0

I rebooted cymac0 a couple of times. When I first got here it was just frozen. I rebooted it and then ran a model (x1ios). The machine froze the second time I ran ./killx1ios. I've rebooted it again.

  7494   Fri Oct 5 18:08:17 2012 ManasaConfigurationPSLAOM installation

Quote:

Do more investigation to understand what is causing the power reduction.

Is the alignment inadequate? Check the in-lock ccd image.

Is the incident power reduced? (by what?) Use dataviewer.

Is the AOM doing something? Is it active? Then how much power is it eating?

BY THE WAY, how the deflected beam is dumped?
If you don't have anything for blocking the 1st order beam, you have to expect Steve coming to you.

The PMC has been aligned and is all happy happy 

I have installed an  iris to dump the higher order beams deflected by the AOM. After installing the iris, I found that the PMC trans dropped to 0.58V and the PMC misaligned in pitch. So I've touched the 2 steering mirrors before the PMC. Now it is satisfactorily locked with PMC trans at 0.84.

I have also checked the alignment with AOM switched on. PMC trans drops to 0.15 with AOM on and comes back to 0.84 when AOM is switched off without losing lock .

  7493   Fri Oct 5 16:21:48 2012 SteveUpdateGeneralfreshmen visiters

40 plus freshmen visited the 40m today

Attachment 1: IMG_1693.JPG
IMG_1693.JPG
Attachment 2: IMG_1694.JPG
IMG_1694.JPG
  7492   Fri Oct 5 14:53:29 2012 JenneUpdatePSLTTFSS board not fully seated!

[Den, Jenne]

Den noticed that the -15V LED on the TTFSS board was not illuminated.  A further symptom of the FSS being funny was that the PC RMS Drive was constantly high (3.6 ish) and the FAST Monitor was very high, often saturated. 

We took the TTFSS board out, and put an extender card in, and it looked like all of the correct power is being supplied to the board (the +\- 24V LEDs on the extender card were illuminated).  Just to check, we put the board back in, and this time both +\- 15V LEDs came on.  So it looks like the board is fine, it just wasn't seated in there all the way.

Now the readbacks on the FSS screen look good (PC RMS Drive is less than 1, FAST Mon is 5ish), the MC is locked, and I think we're back in business. 

 

  7491   Fri Oct 5 14:40:55 2012 SteveUpdateVACRGA scan after power outage

Quote:

All the front end machines are back up after the outage.  It looks like none of the front end machines came back up once power was restored, and they all needed to be powered manually.  One of the things I want to do in the next CDS upgrade is put all the front end computers in one rack, so we can control their power remotely.

c1sus was the only one that had a little trouble.  It's timing was for some reason not syncing with the frame builder.  Unclear why, but after restarting the models a couple of times things came back.

There's still a little red, but it mostly has to do with the fact that c1oaf is busted and not running (it actually crashes the machine when I tried to start it, so this needs to be fixed!).

 The RGA was not effected by the short power outage.

Attachment 1: afterpoweroutaged10.png
afterpoweroutaged10.png
Attachment 2: pd73m10d.png
pd73m10d.png
  7490   Fri Oct 5 11:11:00 2012 DenUpdatePEMreadout box power

Quote:

Guralp readout box received +13.7 /0/ -15V instead +15V because of the broken fuse. Power provided by the source is normal.

Edit by Den: I've found a similar fuse on one of the tables and borrowed it. Guralp is not working again.

 I've meant Guralp is NOW working again 

ELOG V3.1.3-