Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM March 18 to 5 PM March 19. Also attached are plots of the modes to show when they were running/acquiring data.

Data was taken from h1nds1.
T0=13-03-19-00-00-00; Length=86400 (s)
1440.0 minutes of trend displayed

[R. Abbott, D. Gustafson, K. Izumi]

The 9 MHz distribution amplifier box, which was in the R2 rack nearby the PSL room, has been pulled out to the EE shop for testing.

It seems that the input N-type connector of the box is doing something funny : the output RF power of the box can be at its maximum but is flaky when the connector of an exterior signal cable is not all the way in. Also it doesn't show any outputs when the exterior cable is all the way in. This is weird. At the beginning we thought this was due to the connector of the exterior cable, but replacing the connector didn't help. So we are suspecting the connector of the box at the moment and hence pulled the box out of the rack. Some tests will be happening tomorrow morning.

 

OS updates on various login,wiki machines.

rebuilt the old cdslogin server, still in progress.

rebooted h1pemmx, its IRIGB unit had powered down friday evening, Richard restarted it today.

Patrick found second trend issue around the DAQ restart time yesterday morning. We fixed this particular problem and alerted Alex to the cause.

Worked with Keita and Arnaud on the blank DAC parts of various medm screens.

I, Arnaud and Dave came across a problem which was somewhat confusing at first.

The problem I encountered was that the EPICS channel names for user model DAC output of TMSY, e.g. H1:FEC-99_DAC_OUTPUT_2_4 and such, were not working (in this channel name, 99 is the front end code number which you can find in the model, 2 is meant to show the DAC number and 4 shows the channel number) which made watchdog-related part of some medm screens white.

In this specific case TMSY uses two DAC cards, DAC2 and DAC3.

Dave pointed out that in the user model the DAC cards are logically addressed starting from 0 no matter what, so in our case H1:FEC-99_DAC_OUTPUT_2_4 and such should be addressed as H1:FEC-99_DAC_OUTPUT_0_4 and such. Simple once Dave explained this to me.

In IO model (which has all physical DAC) the corresponding channel is addressed as  H1:FEC-97_DAC_OUTPUT_2_4, here the logical and physical card number are the same. Simple again.

Complication was that the TMSY medm screen used to only accept one addressing that is used common for both the user model and the IO model channel names for the macro substitution, i.e.

chan="$(IFO):FEC-$(FEC)_DAC_OUTPUT_$(TF1)"

chan="$(IFO):FEC-$(IOPFEC)_DAC_OUTPUT_$(TF1)"

were used for the user model and io model channel names, and $(TF1) carries something like "2_4", so either the io model channel name was correct but the user model was not, or vice versa. And there were also $(TF2), $(TF3), $(LF), $(RT), $(SD) or something like that.

AS a dirty solution, I made another set of DAC card_channel macro for user model, i.e. $(UTF1), $(UTF2) etc. such that

chan="$(IFO):FEC-$(FEC)_DAC_OUTPUT_$(UTF1)"

etc. are used for user model outputs and

chan="$(IFO):FEC-$(IOPFEC)_DAC_OUTPUT_$(TF1)"

etc. are used for the io model outputs. This is ugly, maybe it makes more sense to use $(TF1) and such for the channel number, $(UDAC0) etc. for the DAC card number in the user model, and $(IDAC0) etc. for the DAC card number in the io model, such that you use

chan="$(IFO):FEC-$(FEC)_DAC_OUTPUT_$(UDAC0)_$(TF1)"

chan="$(IFO):FEC-$(IOPFEC)_DAC_OUTPUT_$(IDAC0)_$(TF1)".

Anyway, I did the ugly and quick change, made the necessary change to the site map and the OAT medm screen and committed them to the svn.

Thing is, there are other instances where the first DAC in the user model is not the first physical DAC card (e.g. BS), and I didn't do anything, I expect that SUS people will decide what is the better way of doing things, modify the MEDM for everything (including TMSY if necessary), and propagate it back to LLO.

Ongoing, Greg will be close to 25% done by the end of his day.  We've got the first (SE) iLIGO stack out; Greg is currently drilling and tapping holes.

J. Oberling, T. Sadecki, B. Weaver

On Mon. the 18th, we finished alignment of PR3 using the PLX periscope.  However, we had to do some rather coarse pitching of the periscope itself in order to maintain the IAS beam height at the optic.  This adjustment should, in theory, not be necessary, and furthermore, should also have no effect on this parameter due to the angle preserving qualities of the periscope design.  At the time, we convinced ourselves that this adjustment was legitimate and carried on with the alignment.  However, in mulling it over for a day, we began to doubt the PLX integrity.  To reinforce this doubt, we also began alignment of PRM which uses the entire PR beam path for alignment.  With the IAS as-built values for PR2 and PR3, we should have seen the autocollimator beam somewhere near the center of the PRM optic.  However, the beam was clipping off the upper right side of PRM a couple of inches from where we expected it to be.  Just out of curiosity, I wanted to see if I could us the alignment offsets to steer the beam to where it should be.  I did so using the sliders on the PR3 MEDM screen and got it to a respectable eyeballed center using offsets of ~1000 in both pitch and yaw.  The labels for these offsets said 'microradians', so I was a bit surprised to see that ~1000 microradians was required to correct the pointing.  I then left the chamber to verify from more knowledgable sources (mostly C. Mueller) that these sliders were actually calibrated in microradians, and was told that they indeed were microradians. 

Today, I assisted with the check-out of the PLX periscope out of chamber (I'll leave that report to the more knowledgable parties).  Later in the day, I decided to see if I could make more sense of the pointing of the IAS beam by steering both PR2 and PR3 rather than just PR3 as I had done the previous day.  After a few attempts to steer PR2 and tripping the IOP watchdog overseeing both HAM2 and HAM3 chambers, I discovered that as I was applying the offset in yaw to PR2, the IOP watchdog was indicating that it was being tripped by the yaw channels (left and right) of MC3.  I had in previous attempts increased the ramp time, as I had incorrectly assumed that was the culprit in the IOP watchdog trip.  I discussed this issue with A. Pele who is currently investigating. 

Day's Activities

• Pulling cables for ISCT1/IOT2L (Filiberto, Rich A.)

• Praxair at CP3 & CP5

• Stray Light Control Baffle people working in LVEA

• Mayflower here to swap containers

• Paradise Water

• Work at Vault (STS2 Seismometer & magnetometer) & MX by Richard & Vern

• Photon Calibrator work in H2 PSL (Pablo & Rodruck)

Dust Monitors:

• #8 (HAM2 Clean Room) has been alarming starting at 8:45am (had as many as 25k counts!)
• #14 (H2 PSL Enclosure) a few 100 counts

Removed duplicate seismic trends on TV (they were same, but started at different times)

Our annulus system uses 55 l/sec ion pumps to maintain the vacuum between the oring seals. MEDM screens show ion pump current which is also a measure of pressure at the ion pump inlet flange.  See the attached file for the pump curves and the current to pressure conversion. We have 46 of these pumps throughout the system.

1 mbar ~ 0.75 torr

1 bar = 760 torr = 1 atm

Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot requested from 5 PM March 17 to 5 PM March 18. Also attached are plots of the modes to show when they were running/acquiring data.

I do not know why dust monitor 4 in the LVEA stopped. It has been acting strangely lately though, with occasional low battery errors. I have restarted it.

There seems to be a very high single spike in the > .3 microns counts in the optics lab.

Data was taken from h1nds1.

mode:
2220 seconds worth of data was unavailable on this server
1440.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=13-03-18-00-00-00; Length=86400 (s)
No data output.

status:
T0=13-03-18-00-00-00; Length=86400 (s)
2220 seconds worth of data was unavailable on this server
1440.0 minutes of trend displayed

> .3 microns
T0=13-03-18-00-00-00; Length=86400 (s)
2220 seconds worth of data was unavailable on this server
1440.0 minutes of trend displayed

> .5 microns
T0=13-03-18-00-00-00; Length=86400 (s)
2220 seconds worth of data was unavailable on this server
1440.0 minutes of trend displayed

New TwinCAT installation scripts are available which support:

• All end station code is now run from the same source code, and
• A GUI is available to install, activate and run the PLCs.

This required a change of the target area. All target files are now located in C:SlowControlsTarget which is no longer under subversion control. Source code for the PLC programs is available under C:SlowControlsTwinCATSourceCurrentInterferometer. Program changes should never be applied to the target area directly. The new installation scripts also add the subversion revision number to the target code which in turn is available as an EPICS channel. The archive must be fully committed, otherwise the compile script aborts. When debugging, the revision number is patched to zero (invalid).

References:
Installation of TwinCAT Targets, LIGO-T1300175
Coding Standard for TwinCAT Slow Controls Software, LIGO-E1200225

We(Jim Greg & I) positioned the SEI (Support Tubes) to the correct elevation to put the Cartridge at the correct elevation and position, as best we could.

The vertical is set ~0.025" high (to allow for sag with 10000lbs added) to +1061.0mm.  Nominal height for the Support Tube bottoms would be 1060.4mm nominally putting the Optical Table at 1661.7mm.

We are left with some irreducible horizontal adjustments with the South side needing to go West 3mm and the North side needing to go East 1.5mm but the West and East sides only getting worse if those corrections are made and sitting well within 1/2mm of perfect.  I'll leave the position where it is.

Chris, Kiwamu, Sheila

We tested the picomotors at end Y today, we saw that the hardware is fine for all of them, but we had a lot of problems using the software.  
In the morning the END Y TwinCAT system manager was not working properly, there were some modules in the chassis that were not in the configuration in system manager, although Daniel and Max updated the system manager when they replaced a broken communication module last week.  Patrick updated the system manager again, and saw that PLC2.pro is missing, so none of the ALS laser channels are currently working.  

Once Patrick and Max had fixed that, we were able to control the first two picomotors (M3  (injection path, on the edge of the table) and M6 (injection path center of the table)  from medm screen without problems, but mirrors 3 (dichroic) and 4 (IR QPDs) we were unable to control. (although everything looked fine according to the LEDs on the controller) 

Using the picomotor tester, we were able to control all of the picomotors, by injecting a square wave 0-5V at 500 Hz into the pulse input on the tester.  (The step size needed to see a difference in the position of the mirror is about 1000 steps, so the switch that moves by a single step is not very practical)

I'm not sure what is going on with the last two controllers when we use beckhoff, but I will try to figure it out.  

Also, Kiwamu removed the half wave plate that we put onto the ALS table for the QPD alignment.  

Dust Monitor 1 has a calibration error and is not working - Patrick is working on a replacement. All PSL environmental monitoring channels still offline.

800-820 Arnaud taking measurement on MC1 and MC3 ---coordinated with Doug and Jason

919 Mid Columbia Forklift on site

930 Kiwamu transitioned EY to laser safe

930 Pablo and Michael R working on PCAL annulus near H2 PSL enclosure

1004 Travis pulling soft covers on HAM2

1100-1140 Dave B power cycling h1pemmx, restarting DAQ, SUS-IM

1307 CH2MHILL on site (Ski)

1330 Apollo Sheet Metal delivery

1445 Reverse osmosis unit shut down from clogged filter (H0:FMC-CS_WS_RO_ALARM); fixed by Ski

Based on Corey and Jeff's work last week and with Dave B's help I have made changes to the alarm handler with regard to ETMY and ITMY.

Corey had modified some of the  IOP watchdog MEDM screens to provide a more useful display; for the quads he had changed the old arbitrary "OSEM1-OSEM6" to the more useful "F1, F2, F3, SD, LF, RT ". I have made similar changes to the alarm handler so the operator can quickly tell which OSEM is in alarm state. I used the map data Corey posted in the CDS wiki.

I modified

/opt/rtcds/userapps/release/cds/h1/alarmfiles/h1cds_iop_sus_watchdog_etmy.alhConfig

and

/opt/rtcds/userapps/release/cds/h1/alarmfiles/h1cds_iop_sus_watchdog_itmy.alhConfig

to show the correct OSEM name on both the group field and in the guidance popup. The channel name will still show "OSEM#", however. I updated the changes in the SVN.

Did another hands on touch/look at HAM3.  Touched every connection and detect nothing.  Fluid level unchanged at the Mezzinine reservoir.  Still running steady at 26psi & ~97% max speed.  All's well.

[Chris W., Sheila D., Kiwamu I.]
This is a report from yesterday.

We completed the alignment works which were associated with the TMSY. We accomplished three missions : (1) balancing of the TMSY optical table, (2) alignment of the infrared QPD path on TMSY and (3) alignment of the infrared beam extraction path through a viewport.

TMSY optical table balancing
The optical table (the bottom mass) of the TMSY was re-balanced by shifting the position of an existing small weight, which was attached on the bottom side of the table. A picture of the weight is attached below. The motivation of this mission was to correct a big pitch misalignment which was found after Betsy released tension of the cables [1]. Since the misalignment was largely in pitch according to our observation on the last Thursday, we shifted the existing weight by 2 inch from the original point away from ETMY. This adjustment nicely recovered the alignment. The static pitch offset of the BOSEMs to obtain retro-reflection from ETMY is within a reasonable actuation range. Thus we conclude that we succeeded in re-obtaining the table balance.




Infrared QPD path alignment
This time the issue of the highly transmissive BS at 532 nm [2] was mitigated by introducing a half wave plate to rotate the polarization of the green light such that the reflectivity of the HR surface increases somewhat. Thanks to the half wave plate, which was placed on the launching path on the EY in-air table, the HR beam became barely visible (although Sheila wasn't able to see the spot while I was somehow.) The infrared path on the QPD sled had been about 1.5 mm off in horizontal translation, so we tweaked two steering mirrors which are the ones right before the sled. The path is adjusted with a precision of less than 1 mm by simply looking at the beam spot on the QPDs. A difficulty was to identify the right beam spot as there are lots of ghost beams in the path because the optics are not intended for green light.

Infrared extraction path alignment
This adjustment was much easier than the last alignment missions because the green light was very visible. After we confirmed that the beam hit the center of every optic, we steered the last launching mirror to let the beam go through the bottom middle viewport. The beam was adjusted such that it goes through the center of the viewport glass with a precision of about 5 mm.

Note :
We increased the laser power to make the beam more visible. This needs to be decreased to the point where it used to be.
The half wave plate is still in the path. This needs to be removed.

[1] LHO alog 5810 "Another Round of TMSY De-rubbing"
[2] LHO alog 5774 "50-50 IR beam splitter is a good AR for green"
 

I added temperature/relative humidity sensors to the dust monitors in the optics lab, vacuum prep lab and bake oven room.

I walked about 300 meters of Y1 this week and took some photos of the beam tube insulation.

Between ports 2 and 3 (a distance of 250m) I counted 35 holes in the insulation. Virtually all of these holes were at taped joints between insulation wraps. These joints occur every 4 feet.

So of 800 taped joints I saw 35 which were violated by rodents. There may have been a few more on the backside of the tube. The photos in this report show some of the holes, some of the "good" taped joints, and some views of the uninsulated bellows regions.