[Sheila, Kiwamu]

Sheila had a difficulty in relocking the IMC. So I looked into it to figure out what is happening and fixed it by steering the PZT pit.

It was apparently due to a misalginment, mainly in pitch according to the GigE views. Looking at one-day trend, I found that the PZT pit suddenly had changed its value from 400 to -240 counts at around 8:20 am local. A mysterious point is that , after the PZT jumped, the IMC was still able to lock itself for approximately 4 hours.Then it ran into a situation where it was not able to hit the LSC trigger. I didn't see a significant drift in any of the MC suspensions. I fixed it by steering the pitch of PZT back to +300 counts. It relocked right away and we ran the offload script so that it doesn't loose the good alignment by a unclok. We should keep our eyes on this PZT.

The attached is the one day trend.

Chris, Daniel, Stefan

We implemented the first operational version of a control state definition (LIGO-T1300958). We chose the x-end PLC2 ethercat system to test the code.

The related files are currently in als/common/guardian, but will likely have to move again.
 - PLC2_X.xml:     the xml file defining the control state
 - PLC2_X.py:      auto-generated python code using Daniel's csdinfo utility, based on PLC_X.xml (currently only available in windows, but soon to be ported to unix by Chris)
 - csd_PLC_X.db:   data base for the new epics channels controlling the control state. Also auto-generated by csdinfo, based on PLC_X.xml
 - csd_PLC2_X.adl: auto-genereted medm screen, created from csd_PLC_X.db using makeMEDMfromDB
 - makeMEDMfromDB: bash script for generating medm screens from data base
 - csd_PLC2_X.cmd: ioc startup file for launching the epics data base


A guardian instance controls the global state machine (see LIGO-T1300958). It implements the states "SAFEOP" and "OP". It also has dry versions of each state for testing - they only log differences as opposed to enforcing the settings. The guardian can be started by
  guardmedm H1ECATX1PLC2

The IOC was started on h1guardian0 using
  softIoc -D /ligo/apps/linux-x86_64/epics/base/dbd/softIoc.dbd csd_PLC2_X.cmd 

The associated MEDM screen can be started with 
  medm -x csd_PLC2_X.adl 

Remarks:
 - more work is needed to make the loading process smooth - most importantly csdinfo has to run on unix.
 - the xml file likely still needs some tweaking to properly work with the Beckhoff auto-locker.


Attached text files:
 - xml file - the source of everything
 - the auto-generated py file
 - the auto-generated db file
 - script generating the medm screen

Attached screen shots:
 - guardian for the global state machine
 - medm screen for the new state variables for PLC2

The first one I was switching blends, plot attached.  The next two we don't know why they happened, we only got one plot.

Laser Status: 
SysStat is good
Output power is 27.5 W (should be around 30 W)
FRONTEND WATCH is Active
HPO WATCH is red

PMC:
It has been locked  d, 11 h 40 minutes (should be days/weeks)
Reflected power is 1.2 Watts  and PowerSum = 11.0 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 0 d 0 h and 3 min (should be days/weeks)
Threshold on transmitted photo-detector PD = 0.56 V (should be 0.9V)

ISS:
The diffracted power is around 12.4 % (should be 5-15%)
Last saturation event was 0 d, 0 h and 2 minutes ago (should be days/weeks)

   On Monday 04/145/2014 We partly removed the soft covers on the North and South door of HAM5. Particle counts before the covers came off were generally zero, with an occasional 1 to 20 counts in the 0.3 and 0.5 micron range. I took several counts inside the chamber. Most were zero, which occasional spikes in the 100 0.3 micron range. I did see one spike with over 500 0.3 micron counts, and corresponding lesser counts in the larger particle sizes. These counts cleared within a few minutes and return to the normal ranges.      

I installed the latest OS updates on the digital video camera servers, and also did some minor updates to the EPICS IOC processes, as specified in WP4566.  No issues, other than a typo that took a little time to track down that prevented the settings from being automatically restored (fixed).

we don't know why, it is windy out.  Sensor correctioin was off

We are trying Tcrappy

Here are spectra of the ETMX and ITMX oplevs.  All blends are on Tbetter, sensor correction was on for ETMX and off for ITMX. 

We are bothered right now by large amplitude motion (around 1urad pp) in yaw at very low frequencies.

I was setting the stage 1 blend filters (one at a time and slowly like we were instructed to), and the ISI tripped due to the ACT limit.

These plots show that it is possible to completely damp out the fundamental L and P modes of the quad, that are causing the cavity pain. The damping method here is called 'full state feedback'. It is like modal damping in that it uses an estimator to compensate for a shortage of sensors around the quad. However, the controller is a matrix rather than a set of filters. The advantage of the matrix feedback is that you can solve the matrix for a set of desired closed loop poles. So here I have specified that the first two modes will have a Q of 0.67 in the closed loop. The others I specified between 10 and 50.

The price you pay for this controller is absolutely terrible noise performance. Also, it is not AC coupled. But, if the RMS test mass motion is a real problem for the cavity, this can be used to suppress it.

The hydrogen outgassing rate measured is 75% of that measured in 2000. The atmospheric accumulation is about
6.9 x 10^-8 torr liters/sec and seems high relative to that in y1 and the accumulations made at LLO. The value suggests
a small leak. If this is in the beamtube it is at the threshold of not being able to be found with our
current techniques.

The results of the accumulation were more difficult to calculate and have more uncertainty due to the method of 
connecting the RGA to the beamtube. The connection was made by a corrugated small diameter tube rather than a mount
directly on the beamtube. The pumping speed of the tube and the pumping speed of the RGA as an ion pump need to
be accounted for. The attached pdf file shows the influence of the connecting tube and presents the results.