Jenne just rebooted c1scy and daqd on the framebuilder. We will do the actual test after lunch.
When I was working on a new front end machine c1sus, I found that make command didn't run and gave the following message.
"make:warning:clock skew detected.Your build may be incomplete"
This was caused by a clock difference between the nfs (nodus) and the terminal machine (c1sus).
I had to set up ntp daemon to synchronize them. Here is a procedure to set up it
- log in to a front end machine
- enable the ntp daemon
- configure the ntpd
vi (emacs) /etc/ntp.conf
vi (emacs) /etc/ntp.conf
- below is the contents I wrote on ntp.conf
server 192.168.113.200 minpoll 4 maxpoll 4 iburst
server 192.168.113.200 minpoll 4 maxpoll 4 iburst
sudo service ntpd start
To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.
For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal. So the offset needs to be manipulated digitally.
We wanted to make aldabella and mariabella know how to work.
What we did:
1. Added 2 lines to /etc/rc.local
mount linux1:/home/cds/ /cvs/cds
2. Edited ~/.cshrc
Working environment is set to aldabella and mariabella. They have their access to the main system, linux1, now.
fstab doesn't work for aldabella and mariabella because the mount should be done after ndiswrapper loads.
mount linux1:/home/cds/ /cvs/cds
Our new Agilent Technology TwisTorr 84FS AG rack controller ( English Manual pages 195-297 ) RS232/485, product number X3508-64001, sn IT1737C383
This controller, turbo and it's drypump needs to be set up into our existing vacuum system. The intake valve of this turbo (V4) has to have a hardwired interlock that closes V4 when rotation speed is less than 20% of preset RPM speed.
The unit has an analoge 10Vdc output that is proportional to rotation speed. This can be used with a comperator to direct the interlock or there may be set software option in the controller to close the valve if the turbo slows down more than 20%
The last Upgrade of the 40m Vacuum System 1/2/2000 discribes our vauum system LIGO-T000054-00-R
Here the LabView / Metrabus controls were replaced by VME processor and an Epic interface
We do not have schematics of the hardware wiring.
We need help with this.
Previous A2L measurement is based on the assumption that actuator efficiencies are identical for all 4 coils.
We thought that the unbelievable "tilt" may be caused by imbalance of the coils.
1. Setup an optical lever.
2. Dither the optic by one coil and demodulate oplev outputs(OL_PIT or OL_YAW) in that frequency.
3. Compare the demodulated amplitude. Ideally, the amplitude is proportional to the coil actuation efficiency.
What we did:
MC2 is the least important, but the easiest.
1. Placed a red laser pointer at MC2 trans table. During the installation, I moved the mirror just before QPD.
2. Made a python script that measures coil actuation efficiency using the above method. I set the driving frequency to 20Hz.
It is /cvs/cds/caltech/users/yuta/scripts/actuatorefficiency.py.
The measurement result is as follows. Errors are estimated from the repeated measurement. (Attachment #1)
MC2_URCOIL 0.953 ± 0.005
MC2_LRCOIL 1.011 ± 0.001
MC2_LLCOIL 0.939 ± 0.006
For MC1, we can use the main laser and WFS1 QPD as an oplev.
But we only have slow channels for QPD DC outputs(C1:IOO_WFS1_SEG#_DC).
So, we intentionally induce RF AM by EOM(see Kiwamu's elog #3888) and use demodulated RF outputs of the WFS1 QPD(C1:IOO_WFS1_I/Q#) to see the displacement.
1. Replaced HR mirror in the MCREFL path at AP table to BS so that we can use WFS1.(see Koji's elog #3878)
The one we had before was labeled 10% pick-off, but it was actually an 1% pick-off.
2. Checked LO going into WFS1 demodulator board(D980233 at 1X2).
power: 6.4dBm, freq: 29.485MHz
3. Turned on the hi-voltage(+100V) power supply going into the demodulator boards.
4. Noticed that no signal is coming into c1ioo fast channels.
It was because they were not connected to fast ADC board. We have to make a cable and put it in.
Is there any place to place an oplev?
- prepare c1ioo channels and connections
- I think we'd better start A2L again than do oplev and coil balancing.
(notes on signal level)
The signal level of the observed peak was -48dBm.
However I was expecting it is like -28dBm with some ideal assumptions.
There may be a 20dB unknown loss which sounds big to me.
The expectation was calculated by using the following simple math.
SIGNAL = A x Z x G_RF x sqrt(P1 / 2) x sqrt (P2 / 2)
where A is the responsibility of the PD and Z is the trans impedance gain. G_RF is a gain of the RF amplifier.
The laser powers of green beams, P1 and P2, are divided by 2 due to a beam splitter.
I was assuming the parameters are like:
A = 0.39 [A/W] (assuming 90% quantum efficiency at 532nm)
Z = 240 [V/A]
P1 = 17 uW (measured by Newport power meter)
P2 = 30 uW (measured by Newport power meter)
G_RF = 23 dB
- What is the actual photocurrent for the beam1 and beam2? We don't care how much power do you have before the BS, but care how much current do you have on the PD.
- How much is the visibility? There is mismatching of the beams. i.e. The beam diameter looked quite different. Also the beams are not TEM00 but have fringes probably comes from the TT mirrors. You maybe able to measure the visibility by the DC output, making the beat freq go through df=0 slowly.
- What is the measured gain of the RF amp? Does it include the voltage division by the output/input impedance?
(Koji, Kiwamu, Yuta)
Lots of progress for the optics placement in the vacuum chamber.
We are ready to go to the next step: open the access connector between IMC and OMC.
The actual work in the vacuum chamber started.
The first goal of the vent is to get the green beam coming out from the chambers to the PSL table.
1. Inspection of the tip-tilt suspension
The alignments of the TTs were inspected. We had five TTs having been sitting on the table in Bob's clean room.
Prior to their installation we checked the alignments of those because they sometimes showed large hysteresis mainly in the pitch directions.
If a TT has the hysteresis, the pitch position doesn't come back to the previous position. This may cause an issue of the interferometer operation.
- SN001, SN003, SN005 looked well aligned and show no hysteresis.
- The alignment of SN002 was not so good (theta ~ 0.004 rad ) compared to those three, but no hysteresis, we think this guy is still acceptable for the installation.
- SN004 had an apparent hysteresis. This guy doesn't come back to the previous place, being applied a touch. We have to fix this at some point.
2. Work in the ITMX chamber
Now all of the optic in this chamber was installed in the approximate place.
- Installed POX/POP steering mirrors.
- TT(SN003) was placed.
- The two steering optics for ITMX OPLEV were placed at the designed positions.
3. Work in the BS chamber
Installed 2 TTs to the BS chamber.
- SR3: TT(SN001)
- PR3: TT(SN005)
After the alignment of the green steering mirrors, we confirmed
the green beam is successfully hitting the west wall of the OMC chamber.
Those TTs are approximately aligned using the weakly reflected green beams.
- Open the access connector
- Place another periscope and two steering mirrors for green
- Damping of the suspended optics
- Resurrect MC and its stable lock
- Remove MCT pickoff path
- Align optics in the main path
- Recycled Michelson lock
I have just received the scheduling of the PSL self work for tomorrow. Gautam and I agreed that if it is needed I will shut the laser off and cover the hole table with plastic.
As we do not have legs for Trillium, I was advised to use shims to adjust the levels. However, they produce extra resonance at ~30 Hz + harmonics. Coherence is lost at these frequencies.
Brian Lantz / Dan Clark are looking around their lab to see if they forgot to ship the feet with the T-240. They had taken the feet off to put it in a pod.
Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it. We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.
The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).
CALIFORNIA INSTITUTE OF TECHNOLOGY
Date: Thursday October 04,2012
This morning at 2:17 a.m. much of the City of Pasadena including our Campus experienced a electric power sag of short duration, approximately 1/10 of a second. The cause was a fault on one of Pasadena’s 17KV circuits. Some sensitive equipment have been impacted.
Contact: Mike Anchondo x-4999
I wanted to measure the RF transimpedance of the WFS heads, as outlined above.
Summary: Measurement is not done.
Uniblitz mechanical shutter installed in the green beam path at ETMY-ISCT The remote control cable has not been connected.
We have tried to ssh into c1iscey yesterday morning. It just did not work. We have just tried it again (now) and it did work.
Lesson learned: always shut down the computer from a TERMINAL Do not turn it off by the manual power switch.
My goal of today was to lock PRMI without using AS55 and it is 50% successful.
The sideband-resonance PRMI (SB-PRMI) was locked with REFL33_I and REFL55_Q for the PRCL and MICH control respectively.
The carrier-resonance PRMI wasn't able to be locked without AS55.
(it looked no clean MICH signals at the REFL ports.)
The motivation of not to use AS55 came from the suspicion that AS55 was injecting some noise into MICH (#5595).
So I wanted to try another RFPD to see if it helps the stability or not.
The lock of SB-PRMI was quite stable so that it stayed locked more than 30 minutes (it ended because I turned off the servos.)
Then I briefly tried DRMI while PRCL and MICH kept locked by the same control loops, namely REFL33_I and REFL55_Q.
The lock of MICH and PRCL looked reasonably robust against the SRCL fringes, but wasn't able to find a good signal for SRCL.
I think I am going to try locking DRMI tomorrow.
- - settings
Demod phase for REFL55 = -45.3 deg
Demod phase for REFL33 = -14.5 deg
Whitening gain for REFL55 = 4 (12 dB)
Whitening gain for REFL33 = 10 (30 dB)
MICH gain = 100
PRCL gain = 8
+ I removed an iris on the ITMY table because it was in the way of POY. See the picture below.
+ I found that burtrestore for the ETMX DC coil forces were not functional.
=> currently ETMX's "restore" and "mislalign" buttons on the C1IFO_ALIGN screen are not working.
=> According to the error messages, something seemed wrong on c1auxex, which is a slow machine controlling the DC force.
The power ratio of the beatnote signal vs. the 216kHz sideband has been measured.
The measured ratio was -55 dB, which is smaller by about 20 dB than Aidan's estimation.
To confirm this fact we should check the modulation depth of the end PDH somehow.
The below is a picture showing the sidebands around the beatnote locked at 66.45 MHz.
Other than the +/-216 kHz sidebands, we can see some funny peaks at +/- 50 kHz and +/-150 kHz
I wonder if they come from the servo oscillation of the MC servo whose UGF is at 24 kHz. We can check it by unlocking the MC.
So, on the vertex PD, the power of the 80MHz +/-200kHz sidebands should be around sqrt(0.15)*0.05 = 0.02 = 2% of the 80MHz beatnote.
Once we get the green and IR locked to the arm again, we're going to look for the sidebands around the beatnote.
Can we set up a fiber-PD on the end table to look at the beat between the "end laser IR beam" and the "PSL IR beam fiber-transmitted end beam"?
We should see the same thing on that PD that we see on the green PD (plus any fiber noise and I'm not really sure how much that'll be off the top of my head). If we unlock the lasers from the arm cavity then the free-running noise of the lasers wrt to each other will probably swamp the 50kHz and 150kHz signals. Maybe we could lock the end laser to the free-running PSL by demodulating the beat note signal from the fiber-PD and then we could look for the extra sidebands in the IN-LOOP signal. Then we could progressively lock the PSL to the MC and arm cavity and see if the sidebands appear on the fiber-PD at some point in that process.
It's possible that the 216kHz drive of the PZT on the Innolight is somehow driving up some sub-harmonics in the crystal. I think this is unlikely though: if you look at Mott's measurements of the Innolight PZT response, there are no significant PM resonances at 50 or 150kHz.
Other than the +/-216 kHz sidebands, we can see some funny peaks at +/- 50 kHz and +/-150 kHz.
When Koji and I were massaging the MC, we noticed that the oscillations were at 48.5 kHz. They were pretty huge and are probably what you're seeing on the beat. My guess is that they are the PZT resonances of the PSL 2W NPRO; we need to put a notch in the FSS box - it still has the notch from the old NPRO.
I made a simple PD test circuit which may allow to test PD response up to few 100MHz.
Its not for low noise, only for characterising PD response.
Here is the circuit:
The 2 capacitor values (for bypassing) are kind of arbitrary, just what I found around
(one medium, one small capacity). Could be improved by better RF types (e.g. Mica).
The PD type has no meaning. I put in the Centronic 15-T5 for a start.
The bias can be up to 20V for this diode.
The signal appears across R1. It is small, to make a large bandwidth.
R2 is just for slightly decoupling the signal from the following RF amplifier.
The wire into the RF amplifier is short (~cm). And the amplifier is supposed to have 50 Ohm
I use a mini circuits ZFL 500 here.
power supply for this is 15V.
I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:
The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.
Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.
Edit by Joe:
I was able to track it down to the spx model not running properly. It needed the Burt Restore flag set to 1. I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag. The data is now circulating all the way around. If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up. So the loop has been closed, just without all the correct filters in.
To get the feeling of the master of IFO, I;
1. Stabilized both arm length using ALS.
2. Ran findIRresonance.py for both arms and find what offset gives me IR resonances.
3. Holded X arm to IR resonance, holded Y arm to IR resonance, and released both arms.
Below is the time series data of what I did.
- Currently ALS is not stable enough. It only stays for about few minutes. I think it is because of the bad alignment of green from each end.
- We can't tell end green frequency is higher or PSL green frequency is higher. So, the sign of the servo filter sometimes flips.
- Wobbliness of X end green transmission beam spot was from the ETMX oplev. When the oplev servo is on, it got more wobbly when X end table is opened. But when the oplev servo was off, wobbliness was same even if the presence of air flow.
- MICH contrast in plot above seems like it somehow got better when two arms are at resonance by ALS. I think this is not real because reflection from both arms at AS port was not well aligned and beam was clipped. Koji and I measured contrast of FPMI and MI(ETMs misalined), and they were 99.6 % and 99.9 % respectively. Beam clipping seems like it comes from some where between BS to AS port. We need to figure out where and fix this.
Things need to be done to make ALS more concrete:
- Align Y end green beam!
- Look into Y end green frequency servo
- How do we hand-off servo using ALS to IR lock?
- Noise budgeting for new phase tracker scheme
- Linearity check of the beat box and phase tracker
We have one single O-ring on the 40m vacuum envelope. It is on the OOC west side, facing the AP table. This O-ring has to be protected from the force of this
door. There should be 3 shims ~120 degrees apart to carry the full load, so it is not the O-ring that is getting squashed.
This morning I found only one of these shims in place.
In the previous elog we've proved that signals C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON are in single precision. Now we try to understand if the precision is lost when the signals enter dtt tools or in the online code. For this measurement we just switch on one of the filters between the signals. By this we add mathematical operations inside the online code. If double precision is used there, then we'll see the same error as before, because the real error is still very small (~10-15) and dtt tools add this 10-7 error. But if the digital error will increase then no matter what kind of precision use dtt, online code uses single precision. At least at some points.
Test 1. cheby1("LowPass",6,1,12)
Test 2. cheby1("Lowpass",2,0.1,3)
Test 3. butter("LowPass",8,10)
Test 4. butter("LowPass",2,10)
We can see that coherence become worse. And longer filter - more digital error. This means that single precision is used in calculations.
[Jamie, Xavi Siemens, Chris Pankow]
We built the skeleton of a new calibration model for the LSC degrees of freedom. I named it "c1cal". It will run on the c1lsc FE machine, in CPU slot 4, and has been given DCUID 50.
Right now there's not much in the model, just inputs for DARM_ERR and DARM_CTRL, filters for each input, and the sum of the two channels that is h(t).
Tomorrow we'll extract all the needed signals from c1lsc, and see if we can generate something resembling a calibrated signal for one of the IFO DOFs.
So it turns out that the card that Rolf had given me was not a Dolphin host adapter after all. He did have an actual host adapter board on hand, though, and kindly let us take it. And this one works!
I installed the new board in c1ioo, and it recognized it. Upon boot, the dolphin configuration scripts managed to automatically recognize the card, load the necessary kernel modules, and configure it. I'll describe below how I got everything working.
However, at some point mx_stream stopped working on c1ioo. I have no idea why, and it shouldn't be related to any of this dolphin stuff at all. But given that mx_stream stopped working at the same time the dolphin stuff started working, I didn't take any chances and completely backed out all the dolphin stuff on c1ioo, including removing the dolphin host adapter from the chassis all together. Unfortunately that didn't fix any of the mx_stream issues, so mx_stream continues to not work on c1ioo. I'll follow up in a separate post about that. In the meantime, here's what I did to get dolphin working on c1ioo:
To get the new host recognized on the Dolphin network, I had to make a couple of changes to the dolphin manager setup on fb. I referenced the following page:
Below are the two patches I made to the dolphin ("dis") config files on fb:
--- /etc/dis/dishosts.conf.bak 2014-04-17 09:31:08.000000000 -0700+++ /etc/dis/dishosts.conf 2014-04-17 09:28:27.000000000 -0700@@ -26,6 +26,8 @@ ADAPTER: c1sus_a0 8 0 4 HOSTNAME: c1lsc ADAPTER: c1lsc_a0 12 0 4+HOSTNAME: c1ioo+ADAPTER: c1ioo_a0 16 0 4 # Here we define a socket adapter in single mode. #SOCKETADAPTER: sockad_0 SINGLE 0--- /etc/dis/networkmanager.conf.bak 2014-04-17 09:30:40.000000000 -0700+++ /etc/dis/networkmanager.conf 2014-04-17 09:30:48.000000000 -0700@@ -39,7 +39,7 @@ # Number of nodes in X Dimension. If you are using a single ring, please # specify number of nodes in ring. --dimensionX 2;+-dimensionX 3; # Number of nodes in Y Dimension.
I then had to restart the DIS network manager to see these changes take affect:
$ sudo /etc/init.d/dis_networkmgr restart
I then rebooted c1ioo one more time, after which c1ioo showed up in the dxadmin GUI.
At this point I tried adding a dolphin IPC connection between c1als and c1lsc to see if it worked. Unfortunately everything crashed every time I tried to run the models (including models on other machines!). The problem was that I had forgotten to tell the c1ioo IOP (c1x03) to use PCIe RFM (i.e. Dolphin). This is done by adding the following flag to the cdsParamters block in the IOP:
Once this was added, and the IOP was rebuilt/installed/restarted and came back up fine. The c1als model with the dolphin output also came up fine.
However, at this point I ran into the c1ioo mx_stream problem and started backing everything out.
I added all the _OUT16, _INMON, _EXCMON channels associated with the BS, ITMX, and ITMY channels in SUS_SLOW.ini in the /opt/rtcds/caltech/c1/chans/daq directory. Similarly, I added the channels associated with MC1, MC2, and MC3 to MCS_SLOW.ini and those associated with PRM and the SRM to RMS_SLOW.ini.
Lines pointing to these files were then added to the /opt/rtcds/caltech/c1/target/fb/master file and the frame builder restarted. It took about 4 tries before the frame builder stayed up using ./daqd -c ./daqdrc.
I generated the .ini files with a python script. Its at /opt/rtcds/caltech/c1/scripts/daqscripts/create_inmon_out16_daq_ini.py. It checks the C0EDCU.ini to find what slow channels already exist, then goes through a medm directory given at the command line looking for all _OUT16, _INMON, and _EXCMON channels, adding them if they aren't already accounted for, and then writing out the new file to the location of your choice.
Why EXCMON? I think that we should modify the filter coefficients so that the decimation filter that makes OUT16 is a 2nd order Butterworth at 1 Hz instead of whatever bogus thing it is now. Then we can delete the EXCMON from the DAQ and add either OUTPUT or OUTMON. That way we will have a low frequency signal (OUT16) and a sort of aliased RMS (OUTMON).
ALS looks OK. I tried to lock FPMI using ALS, but I feel like I need 6 hands to do it with current ALS stability. Now I have all computers being so slow.
It was fine for 7 hours after Jamie the Great fixed this, but fb went down couple times and DAQ status for all models now shows 0x4000. I tried restarting mx_stream and restarting fb, but they didn't help.
We rebooted c1psl, c1iscaux and c1aux which were all showing the typical symptom of responding to ping but not to telnet (and also blanked out epics fields on the MEDM screens). Keyed all these crates.
Restored burt snapshots for c1psl, PMC locked fine, and IMC is also locked now.
Johannes forgot to elog this yesterday, but he rebooted c1susaux following the usual procedure to avoid getting ITMX stuck.
Rebooted c1iscaux, c1auxex and c1auxey which were all not reponding to telnet. The watchdogs for the ETMs were turned off and then I keyed all 3 crates. All slow machines are reponding to telnet now. Both green lasers locked to the arms so I didn't do any burt restore.
Had to reboot c1psl, c1susaux, c1auxex, c1auxey and c1iscaux today. PMC has been relocked. ITMX didn't get stuck. According to this thread, there have been two instances in the last 10 days in which c1psl and c1susaux have failed. Since we seem to be doing this often lately, I've made a little script that uses the netcat utility to check which slow machines respond to telnet, it is located at /opt/rtcds/caltech/c1/scripts/cds/testSlowMachines.bash.
The script can be executed by ./testSlowMachines.bash.
After ~3months without any problems on the slow machine front, I had to reboot c1psl, c1susaux and c1iscaux today. The control room StripTool traces were not being displayed for all the PSL channels so I ran testSlowMachines.bash to check the status of the slow machines, which indicated that these three slow machines were dead. After rebooting the slow machines, I had to burt-restore the c1psl snapshot as usual to get the PMC to lock. Now, both PMC and IMC are locked. I also had to restart the StripTool traces (using scripts/general/startStrip.sh) to get the unresponsive traces back online.
Steve tells me that we probably have to do a reboot of the vacuum slow machines sometime soon too, as the MEDM screen for the Vacuum indicator channels are unresponsive.
Steve alerted me that the IMC wouldn't lock. Reboots for c1susaux, c1iool0 today. I tried using the reset button instead of keying the crates. This worked for c1iool0, but not for c1susaux. So I had to key the latter crate. The machine took a good 5-10 minutes before coming back up, but eventually it did. Now IMC locks fine.
Reboots for c1susaux, c1iscaux, c1auxex today. I took this opportunity to squish the Sat. Box. Cabling for MC2 (both on the Sat box end and also the vacuum feedthrough) as some work has been recently ongoing there, maybe something got accidently jiggled during the process and was causing MC2 alignment to jump around.
Relocked PMC to offload some of the DC offset, and re-aligned IMC after c1susaux reboot. PMC and IMC transmission back to nominal levels now. Let's see if MC2 is better behaved after this sat. box. voodoo.
Interestingly, since Feb 6, there were no slow machine reboots for almost 3 months, while there have been three reboots in the last three weeks. Not sure what (if anything) to make of that.
Reboots for c1psl, c1iool0, c1iscaux today. MC autolocker log was complaining that the C1:IOO-MC_AUTOLOCK_BEAT EPICS channel did not exist, and running the usual slow machine check script revealed that these three machines required reboots. PMC was relocked, IMC Autolocker was restarted on Megatron and everything seems fine now.
Reboots for c1susaux, c1iscaux today.
MC autolocker and FSS loops were stuck because c1psl was unresponsive. I rebooted it and did a burtrestore to enable PSL locking. Then the IMC locked fine.
c1susaux and c1iscaux were also unresponsive so I keyed those crates as well, after taking the usual steps to avoid ITMX getting stuck - but it still got stuck when the Sat. Box. connectors were reconnected after the reboot, so I had to shake it loose with bias slider jiggling. This is annoying and also not very robust. I am afraid we are going to knock the ITMX magnets off at some point. Is this problem indicative of the fact that the ITMX magnets were somehow glued on in a skewed way? Or can we make the situation better by just tweaking the OSEM-holding fixtures on the cage?
In any case, I've started listing stuff down here for things we may want to do when we vent next.
MC autolocker was not working - PCdrive was railed at its upper rail for ~2 hours judging by the wall StripTool trace. I tried restarting the init processes on megatron, but that didn't fix the problem. The reason seems to have been related to c1iool0 failing - after keying the crate, autolocker came back fine and MC caught lock almost immediately.
Additionally, c1susaux, c1auxex,c1auxey and c1iscaux are also down. I'm not planning on using the IFO tonight so I am not going to reboot these now.
Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux, c1iscaux2 and c1aux. Usual precautions were taken for ITMX. Did burtrestore for c1iscaux andc1iscaux2 in order to restore the LSC PD whitening gains.
Un-related to this work: input pointing into PMC was tweaked as the PMC_REFL spot was pretty bright.
MC Autolocker was umnhappy because c1iool0 was unresponsive and hence it couldn't write to the "C1:IOO-MC_AUTOLOCK_BEAT" channel. I keyed the crate and IMC locked almost immediately. I'm moving this channel into the RTCDS model as we did for the IFO_STATE EPICS channel so that the autolocker isn't dependant on c1iool0 (which was the whole point of migrating the IFO-STATE variable anyways). I also commented out all of these channels in /cvs/cds/caltech/target/c1iool0/autolocker.db so that there aren't duplicate channels.
Steve reported problems getting the X arm locked. Alignment sliders were inaccessible. Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux and c1aux. Usual precautions were taken for ITMX.
This is becoming a once-a-week thing .
[ Gautam , Steve ]
c1susaux & c1iscaux were rebooted manually.