EY prep work by Apollo continues
EY conduit work between chambers for instruments (Richard M & crew)
PCal Crew working in H2 PSL Room (Colin/Pablo)
cds f0 file server rebooted for Raid Disk Failure from weekend
TMS BOSEM work (Cheryl/Jeff B)
Installing new TMS EX iMac (Cyrus)
Vacuum gauged pair for BSC10 disconnected for conduit work (Ken D.)
Sunday between 8am and 9am the cdsfs0 disk system went into read-only mode. I power cycled cdsfs0 this morning at 09:45 to fix the problem. We have a replacement raid controller to try, but taking cdsfs0 down for the swap out will be very intrusive for all CDS activities and so we have not scheduled this yet.
Some workstations may come back by themselves, others may need to be rebooted. I have restored most of the control room workstations.
Logic:
A) Watch H1:PSL-FSS_AUTOLOCK_STATE
if = 4, set H1:IMC-REFL_SERVO_FASTEN = 1 and H1:IMC-REFL_SERVO_COMCOMP = 1
otherwise set H1:IMC-REFL_SERVO_FASTEN = 0 and H1:IMC-REFL_SERVO_COMCOMP = 0
B) Watch H1:IMC-MC2_TRANS_SUM_INMON
if > threshold, set
ezcawrite H1:IMC-REFL_SERVO_IN1GAIN 0
ezcawrite H1:IMC-REFL_SERVO_COMBOOST 1
ezcawrite H1:SUS-MC2_M2_LOCK_L_GAIN 0.2
ezcaswitch H1:SUS-MC2_M2_LOCK_L FM3 ON
ezcawrite H1:SUS-MC2_M1_LOCK_L_GAIN 1
ezcaswitch H1:SUS-MC2_M1_LOCK_L FM1 ON
otherwise set
echo unlocked $MCval $thresh
ezcawrite H1:IMC-REFL_SERVO_IN1GAIN -10
ezcawrite H1:IMC-REFL_SERVO_COMBOOST 0
ezcawrite H1:SUS-MC2_M2_LOCK_L_GAIN 0
ezcaswitch H1:SUS-MC2_M2_LOCK_L FM3 OFF
ezcawrite H1:SUS-MC2_M1_LOCK_L_GAIN 0
ezcaswitch H1:SUS-MC2_M1_LOCK_L FM1 OFF
I used THRESH_ON=1000, THRESH_OFF=900
Note that Ethercat + one command link to trigger the MC2 filters and gains could easily take care of this.
For now, there are two scripts that do this in ioo/h1/scripts/imc/sballmer :
FSSwatch
MClockwatch
Performance: The typical time from FSS in state 4 to full low noise IMC lock is about 1 to 2 sec, + the 3sec ramp time in the MC2 filters. The longest I
have seen is about 7 sec.
PS: The FSS definitively has to be sped up.
The last burt backup was at /2013/08/18/08:00. I also noticed a lot of other things (like ezcaswitch, ezcawrite or foton) stopped working on some ops machines. I suspect the whole issue is some full or improperly mounted disk.
I added a triggering feature similar to what the lsc has to the h1ascimc model - except that I kept it simple by defining only one trigger and one FM trigger and mask for all DoFs. Relevant channels: Setting the TRIGGER threshold for turning the WFS feed-back ON and OFF: H1:IMC-TRIG_THRESH_ON H1:IMC-TRIG_THRESH_OFF Corresponding monitor channel: H1:IMC-TRIG_MON Setting the TRIGGER threshold for turning DoF filters ON and OFF: H1:IMC-DOF_FM_TRIG_THRESH_ON H1:IMC-DOF_FM_TRIG_THRESH_OFF Corresponding monitor channels: H1:IMC-DOF_FM_TRIG_MON H1:IMC-DOF_FM_TRIG_MON_WORD Corresponding MASK channels: H1:IMC-DOF_MASK_FMx H1:IMC-DOF_MASK_MON I set both up to trigger at the same level as the lsc (ON=1000, OFF=900), and triggered the integrators in FM2. This makes the ASCIMC WFS completely autonomous - no scripts required to start them up. THe MEDM screen for setting up the threshold is still TBD.
[Jamie, Kiwamu, Mark, Stefan]
On Friday, we were finally able to get the "new" Guardian supervisors running and supervising various components of the input mode cleaner. Guardian "supervisors" are the main guardian processes that run the guardian code for a particular domain/component/subsystem. In this case, we had three components (or "system") running, delineated by channel access prefixes:
States for each of the systems were defined, and we were able to run the supervisors through their paces a bit to confirm that the behavior was more-or-less as expected. In fact, I would say everything really worked quite well, surpassing my expectations. Unfortunately we didn't quite get to the point where I felt comfortable leaving the supervisors running on their own, so I shut them down before I left on Friday evening.
Over the next couple of days I'll attempt to build out some of the infrastructure to start/stop/restart the supervisors at will, to ease their commissioning. I'll also work on documentation in preparation for the **Guardian review, Monday, August 26th, 12:00 PDT**.
A guardian "system" consists of states connected together into a directed state graph. It is described in a "system description directory", which is passed to a guardian supervisor process as it's primary argument. When the supervisor is launched it instantiates its own EPICS channel server, which is used for accepting state requests and reporting status.
When the system is in a given system state, the supervisor is executing the run script for that state. If the state run script "Returns", the supervisor transitions to the next state in the sequence to reach the requested state. Once the requested state is reached, the system remains in that state until a new request is issued. If the state code exits with a "return target", the supervisor will transition to the target state. It the system is being run in "un-managed" mode, it will attempt to re-reach the original requested state on its own. This is known as "recovery". Otherwise, if the system is run in "managed" mode, the request will be reset to the recovery target and the system will wait for instructions from its manager.
The supervisor process itself is now functioning as a true finite state machine. In its primary run state the supervisor runs the state code for the current system state (sorry for the overloading of the term "state": the supervisor has "states" of operation of its state machine that are distinct from the "states" of the system it is controlling).
Once we got things finally running, the new supervisor finite state machine architecture was working really quite well, even better than I expected. The system responded very quickly. We could issue requests, after which the supervisor would immediately calculate the path to the new requested state and ratchet through the state sequence to get there. We could easily stop at intermediate states to check status, and then instruct the system to continue on its way.
For things to work, there are really two aspects: there's the guardian supervisor itself, and the system description and its state run code. Beyond the behavior of the supervisor itself (which seemed to be working quite well), we managed to get the actual guardian code for the systems under test in a good enough state such that the graphs were well constructed and the state transitions made sense. We found some bugs in the supervisor that I was able to fix immediately, and we worked on the actual system state code until the systems were behaving properly.
We ran the IMC and SUS-MC2 supervisors in a managed mode, where we were manually coordinating their states to lock the IMC. Once we were happy with their behavior we were even able to run the SYS-IMC manager which was coordinating the transitions of IMC and SUS-MC2 to automatically lock the IMC, and recover the system back to the locked state. I will try to post descriptions of the systems we had working, including the system graphs and state descriptions, in the next couple of days.
However, things weren't working quite well enough that I felt comfortable leaving it running. The supervisor would occasionally get into a hung state that I was not immediately able to diagnose and required restarting the supervisor. The SYS-IMC manager also seemed to miss some transitions, likely due to bugging programming of the SYS-IMC state code. There is also a lot of missing features and infrastructural work needed.
I'll be posting further as more of this stuff gets in place.
BOSEM mounting plate was tapped dry by Jim and it's working great.
All TMS SUS cables were connected.
All BOSEM were reasonably centered but height was not adjusted because the MEDM was not working on cdsimac2.
Not all safety structures were installed, but the one that matters (safety wire) was. There was some problem that was fixed by bending wire (another alog).
I'll be on vacation next week, but basically everything is there for SUS test. Corey/Cheryl/Deepak need to do the following:
In parallel, you need to work on assembling the remaining safety structures.
Another ugly work around.
Mounting position of TMS vertical safety wire is shifted by about half an inch from the center of the TMS table. I'm guessing that the mounting hole position for the wire on the safety support beam, type 01 (D1100264) is wrong.
I'm bending the safety wire, as it is more like a thin rod, so that it clears the ring on the TMS tele.
The first picture shows how the safety wire is bent and the safety wire clamp tilted to allow the wire to clear the ring.
The second picture shows that a plumb bob, which is suspended from the center of the safety wire clamp, is pointing almost at the edge of the ring.
The third picture shows how I held the plumb bob.
I cannot open MEDM sitemap from the dock.
When I click the terminal icon in the dock, a terminal window opens immediately but it takes more than 5 minutes before bash prompt is shown.
When finally the bash comes up, a simple ls command takes 3 seconds.
sitemap command from bash tries to launch something, and it takes about a minute or two before "cannot access file: /opt/rtcds/lho/h1/medm/SITEMAP.adl" is displayed.
We tested a new scheme for IMC locking that is based on fast triggering on the IMC transmitted power. This allows discriminating against higher order modes, without lowering the feed-back gain. Our plan was to - acquire with the fast path (frequency feed-back) only - immediately engage the slow path (MC2 feed-back) once above the threshold - but avoid a large switching transient - and put some slow motion on the optic to make sure we see fringes. All that was achieved by - leaving the the slow path to MC2 on, but - have an additional 0.3Hz pole in the slow path. this puts some slow motion on MC2. - once triggered, this 0.3Hz pole is simply turned off, engaging the full feed-back without a transient. To implement this we had to make one minor change to the FILTBANK_TRIGGER.mdl library part: - our filter needed to be turned OFF on trigger (not the opposite) - we thus added an epics input named "_INVERT" (e.g. H1:LSC-MC_FM_TRIG_INVERT) to the library part - if "_INVERT" is 0 (the default), the behavior is unchanged from the previous model. - if "_INVERT" is ~0, the trigger fires if the input is below threshold. With this logic the IMC seems to grablock in less than 1 sec, reproducibly. The changes (both h1lsc and FILTBANK_TRIGGER.mdl were submitted to the svn (revision 5458).
Work on the OSB roof – Richard Work on the Optics Lab – Gregory TMS work at End X – Cheryl/Keita H2 PSL Enclosure work (local laser hazard ON/OFF) – Colin/Pablo
I looked into cross talk in the PEM Endevco boards and the Anti-Aliasing boards. For the Anti-Aliasing boards I directly injected a 5 Hz ramp signal and looked at 10Hz right before saturation. For the Endevco I installed an accelerometer on a shaker at 5 Hz and gradually increased it until just before saturation. The cross talk attenuations in the attached table are at 10 Hz.
After testing a known good channel on it, we determined that channel 3 of AA2 is bad.
[Stefan, Kiwamu]
Today Stefan reminded me that the WFS RTS library parts for its DC signal was updated in July 30th (see LLO alog 8061) and we haven't applied it at all in LHO. This update was for fixing the numbering of the four DC segments to match with that of the RF segments. Before appplying this updates, we wanted to make sure that this is the right thing to do. So for the reason we did a brief check on the existing WFSs, namely IMC WFSs on ITO2L. We intentionally misaligned the IMC REFL such that it hits only one of the four segments and did a block-and-unblock power modulation by hand to identify which segment responds. We went through all four segments on both WFS_A and WFS_B. Indeed the DC segments were in a wrong order of {4,3,2,1} while it is {1,2,3,4} in the RF segments. Indeed we need to correct it in the IMC realitme model although we haven't corrected it yet.
Looking at the l1asc model which uses the updated WFS library, we noticed that the labels of the tags associated with the DC library parts were incorrect. We probably need to talk to poeple in LLO to make sure that the update was done in a proper way.
VBO A is up and running again but the side effect is really high dust counts in the optic lab's vacuum oven room. For now the door to that room is closed, but hopefully the counts will drop soon. The fiberglass heat tape and insulation are the largest culprits.
We've tested a new tripod mounting system for the magnetometers with aims to decrease artifacts from motion of the magnetometer on the tripod. The iLIGO mounting scheme resulted in peaks in the magnetometer spectra that were not from real magnetic fields but from the magnetometer moving in the earth's field at tripod resonances. We tap tested both tripods to study their resonances and damping. The flagpole resonance of the current tripod is at 7.9 Hz. The new system, designed at Cal State Fullerton, is more damped and rigid. Attached is the power spectrum of both setups, side to side (see photo). The red trace is the magnetometer mounted on the current tripod, the blue trace is the magnetometer mounted on the Fullerton prototype tripod. The flagpole resonance of current tripod is seen at 7.9 Hz, the one place the blue Fullerton trace does not follow. Most other peaks seen are from nearby cleanroom fans and the expected 60 Hz. Terra, Robert
Two tripods in the photo - is the orange one the current or the Fullerton?
Orange is the Fullerton.
TMS ISC cables were attached to the mass using metal clamp with kapton tubing.
Took longer than we first thought because we had an interference with the screw tip of the clamp and the side of the blade, and had to experiment with shimming. Too thin a shim and your screw protrude more from the back and interfere with the blade. Too thick and your screw doesn't go all the way through the threaded hole of the bracket, and the thickness of the bracket seems to be smaller than 1/8, much thinner than you would expect from 1/4-20 thread.
Then the cables were attached to the cube rather than the ceiling using peek clamps. This is because we don't have a good tapped hole to mount cable clamps under Bosch frame. Once it is moved to the test end we'd have more options, but in the mean time this should be good.
The top mass was rebalanced, table cloth was readjusted to maximize the clearance (the tolerance is extremely tight), BOSEMs were repositioned but we couldn't proceed as there was a trouble attaching the side BOSEM to the new mounting plate (see another alog).
In parallel with side BOSEM effort, we still need to mount the dummy feed through to the Bosch frame, put the BOSEM cables on, and set the height of the BOSEMs correctly, which looks like half day's work, before we can test the SUS.
pictures: https://ligoimages.mit.edu/?c=1361
Side BOSEM mounting plate that came out of the oven today didn't have tapped holes and we couldn't mount BOSEM on it.
According to https://dcc.ligo.org/d060323 it has four 8-32 tapped holes, looks as if the shop just drilled holes for the tap and then forgot tapping.
Will talk to Bubba and Tylor to see if they can dry tap (we need four such holes per plate). No SUS test today.
Rev F - tapped holes Rev G - not so much
