The issue of the 9 MHz amplifier box [1] was solved. The box is now back in the R2 rack and working fine.
I tested the box at the EE shop and it was very healthy. Then it turned out that the exterior signal cable was flaky even though Rich had replaced its N-connector by a new one yesterday because we had suspected it at the beginning. We swapped the cable with a temporary one and everything worked fine. The temporary cable will be replaced by an LMR cable at some point but we will go with it for now to carry out the demodulation chain and photo-diode calibration tests.

[1] LHO alog 5846 "9 MHz amplifier box pulled out for testing"
 

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.

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

   We took TFs and Power Spectra data for HSTS I1-MC1. All files have been committed to the SVN repository.  The data files are attached below for review by Stuart A. and Jeff K.