40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 127 of 327  Not logged in ELOG logo
ID Date Author Type Category Subject
  10103   Wed Jun 25 17:49:36 2014 HarryUpdateGeneralRazorblade Analysis Pt. 2

Reconfigured razorblade analysis setup on the PD table as per instructions. Used it to collect data to calculate beam waist with, analyses to follow.

See attached schematic for optical setup.

Attachment 1: RazorbladeSetup.pdf
RazorbladeSetup.pdf
  10102   Wed Jun 25 17:13:10 2014 NichinUpdateElectronicsLaser power check - PDFR system

[Nichin, Manasa]

I wanted to make sure Alex's system of Diode laser + laser controller + optical splitter was working fine and then make a manual measurement for AS55 PD. Manasa was supervising my work and helping me with unhooking the fibers and taking power meter readings. I have tuned on the power to REF DET from under the POY table.

I switched on the laser sitting in the 1Y1 rack and turned up the driving current to 240mA. On checking the laser power readings at AS55 (AS table) and REF DET (POY table) simultaneously, we got readings of 1.6mA and 2.4mA respectively. This much difference in readings was not expected and I did not continue taking the readings for transimpedence measurement.

I will rectify if this unequal splitting of power by the 1x16 optical splitter is going to cause any difficulties for the automated PDFR system measurement technique and resolve it if needed.

 

  10101   Wed Jun 25 14:52:22 2014 Andres MedinaUpdateelogPlacing a lens between the steering mirrors and another lens between the second steering mirror and the cavity

 I was asked to calculate the lenses that we need in order to obtained a Gouy phase close to 90 degrees between the two mirrors that are in the Xend green. Yesterday, I measured the distances between the mirrors, and the distance between the mirror relative to the cavity as illustrate in the image attached below. I looked in to the 40m elog and Manasa did the last update on the length of the cavity. She measured 37.7 + 0.05m. The waist size of the beam that was measured by Annalisa in ID 8637 after the Faraday was w0=2.943e-5m @ -0.039m. I calculated the waist size inside the cavity, and I found a waist of w0=2.2 mm. My plan this week is to keep working in the calculation and finish all the calculation this week so that next week I can go inside and place the lenses. 

Attachment 1: SchematicForXendGreenGoingToTheCavity.pdf
SchematicForXendGreenGoingToTheCavity.pdf
  10100   Wed Jun 25 09:30:44 2014 HarryUpdateGeneralWeekly Update

See attached weekly update

Attachment 1: Weekly_Update—June_25_thru_July_1.pdf
Weekly_Update—June_25_thru_July_1.pdf
  10099   Wed Jun 25 09:17:33 2014 Harry, ManasaUpdateGeneralRazorblade Beam Analysis Setup

Quote:

Harry will update this elog with details about his beam waist measurements for the old NPRO on the SP table.

 see http://nodus.ligo.caltech.edu:8080/40m/10098 for the update

  10098   Wed Jun 25 09:16:52 2014 HarryUpdateGeneralRazorblade Measurements

Purpose

To use a razorblade to measure beam waist at multiple points along the optical axis, so as to later extrapolate the modal profile of the entire beam. This information will then be used to effectively couple AUX laser light to fibers for use in the frequency offset locking apparatus.

Data Acquisition

1) Step the micrometer-controlled razorblade across the beam at a given value of Z, along optical axis, in the plane orthogonal to it (arbitrarily called X).

2) At each value of X, record the corresponding output of a photodiode, (Thorlabs PD A55) here given in mV.

3) Repeat process at multiple points along Z

Analysis

Data from each iteration in the X were fitted to the error function shown below.

V(x) = A*(erf((x-m)/s)+c)

In the Y, they were fitted to:

V(x) = -A*(erf((x-m)/s)+c)

'A' corresponds to an amplitude, 'm' to a mean, 's' to a σ, and 'c' to an offset.

(Only because in Y measurements, the blade progressed toward eclipsing the beam, as opposed to in the X where it progressively revealed the beam.

These fits can be solved for x = (erf-1((V/A)-c)*s)+m1  which can be calculated at the points (Vmax/e2) and (Vmax*(1-1/e2)). The difference between these points will yield beam waist, w(z).

Conclusion

Calculations yielded waists of: X1=66.43um, X2=67.73um, X3=49.45um, Y1=61.20um, Y2=58.70, Y3=58.89

These data seem suspect, and shall be subjected to further analysis.

 

Attachment 1: 40m.zip
  10097   Wed Jun 25 02:01:21 2014 NichinSummaryGeneralWeekly Report

 Attached is the weekly work plan / equipment requirement / lab expert's presence needed for the upcoming week.

Attachment 1: Nichin_Week4_update.pdf
Nichin_Week4_update.pdf Nichin_Week4_update.pdf
  10096   Wed Jun 25 01:18:24 2014 AkhilUpdateelogWeekly Update

 Plans for the Week:

  • Phase and noise characterization of the UFC RF Frequency Counter.
  •  Characterization of the temperature actuator.

Progress and Problems Faced:

  • Since past two days, I have been trying to measure the phase difference between the input and output signals of the FC using a 16 bit ADC ADS1115 (for input phase measurement) on Raspberry Pi(RPI).For that I have assembled a Circuit on a breadboard( Details will be mentioned in my next eLog). 
  • The interfacing and the codes seem to be alright but the RPI is not able to detect the address of the ADC chip. I will try to debug the issue as soon as possible and try to take data through the Pi so that I can have both delay and noise introduced by the FC.
  • Now since the minimum sampling time of the FC has been brought down to 0.1s, I will test how accurately the FC is writing values every 0.1 s for a modulating input.
  • The output data of the FC will be fitted into the input and the order of accuracy will be presented.Also the gain plots will be plotted at higher frequencies like 50 MHz, 100 MHz, 500 MHz and 1000 MHz using the network analyzer.

Work Inside the Lab:

  • On Friday Morning I will  go inside the  lab with Manasa to make measurements from the NPRO to characterize its response to the temperature.
  • I will be in the lab in the morning session(9 am- 1 pm) and make the required measurements. I will then analyze the data and by the end of the week will finish characterization of the FC and temperature actuator.
  • For the rest of the time in this week, I'll be on my desk and will not be entering  the lab.

Electronics Required:

  • I will require the network analyzer on Wednesday and Thursday to make measurements at higher frequencies(30 MHz <F<1000 MHz) from the R PI.

Goal- By the end of the week:

  • To characterize both the FC and the NPRO that would go into the FOL-PID loop.
  • The FC will be ready to replace the network analyzers that are currently being used in the 40m.

 

 

 

 

 

  10095   Tue Jun 24 22:46:15 2014 ericqUpdateComputer Scripts / Programsop340m crons

Quote:

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

 We had fiddled with the scripts/general/scripto_cron script to try and get the MC auto locker working on ottavia, but in doing so broke op340m's reliance on it to run it's cron jobs, like FSSSlowServo.

I've reverted scripto_cron to its original state, and the FSS slow servo starts up again.  

However, scripts like this that we want to always have on seem to be a better fit, to me, for the init system, like we do with daqd and nds on the FB. op340m's inittab looks different than what I'm used to, so I'm not making any changes; this is just a thought. 

MC autolocker is still being ran from an Ottavia GUI terminal; I'll try to get it consistently running on megatron, as suggested in  ELOG10039, now that caget/caput issues seem to be sorted. 

Addendum: I've changed the MC auto locker script to have megatron as its host. Haven't yet gotten it to run automatically; it's running in a detached tmux terminal. I'll finish it up tomorrow. 

  10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

  10093   Tue Jun 24 16:52:43 2014 NichinUpdateElectronicsAn RF cable re-installed

Quote:

 [Nichin, Eric G]

As mentioned in Elog 10062, we found RF cables running between demodulators in rack 1Y2 and RF switch in 1Y1 to have bad SMA connectors (No shield / bad soldering / no caps).

we pulled out all the cables belonging to PD frequency response measurement system , 8 in total, and all of them about 5.5m in length.

Their labels read :

REFL33, REFL11, REFL55, AS55, POX11, REFL165, POP22 and POP110. 

All of them are now sitting inside a plastic box in the contorl room.

On another note, instead of fixing all the cables ourselves, Steve and Eric G decided to order custom made RF cables from Pasternack as professionally soldered cables are worth it. We have placed an order for 2 cables (RG405-550CM) to check out  and test them before we order all of the cables.

 The new RF cables arrived. But unfortunately we did not realize that RG405 was a Semi-rigid coax cable, with a copper shielding. These are meant to be installed in setups that will not be changed / disturbed. We need to order a different set of cables. The new cables have joined the other cables in the plastic box mentioned above.

For now to check if the old setup is still working, I have installed an RF cable (that we earlier pulled out and looks like in good shape, labelled REFL33) between the AS55 Demodulator output PD RF MON in rack 1Y2 and the network analyzer input. Since Manasa and the others were busy working with the interferometer, I did not switch on the laser and did not take any readings. The power supply to REF DET remains off.

I will continue with the measurements tomorrow morning and also try to get the data wirelessly using Alex's code. 

  10092   Tue Jun 24 13:04:49 2014 Harry, ManasaUpdateGeneralRazorblade Beam Analysis Setup

Harry will update this elog with details about his beam waist measurements for the old NPRO on the SP table.

  10091   Tue Jun 24 13:02:54 2014 ManasaUpdatePSLRingdown PD installed

Quote:

I would like to measure the switching time of the AOM. So I have disconnected the modulation input to the AOM that comes from the ISS. I have also turned OFF the SR560's and the AWG that belong to ISS. 

Pics and cable connections of the state in which the ISS setup was left at, will be updated soon.

I installed a fast PDA10CF along the path of a leaking beam from one of the steering mirrors that direct the main beam to the PMC. This beam was dumped to a razor blade. I removed the razor blade and installed a Y1 to steer this beam through a lens on the PD.

Pics of the layout post-installation will be updated.

Also, I tested the AOM by giving it 0-1V modulation input from the AWG. This has been disconnected after the test. So everything should be as it was pre-testing.

Attachment 1: PSL_ringdown.png
PSL_ringdown.png
  10090   Tue Jun 24 01:07:56 2014 JenneUpdateLSCBootfest 2014!

Still no real luck getting the beam back aligned to the IFO.

Koji and I tried a few minutes of wiggling the input pointing tip tilts (TT1 and TT2) around, and then tried doing some thinking.

We note that the beam propagates (modulo a few pickoffs):

IMC -> Faraday -> TT1 -> MMT1 -> MMT2 -> TT2 -> PRM.

Since moving TT1 to the rails does make beam reflections in the BS chamber move (as seen by movement of the general illumination on the PRM face camera), I posit that the beam is getting through the Faraday.  It is certainly getting at least mostly through the Faraday, although since the MC locked so easily, I assume that we didn't have too much movement after the ~2pm Alaskan earthquake & aftershocks, so we're at pretty much the same alignment as usual, in terms of beam pointing coming from the IMC.

The plan is then to see the position of the beam on MMT1, and steer using TT1 to get the beam to roughly the center.  Then, see the beam propagate to MMT2 (if possible) and TT2 (if possible).    From here, we should be able to see the spot on PRM.  We should be able to use TT2 to tweak things up, and get the beam back to about the right place on POP, or REFL, or somewhere farther along.  Hopefully at this point, we'd see some flashes in the Yarm. 

Using a spare Watek camera, I was able to capture a shot of the face of MMT1.  This is when the TTs were restored to their values that were saved last Monday.  I checked, and this is also roughly the center of the actuation range of TT1, for both pitch and yaw.

MMT1_face_23June2014_2315pm.png

I am not able to see the face of MMT2, or TT2.  If I leave TT1, and move TT2, I am not able to see any movement of any beam or reflections seen in the PRM face camera.

Koji and I are checking the MC spot positions, but it may be time to leave this for the morning crew.

EDIT:  The MC spots were actually pretty bad, and the WFS were working really hard.  Koji realigned the MC suspensions, and now the MC spots are slightly better, although quite similar, to what Manasa measured last week.  The restored TT values still don't give us any flashes in the arms.

  10089   Mon Jun 23 21:16:14 2014 NichinUpdateElectronicsTransimpedence measurement-BBPD

  [Nichin, Koji] 

Today evening, me and koji decided to get down to the problem of why the trasimpedence plots were not as they were supposed to be for Broadband photodiode (D1002969-v8) S1200269. There were a few problems that we encountered:

  • Turns out the REF PD was not illuminated properly, for maximum output. The DC output voltage turned out to be much higher than the previous measurement. Since I assumed that the REF PD had not been touched since the first day I took readings, I did not check this.
  • The fork holding the Test PD was a bit out of shape and only one side of it was clamping down the PD. This made the PD vulnerable swivel about that one side. We replaced it with a new one.
  • I was setting the current diving the Jenne laser to about 20mA and this resulted in nocthes at higer frequencies in the network analyzer due to over driving of the diode laser. Once we reduced this to about 12.5-13 mA they disappeared. Also, the current limit setting was set at 40mA which is way too high for the jenne laser and might have resulted in damaging it if someone had accidentally increased the current. We have now set it at 20mA.

After these changes the measurements are as follows:

I moved the NA from near rack 1Y1 to the Jenne laser table. 

 Acquiring data

  • Jenne Laser driving current: 12.8mA 
  • The following conditions were set on Network Analyzer Agilent 4395:

 

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 801

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 Results

DC output voltage of REF PD: 0.568V

DC output voltage of BBPD: 18mV

Power incident on REF PD and BBPD respectively: 0.184mW  and 0.143mW

Hence, Responsivity for REF PD and BBPD respectively:  0.315 A/W and 0.063 A/W 

Responsivity given in the Datasheet for REF PD and BBPD : 0.68 A/W and 0.1 A/W

 

 

The reason for these differences are unknown to me and must be investigated.

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) S1200269 was around 1kV/A-2kV/A for most of the range, but the value started falling as the frequency approached 100 MHz. This BBPD is best when used at 10-30 MHz.

Attachment 1: BBPD_transimpedence_06-23-2014.pdf
BBPD_transimpedence_06-23-2014.pdf
Attachment 2: BBPD_readings_06-23-2014.zip
  10088   Mon Jun 23 20:58:38 2014 ericqUpdateCDSBootfest 2014!

This afternoon, I wanted to start the nominal alignment/adjustment steps for evening time locking, but got sucked into CDS frustrations. 

Primary symptom: TRX and TRY signals were not making it from C1:SUS-ETMX_TR[X,Y]_OUT to C1:LSC-TR[X,Y]_IN1. Various RFM bits were red on the CDS status page. 

 Secondary symptom: ITMX was randomly getting a good sized kick for no apparent reason. I still don't know what was behind this. 

First fix attempt: run sudo ntpdate -b -s -u pool.ntp.org on c1sus and c1lsc front ends, to see if NTP issues were responsible. No result.

Second fix attempt: Restart c1lsc, c1sus and c1rfm models. No change

Next fix attempt: Restart c1lsc and c1sus frontend machines. c1lsc models come back, c1sus models fail to sync / time out/ dmesg has some weird message about ADC channel hopping. At this point, c1ioo, c1iscey and c1iscex all have their models stop working due to sync problems. 

I then ran the above ntp command on all front ends and the FB, and restarted everyone's models (except c1lsc, who stayed working from here on out) which didn't change anything. I command-line rebooted all front ends (except c1lsc) and the FB (which had some dmesg messages about daqd segfaulting, but daqd issues weren't the problem). Still nothing. 

Finally, Koji came along and relieved me from my agony by hard rebooting all of the front ends; pulling out their power cables and seeing the life in their lights fade away... He did this first with the end station machines (c1iscey and c1iscex), and we saw them come back up perfectly happy, and then c1ioo and c1sus followed. At this point, all models came back; green RFM bits abounding, and TR[X,Y] signals propagating through as desired. 

Then, we tried turning the damping/watchdogs back on, which for some strange reason started shaking the hell out of everyone except the ETMs and ITMX. We restarted c1sus and c1mcs, and then damping worked again. Maybe a bad BURT restore was to blame?

At this point, all models were happy, all optics were damped, mode cleaner + WFS locked happily, but no beams were to be seen in the IFO 

The Yarm green would lock fine though, so tip-tilt alignment is probably to blame. I then left the interferometer to Jenne and Koji. 

  10087   Sat Jun 21 01:46:28 2014 NichinUpdateElectronicsBBPD Transimepedence plot

Sorry for the late update Koji.

There was a bug in my code that was pointed out by koji and here is the revised plot of transimpedence. The correct code attached.

The transimpedence value is unusually high, about 50kV/A-70kV/A for most of the range. The same was observed when the transimpedence was calculated on another BBPD in Elog.

It is highly unlikely that both the BBPDs are faulty and might be because I am doing the calculations wrong. Must dig deeper into this. Maybe it is a good idea to try the shot noise method of calculating the transimpedence and see how the values turn out. Will do that ASAP.

Attachment 1: BBPD_06-18-2014.pdf
BBPD_06-18-2014.pdf
Attachment 2: BBPD_readings_06-18-2014.zip
  10086   Sat Jun 21 01:25:12 2014 NichinHowToElectronicsPD Trasimpedence measurement theory

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

Attachment 1: Transimpedence_Calculation_.pdf
Transimpedence_Calculation_.pdf
  10085   Fri Jun 20 19:09:23 2014 KojiUpdateElectronicsTransimpedence measurement-BBPD

Oh, nice! This must be a new technique to have a higher transimpedance by breaking the PD.

Now both BBPDs are showing abnormally high impedance.
(Remember, you have not revised your
previous entry after my pointing out you have a bug in the code.)

You should break down the measurement into each raw numbers for validation.
And if this high impedance is still true, you should point out what is causing of this anomaly.

  10084   Fri Jun 20 19:07:44 2014 ranaUpdateComputer Scripts / Programsop340m DNS

I had forgotten to fix the DNS setup on op340m and so our slow, perl, PID loops for the laser were not running well (and that's why the FSS-FAST has been saturating).

I edited /etc/resolv.conf on there and then did /usr/sbin/reboot as super-user.

op340m:~>more /etc/resolv.conf
domain martian
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 131.215.139.100
nameserver 131.215.9.49
op340m:~>date
Fri Jun 20 19:06:37 PDT 2014

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

  10083   Fri Jun 20 18:33:53 2014 HarryUpdateGeneralRazorblade Beam Analysis Setup

 Eric Q and I set up the optical configuration for razorblade beam analysis on SP table for future use.

It has been aligned, and will be in use on Monday.

The beam will be characterized for future characterization of optical fibers.

  10082   Fri Jun 20 16:36:44 2014 NichinUpdateElectronicsRF cables removed

 [Nichin, Eric G]

As mentioned in Elog 10062, we found RF cables running between demodulators in rack 1Y2 and RF switch in 1Y1 to have bad SMA connectors (No shield / bad soldering / no caps).

we pulled out all the cables belonging to PD frequency response measurement system , 8 in total, and all of them about 5.5m in length.

Their labels read :

REFL33, REFL11, REFL55, AS55, POX11, REFL165, POP22 and POP110. 

All of them are now sitting inside a plastic box in the contorl room.

On another note, instead of fixing all the cables ourselves, Steve and Eric G decided to order custom made RF cables from Pasternack as professionally soldered cables are worth it. We have placed an order for 2 cables (RG405-550CM) to check out  and test them before we order all of the cables.

  10081   Fri Jun 20 14:42:57 2014 steveUpdateSUSvac illuminators turned off
  10080   Fri Jun 20 11:43:30 2014 ericqUpdateComputer Scripts / ProgramsRestarting ELOG

Manasa let me know that the ELOG was down, and that she used the normal restart procedure, but then all entries were gone. 

This is because the ELOG has been moved on nodus, so going to the old place and running the restart script starts up the old dysfunctional ELOG installation. 

The proper place to restart the ELOG is now nodus:/export/home/elog/start-elog.csh

I'm updating the relevant 40m wiki page now. 

  10079   Fri Jun 20 11:41:18 2014 NichinUpdateElectronicsTransimpedence measurement-BBPD

EDIT: Please ignore the following data. The revised data and plot are in Elog 10089 

Yesterday evening, I conducted the same measurements done in Elog-10059 using the same REF PD (NF 1611) and the same model of BBPD, but on different piece that needed to be checked. 

I moved the NA from near rack 1Y1 to the Jenne laser table and back again after the readings were done.

 Acquiring data

  • The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 1MHz to 300 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedance of  Broadband photodiode (D1002969-v8) was around 50kV/A-70kV/A (Unusually high) for most of the range (2), but the value started falling as the frequency approached 200 MHz.

 

The high impedance might be because the PD is faulty.   

 

 

 

 

Attachment 1: BBPD_readings_06-19-2014.zip
Attachment 2: BBPD_transimpedence_19thJune2014.pdf
BBPD_transimpedence_19thJune2014.pdf
  10078   Fri Jun 20 09:46:49 2014 manasaUpdateIOOMC WFS servo turned ON

The IMC stayed locked last night, but with  a high REFL ~3.0. I found the WFS servo OFF; so went ahead and enabled it. (Did somebody disable it for reasons not elog'd?)

MC returned to a happy state. But the WFS offsets are quite large. So I tweaked the alignment and got MC REFL down to ~0.45 and MC TRANS SUM to ~16500 counts. MC WFS offsets also dropped significantly after this without any need to touch the alignment to the WFS PDs.

  10077   Thu Jun 19 22:04:23 2014 ericqUpdateComputer Scripts / Programscaget/caput now return in reasonable time

I think I've fixed the caget/caput issue. Rana's observation that pinging the IP directly was faster than pinging the hostname set me on a path of googling which informed making the following changes to the DNS setup on chiara (specifically, informed by this thread: http://www.dslreports.com/forum/r11836974-BIND-slow-to-reply-over-LAN-Solved)

/etc/bind/named.conf.local has these lines:

zone "martian" IN {
 type master;
 file "/etc/bind/zones/martian.db";
 };
zone "113.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/zones/rev.113.168.192.in-addr.arpa";
};

The first zone command links hostnames like c1lsc to an IP like 192.168.113.62, but apparently in the second, we need to do the inverse. So, for each line in martian.db like

c1lsc           A       192.168.113.62

I added a line in rev.113.168.192.in-addr.arpa like so:

62 IN PTR c1lsc.martian

This seems kind of silly, but now if you do the host command from a workstation, it can find the hostname associated with an IP. 

controls@pianosa|~ > host 192.168.113.62
62.113.168.192.in-addr.arpa domain name pointer scipe12.martian.113.168.192.in-addr.arpa.
62.113.168.192.in-addr.arpa domain name pointer c1lsc.martian.113.168.192.in-addr.arpa.

[At this point, note that we have a bunch of duplicate entries in https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  with these scipe## hostnames. What are these for?]


 
Now (edited for brevity):
 
controls@ottavia|~ > ping -c 5 -D c1sus
PING c1sus.martian (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- c1sus.martian ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.051/0.075/0.114/0.028 ms
controls@ottavia|~ > ping -c 5 -D 192.168.113.85
PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- 192.168.113.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.052/0.130/0.380/0.127 ms
 
controls@pianosa|~ > time caget C1:LSC-XARM_GAIN
C1:LSC-XARM_GAIN               0.015
real    0m0.039s
 
controls@pianosa|~ > time caput C1:LSC-XARM_GAIN 0.0151
Old : C1:LSC-XARM_GAIN               0.015
New : C1:LSC-XARM_GAIN               0.0151
real    0m0.054s
 
 
 

 

  10076   Thu Jun 19 17:28:19 2014 SteveUpdatePSL window device is ready for test

The window is at the north west corner of the  PSL enclosure.

The 1 mm thick BK7 window is AR coated both side R <0.08%,  W2-PW1-1004-1064-0

The PZT stack is 0.75" OD, 0.25" thick with  ~ 6 mm ID,  motion range 2.5 micron at 200V

Soft silicon rubber isolation.

 

RXA: This is the opto-mechanical phase shifter that Steve has built for diagnosing scattered light problems. We put it into the reflected light path of any of the cavities and see if it can move the scattering noise from DC up to a higher frequency. e.g.:

The paper on this from GEO

Attachment 1: softW2.jpg
softW2.jpg
Attachment 2: softW2b.jpg
softW2b.jpg
  10075   Thu Jun 19 17:11:52 2014 steveUpdatePEMit is warmer today

 The PSL HEPA was running at 30VAC-variac. It is 1 degree C warmer than usual. The HEPA fan motor turned up to 60 V

Attachment 1: warmertoday.png
warmertoday.png
  10074   Thu Jun 19 16:49:15 2014 ranaUpdateComputer Scripts / Programsautolocker running again

  We've noticed that the caget/caput and cdsutils take a long time to return the command prompt. The following two ping commands indicate that it may be related to routing or our new BIND9 DNS setup on chiara.

 

 

controls@ottavia|~ > ping -c 5 -D c1sus

 

PING c1sus.martian (192.168.113.85) 56(84) bytes of data.

 

[1403221338.383403] 64 bytes from 192.168.113.85: icmp_req=1 ttl=64 time=0.114 ms

 

[1403221343.386211] 64 bytes from 192.168.113.85: icmp_req=2 ttl=64 time=0.059 ms

 

[1403221348.387666] 64 bytes from 192.168.113.85: icmp_req=3 ttl=64 time=0.060 ms

 

[1403221353.389736] 64 bytes from 192.168.113.85: icmp_req=4 ttl=64 time=0.059 ms

 

[1403221354.390713] 64 bytes from 192.168.113.85: icmp_req=5 ttl=64 time=0.060 ms

 

--- c1sus.martian ping statistics ---

 

 

 

5 packets transmitted, 5 received, 0% packet loss, time 20007ms

 

rtt min/avg/max/mdev = 0.059/0.070/0.114/0.023 ms

 

 

 

controls@ottavia|~ > ping -c 5 -D 192.168.113.85

 

PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.

 

[1403221463.737857] 64 bytes from 192.168.113.85: icmp_req=1 ttl=64 time=0.078 ms

 

[1403221464.737353] 64 bytes from 192.168.113.85: icmp_req=2 ttl=64 time=0.059 ms

 

[1403221465.737318] 64 bytes from 192.168.113.85: icmp_req=3 ttl=64 time=0.050 ms

 

[1403221466.737316] 64 bytes from 192.168.113.85: icmp_req=4 ttl=64 time=0.052 ms

 

[1403221467.737321] 64 bytes from 192.168.113.85: icmp_req=5 ttl=64 time=0.050 ms

 

 

 

--- 192.168.113.85 ping statistics ---

 

5 packets transmitted, 5 received, 0% packet loss, time 3999ms

 

rtt min/avg/max/mdev = 0.050/0.057/0.078/0.014 ms

 
  10073   Thu Jun 19 14:52:20 2014 not ericqUpdateComputer Scripts / Programscontrol room bashrc change

Quote:

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  It's a very good plan to always inspect the exit code of your command.  Well done.

  10072   Thu Jun 19 14:41:00 2014 ManasaUpdatePSLISS disabled

I would like to measure the switching time of the AOM. So I have disconnected the modulation input to the AOM that comes from the ISS. I have also turned OFF the SR560's and the AWG that belong to ISS. 

Pics and cable connections of the state in which the ISS setup was left at, will be updated soon.

  10071   Thu Jun 19 14:12:45 2014 steveUpdatesafetyoptical table scans

 

 PSL, AP, ETMY and ETMX optical tables were scanned for stay beam.

  10070   Thu Jun 19 12:10:18 2014 AkhilUpdateElectronicsGain plots to Characterize UFC-6000 RF Frequency Counter

The goal is to characterize the Mini-Circuits RF FC (Model UFC-6000)  by plotting Gain Plots.

Work Done:

The sampling rate of the UFC-6000 RF FC is 1s (should look into making the sampling time smaller). So to satisfy Nyquist criterion, the maximum modulation frequency is 0.5 Hz beyond which  aliasing effects are seen.

The measurements taken (mentioned in my previous elog) are used to plot Gain vs Modulation frequency for carrier frequencies of  5 MHz and 25 MHz.

Calculations:

A modulated signal can be represented as X(t)= A*sin (Fc*t+D*sin(Fm*t+phase1))  where Fc and Fm are carrier and modulation frequencies respectively and D is the modulation depth.

This signal Y(t) is input to the FC and the output frequencies of the FC are recorded.

Let the output of the FC is Y(t)= A'*sin(Fc*t+D'*sin(Fm'*t+phase2));

 

Gain = D'/D;

phase = phase2 - phase1;

 

D' is calculated by subtracting the carrier frequency from the output frequency and calculating the amplitude of the resulting fitted sine wave.

The phase can be calculated if the phase of the input is known(which will be done next).

Plotting the Bode plots would give response of the FC to modulation.

 

The plots generated  will be used to estimate:

1) Transfer Function of FC to be known to build an FOL-PID loop.

2) Quantization noise from Power Spectral Density(PSD) vs Hz.

 

To Do Next:

1)Calculate the phase difference  to complete the Bode plot. This would require interfacing of the ADC on raspberry pi.

2)Estimate the quantization noise from the digital output.

 

 

Attachment 1: GainVsFreq.png
GainVsFreq.png
  10069   Thu Jun 19 10:39:22 2014 steveUpdatesafetysurf safety training

 

 Andres Medina and Andrew "Harry" Hall received 40m specific safety training. They did general safety already and their laser safety training will be this after noon.

Attachment 1: 2014surfsAA.jpg
2014surfsAA.jpg
  10068   Thu Jun 19 00:02:48 2014 JenneUpdateLSCPRMI+2 arms recovery

Arms locked in comm and diff with ALS. PRMI locked with REFL33 I&Q while arms off resonance. Having trouble reducing CARM offset, even to get to arm powers of 1.

After Manasa installed the new Xgreen PD, Koji looked at the PSL table alignment with me.  I saw only a very weak beatnote with the X BBPD, even though I could see the beatnote on the Y PD from the leakage of the X beam to the Y PD  (Yend shutter was closed, so just PSL and X greens were on the table).  I had thought that my near-field and far-field alignments were pretty good (actually, I checked them, but didn't feel that I needed to tweak them since Manasa did the alignment this afternoon).  Anyhow, it was just a matter of tweaking up the alignment a bit, and then the X beatnote got up to about -25dBm at a few tens of MHz.  I am starting to question myself if the other BBPD is broken, or if I just not well enough aligned.  Anyhow, the spare is in, we can still have a look at the previous X BBPD, but it may be okay, and it's just me embarrassing myself by not catching an alignment problem.

Anyhow, after the X beat was found, I was able to (on my first try) lock the arms using ALS comm and diff.  (I already had a nice strong Y beatnote, so that didn't need finding, other than temp adjustment of the end laser).  I ran the carm_cm_up.sh script, and it did everything nicely.  I did a quickie check of the phase tracker loop gains, but that should be redone in the morning.

PRMI was a little reluctant to lock, so I played around with the MICH and PRCL gains, but didn't really find any combination that was any better than the usual (+0.8 for MICH, -0.04 for PRCL as I had last night, although I needed to reduce the PRCL gain back to -0.02 to eliminate loop osc). 

After an arm lockloss, I relocked just the PRMI and used awggui to put a line into C1:LSC-PRM_EXC to check the RF PD phasing.  I changed REFL33 from 133.5 to 138.5, and REFL 165 from -142.5 to -152.5.  I didn't think that REFL11 needed changing, and I didn't check REFL55.  I also checked that I could lock PRMI without arms, using both REFL33 and REFL165 - they seemed about the same to me, both stable.  REFL33 has 1's in the input matrix, and I was using 0.07's for REFL165.  The demod phase adjustment didn't really improve PRMI locking while the arms were held off resonance, even if I moved the arms even farther from resonance (usually we do 3nm, I went out to 5nm to see if that helped - it didn't).  I tried REFL165 locking, but that wasn't any good either.  I tried using REFL165 with the arms held off resonance, but that didn't seem to catch at all (at least with REFL33 I was getting short lock blips). 

Anyhow, of the 3 or 4 times that I caught REFL33 PRMI lock and tried to reduce the CARM offset, only one time did I even get to arm powers of about 1 (CARM digital offset of -0.1, with CARM held on sqrt transmission signals), and then it didn't stay for more than a few tens of seconds.  The other few times, it broke lock on the way up to arm powers of 1. 

So, carm_cm_up.sh works pretty well, although perhaps the arm powers of 1 offset reduction needs to be a little slower.  PRMI doesn't catch and hold lock very easily with REFL33, and even less so with REFL165.  It may be useful to try catching lock with REFL11 or 55, and doing a transition over to 3f.  No real progress forward, but we're pretty much recovered.

 

  10067   Wed Jun 18 22:47:48 2014 ericqUpdateCDSRaspberry pi added to martian network

I set up a raspberry pi on the martian network, to be hooked up to a frequency counter for tracking ALS beatnotes. 

The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table are outdated, the name server configuration is now at /etc/bind/zones/martian.db, I need to remember to update the wiki soon. 

In any case, the raspberry pi is called "domenica," is found at 192.168.113.107, and has the standard controls user, with /cvs/cds mounted in the same way as the control room machines. 

Once I'm comfortable with the configuration of the pi, I'm going to take an image of the SD card that serves as its hard drive, so that we can just image new cards for future raspberry pis on the martian network if we ever want them. 

  10066   Wed Jun 18 22:34:44 2014 ericqUpdateIOOcaget frusrtation

Quote:

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

This is still happening. Specifically: on all of the control room computers, calls to caget display the result immediately, but then hang for five seconds (consistently five). We had also seen a situation where calls hang indefinitely on ottavia/pianosa, but a reboot "fixes" this.

Some observations:

  • Front end machines and the FB have proper caget/caput response times.
  • Control room machines have some odd ping behavior when targeting frontends/FB; namely the ping times themselves are ok, but each ping line takes quite some time to show up, which made us think that there is odd network routing issue happening with some network switch. 
  • Front ends and FB get epics from /opt/rtapps, whereas control room machines get epics from /ligo/apps, which has different contents. (Is this for Gentoo vs. Ubuntu? I don't really get why this is the case...). This means different environment setting scripts to be called, so maybe the control room machines are misconfigured in some way for the new name server?

I poked around the network settings on all of these machines, but everything seemed reasonable. Nothing was changed. Rossa and Pianosa have their network settings done through some Ubuntu GUI, but I don't know where the settings are written. I had expected their settings to be in /etc/network/interfaces; maybe we should change this to be consistent with other machines, and easier to administrate via the terminal. 

Despite all this, ezcaread is fine.

  10065   Wed Jun 18 21:53:48 2014 KojiUpdateElectronicsChanges to the PD frequency response measurement system

Not "hot" current but "photo" current. Is this my bad!?

It was me who told Nichin that the DC transimpedance was 200Ohm. But according to this entry I checked the RF transimpedance of AS55 before.
In my code, the DC transimpedance was defined to be 50Ohm. If we believe it, 30mV corresponds to 0.6mA.

Quote:

The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

 

  10064   Wed Jun 18 21:37:11 2014 KojiUpdateIOOMC REFL investigation

[Jenne Koji]

We decided to check the situation of the REFL MC beam path.

- No resolution of the weird MC REFL DC increase
- The reflection from the PD was adjusted to hit the beam dump
- The MC WFS paths were aligned again


Detail:

We found that the reflected beam from the PD was hitting the mount of the beam dump.
So the entire MC REFL path was steered down such that the last steering mirror does not neet to steer the beam.
When the alignment was adjusted so that the reflection from PD hit the beam dump, the beam spot on the small mirror right before the PD
got a bit marginal but it seemed still OK after some tweak.

Then we looked at the reflection value. It is still about 6.5. No change.

As we messed up the entire MC REFL path, we aligned the MC WFS paths again.
This was done with the unlocked MC REFL beam. Once the cavity was locked,
it turned out that it was enough for the WFS too keep the MC locked.

  10063   Wed Jun 18 19:30:28 2014 JenneUpdateComputer Scripts / ProgramsRossa having a better day

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

but now it looks like:

GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

  10062   Wed Jun 18 18:16:26 2014 NichinUpdateElectronicsChanges to the PD frequency response measurement system

[Nichin, Eric G, Koji]

Continuing out work from elog:10037, we wanted to check if the frequency response of AS55. Having figured out exactly how to use the Laser diode controller (LDC 3744C), we hooked up a fiber power meter to the optical fiber illuminating AS55 (that we disconnected from its mount last Friday ) and raised up the current to 150mA to get almost 0.8mW power reading.

When aligning the fiber to illuminate the PD, we found that the beam was pretty wide. So we pulled out the collimator and tweaked it to get a focused beam. The fiber was mounted back and was aligned to get a maximum DC reading. The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

Network analyzer was now connected to the modulation input of the laser and the RF output from REF DET and AS55 (inputs to RF switch at rack 1Y1) were connected as input to measure the transfer function. We got just noise on the scope of NA. So, then we tried REFL33 as the Input and still got nothing (We were also not sure if this PD was properly illuminated, we did not check). However the REF DET was giving a nice response on the scope. Turns out all the PDs were disconnected form the Demodulator (D990511) on rack 1Y2.

On closer inspection the RF cable between domodulator and RF switch that was labelled AS55 had a loose SMA connector at the switch end. I will have to fix that tomorrow . For the time being Koji connected the cable labelled REFL33 to the AS55 demodulator and we finally got a response form the AS55 PD on the NA. However no readings were recorded. The power supply to REF DET was turned off in the end as Eric G claimed that it has been ON for almost a year now, which is not a good thing. Also, we removed the modulation input from NA to the diode laser and terminated the input with a 50ohm terminator.

We planned to pull out and check each and every RF cable (especially the SMA ends for faulty soldering and loose connections) and fix/ replace them as needed.

  10061   Wed Jun 18 18:00:36 2014 ericqUpdateComputer Scripts / Programscontrol room bashrc change

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  10060   Wed Jun 18 17:38:14 2014 JenneUpdateComputer Scripts / Programsautolocker running again

The MC autolocker is once again running on Ottavia, with the nohup command.  

It was hanging for a long time (at least minutes) on the cavput and the caputs in the MC2 tickle on and off scripts.  I claim that there isn't a good reason to not just use ezcawrite, or whatever the latest and greatest fully functioning function is, so I've changed the cavput to a series of ezcawrites, and all of the caputs are also ezcawrites.  Now I don't see any hanging, and the MC locks itself.

This does not solve the scripto_cron issue, so if Ottavia is rebooted, or the autolocker is otherwise killed, it will not start itself up. 

  10059   Wed Jun 18 16:44:55 2014 ManasaUpdateElectronicsBBPD installed for BEATX detection

This BBPD is the spare that we pulled out and is installed for ALSX-PSL beat note detection.

  10058   Wed Jun 18 15:25:06 2014 NichinUpdateElectronicsBBPD Transimepedence plot

 Motivation:

To measure the transimpedence of  the Broadband photodiode (D1002969-v8), using a New focus photodiode (1611) as reference. The amplitude modulated Jenne Laser (1.2mW) was used @20mA

The steps involved in getting the transimpedence:

Acquiring data

  • The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 500KHz to 300 MHz.

2) Number of Points sampled in  the range: 301

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

Plotting

  • The matlab code attached (Trans_plot.m) will then give plots for the absolute values of transimpedence in V/A.
  • Logic involved in the code will be presented clearly in a separate Elog. 

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedence of  Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range (2), but the value started falling as the frequency approached 200 MHz. 

Attachment 1: BBPD.png
BBPD.png
Attachment 2: BBPD_readings_06-18-2014.zip
  10057   Wed Jun 18 13:39:01 2014 ranaUpdateCDScdsutils reverted to version 238

 

 After some email consult with Jamie, I got cdsutils working again by reverting to v238. The newest versions are not compatible with our python 2.6 on Ubuntu 10. And our Ubuntu 12 machines do not have NDS2 clients that work yet.

The read/write commands work at the moment, but the NDS based ones don't yet work on pianosa due to some NDSSERVER flag/setup issue maybe, Jamie ??

controls@pianosa|~ > z

usage: cdsutils <cmd> <args>

Advanced LIGO Control Room Utilites

Available commands:

    read         read EPICS channel value

  write        write EPICS channel value

  switch       switch buttons in standard LIGO filter module

  avg          average one or more NDS channels for a specified amount of seconds

  servo        servos channel with a simple integrator (pole at zero)

  trigservo    servos channel with a simple integrator (pole at zero)


  version      print version info and exit

  help         this help


Add '-h' after individual commands for command help.

controls@pianosa|~ > z read C1:LSC-DARM_GAIN

0.0

controls@pianosa|~ 2> z avg 3 C1:IOO-MC_F

Error in write(): Connection refused

Error in write(): Connection refused

NDSSERVER variable incorrectly defined, or no NDS servers available.

controls@pianosa|~ 1> echo $NDSSERVER

fb

  10056   Wed Jun 18 13:29:48 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

 

 Moral is wrong.

AutoLocker was working fine last night and we observed it to run and do the appropriate mcdown and mcup stuff. Probably something is breaking with it after several hours.

If you have suspicions about the script, best to look through the logs during the first few hours when we had it running yesterday.

  10055   Wed Jun 18 11:57:44 2014 not JenneUpdateLSCIFO alignment recovery

Quote:

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

 Nope, we did not touch any of the PDs other than AS55. I have mentioned in  my elog:10037 what we did exactly.

We just looked at all the other PDs to check if they were being illuminated by the correctly labeled fiber. Nothing other than that.

  10054   Wed Jun 18 11:28:19 2014 ManasaUpdateComputer Scripts / Programsautolocker confusion

Quote:

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

I am NOT convinced that the autolocker script is running or doing anything. The MC was unlocked as of this morning and the autolocker wasn't doing anything to any of the MC servo buttons and sliders. The autolocker control shows that it is 'alive' but it still blinks 'MC down' even after I locked the MC manually. I am suspecting that this might have to do something with the caget and caput in autolock script itself rather than the CRON. I will look into this problem later today.

Moral of the story: The autolocker is not doing its job.

ELOG V3.1.3-