andres.ramirez@LIGO.ORG - posted 14:56, Tuesday 15 April 2014 (11363)
Maintenance
Crystal chiller refilled.
Crystal chiller refilled.
[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.
I changed the PZT offsets this morning to account for the temperature drop in the laser room over night. Robert then increased the nominal, so it is expected that the alignment shifts back towards the older settings. The correct way is to use the centroid of the reflected beam when not locked and steer the PZT to the same position. Dave added theses channels to the frame, so they can be trended (if you can figure out how they are named). We probably should add an error condition to the IMC locker which checks this at the beginning.
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.
I tried moving to Tcrappy and it tripped again as I tried to turn it on
Hugo found that the problem was that some gain switches were set incorrectly. This is something that it would be nice to have the Guardian control. PS, this is sheila
Input gains were turned off on half the T240. We turned them back on, and ITMX is now running on TCrappy.
To be absolutely clear, my understanding is that the new threshold is NOT actually 60s worth of saturations, but
60 * (model sample rate in Hz) samples worth of single-sample saturations that will now cause trips.
This is a big and important distinction. The first will trip after 60s worth of continuous saturations; the second will trip in an indeterminate time after the first saturation after a reset.
Please correct me if this is not right but this is my understanding of the new behavior, and it's important that everyone is clear on it.
60 x (model rate) = (number of saturated samples allowed) is what I coded into the master model, and what I meant by "60s worth of saturations" without realizing it could be misunderstood.
HEPI-L4C saturation counter will keep accumulating regardless of whether the saturations are continuous or not, until the reset button is pushed, or HEPI trips.
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
The ISI tripped again, L4C limit, there are people working in the beer garden. The BS ISI is also tripped.
ITMX ISI tripped again. ACT Limit this time...no idea why... the blends were on TBetter
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.
We've seen this on ITMY before and changing out the laser seemed to fix the problem. I've attached some graphs indicating more clearly what might be occurring. The time series indicates that the power is dropping on all quadrants in with 20 second intervals; although this is very difficult to see by looking at the normalized pit and yaw signals,you can see it very clearly when looking at the individual segments. Similarly, in the spectra, there is only a small indication at 1.0-2.0 Hz that something weird may be going on but when we look at an individual segment, you can see weird spikes starting at 0.056 Hz and then the harmonics following through to higher frequencies. For comparison, I included the ETMX Segment1 spectra and you can see that we shouldn't see those spikes. I'll be investigating this today but my first guess would be either the laser or laser power that's causing a dip in power every 20 seconds, which is pretty odd because we got this laser new "off the shelf" from microlasers.
Some improvement but still oscillatiing a bit.
I've attached new spectra comparing the WIT sensors and the optical lever to show that we can see real motion of the optic for the coil balancing procedure that the SUS team is trying to perform. Also attached is the comparison between ETMX and ETMY, although the ISIs are in a different state, we can see that they are comparable. The last image attached is a trend showing that we still see this power oscillation with a peak to peak of about 240 counts with a period of ~3 seconds. This is much better than the p-to-p of 2500 counts every 19-20 seconds in the previous laser configuration.
Trying to hunt down the exact noise source proved to take longer than I thought it would. I ended up switching between three variables and chooising the best configuration: The laser, the power supply, and the outlet. We have not switched this laser to run with the power board yet but once we implment this change, it'd be interesting to see if this oscillation goes away or gets worse. Richard thinks that the noise comes from the thermo-electric coolers in the laser itself, in which case switching to the power board probably will probably not change this artifact.
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.
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.
Yep, this level of air leak would be challenging to locate by current techniques. It's probably small enough not to directly impact sensitivity, but it seems important to establish whether there's a degradation process at work, like LLO Y. We should consider a repeat accumulation, perhaps with three sampling points along the 2km module.
I estimate some 3000 cm^2 of viton in the large valves exposed to this volume. This may account for some of the air. Anyone know the outgassing rate of viton after 140,000 hours under vacuum?
We should probably reconfigure the RGA to eliminate local orings and the low conductance of the flex hose. Kyle and I felt we had nothing to loose by trying the quick and dirty method first. Practice makes better.
Correction on the surface of viton contained in the LN pumps and large gate valves.
There are 4 gate orings entirely in the vacuum (45 inch diam) and 2 gate orings 1/2 exposed at the closed gate valves(45inch).
There are 4 flange orings 1/2 exposed where the gate valves bolt to the ln pumps(45 inch diam)
There are 2 bonnet seal orings 1/2 exposed in the two gate valves open to the volume - each is 144 inch long.
Total surface area ~ 6970 cm^2
If the entire air leak is allocated to this we get an outgassing rate for the viton of 1e^-11 tl/sec/cm^2.
