[Paul, Giacomo, Rodica, Cheryl]

This simulation work is related to the measurements described in entry 4571, in which beam distortion was observed when using the FI with 4mm DKDP at high-power.

I noticed that it did not look like the alarm levels had been set on the FMCS EPICS channels. These are set by a burtrestore. I have set them.

WP#3533

We moved all fast PEM channels from H2 to H1 this afternoon. 

The h2tcsl0 front end was shut down. It was disconnected from the PEM IO Chassis. The h1oaf0 one-stop cable was extendeded into the LVEA and connected to the LVEA PEM chassis. We powered h1oaf0 up for the first time, and Dolphin crashed all corner station SUS and SEI systems (see today's alog). 

The h2ioptcsl0 model was copied for h1iopoaf0, and the h2peml0 model converted to h1peml0. We checked the SEIS channels looked ok.

I added PEM to H1 DAQ and removed it from H2 DAQ.

We have completed the transition of the EY CDS systems from H2 to H1. In the past two days we have been cleaning up MEDM screens, converting the filter module files and reconfiguring the H1 and H2 DAQs.

The only task left is to convert the HWS EPICS system to H1, we are working with the TCS group on this.

I am closing out WP #3518.

Late report from Wed/Thursday.

We have been noticing that when the 2-RFM systems h1lscl0 and h1oaf0 were powered up they crash all systems on the Dolphin network. On wed h1lsc0 was powered up for the very first time all SUS and HPI models crashed. The IOP models and ISI models time gliched. I diag reset runing models and restarted crashed models. Later Hugo noticed that the DAC drives for h1isiham3 were randomized and we could only recover by power cycling the h1seih23 IO Chassis (unplugging the DC power cord).

Today we got the same initial problem by powering up h1oat0. This time all user models crashed including ISI. We were careful to restart all models this time, including IOP models.

We correctly powered down h1oaf0 by first removing it from the Dolphin network, yet when we powered it up we once again crashed all Dolphin connected models. We are seeing a pattern here. Again we restarted all models (IOP and User). Hugo reported that the DAC channels for h1isiham3, h1susmc2 and h1suspr2 seem to be working (i.e. we cannot reproduce the DAC channels randomized problem).

[Patrick / Kiwamu]

We made some changes in the EPICS server script and database file for a slow digital process (PLC2 on H2ECATC1) to broadcast the EPICS values associated with the IMC control.

Yesterday we took a look at the OPC and EPICS servers on H1ECATC1 because the EPICS values had not been available. H1ECATC1 contains two PLCs (called PCL1 and PLC2) and the database file of both of them should be passed to the EPICS server. It turned out that the lines for PLC2, which takes care of the IMC servo and some others, were commented out in the EPICS startup script called st.cmd. We released the commented lines so that both PLC1.db and PLC2.db are loaded. However running the startup script then gave endless warning messages.

To make the situation simpler, we temporarily split the startup script into two pieces - one for PLC1 and the other for the IMC servo (which is a part of PLC2). They are called PLC1_st.cmd and PLC2_st.cmd respectively and each has a dedicated bat file. Also we made a database file which contains only IMC servo parts by copying the corresponding lines from the existing PLC2.db. This file is currenlty named as PLC2_IMC_REFL_SERVO.db

We ran both scripts to activeate two EPICS servers and they seemed running fine so far. So we are now able to see the EPICS values associated with the IMC servo board from an MEDM screen, which is good.

We need to further investigate why we got the numerous warning messages and how we solve it at some point.

 3 viewports were installed on the IO septum, the fourth one will be installed at a later date.

The first contact was removed from the viewports outside of the chamber, inspected, then the o-ring set into the groove.  The viewports were installed on their respective ports.  Torque used 16 ft*lbs.

VP1, VP3, VP4 were the ports installed

(Mark L, Marc S, Gerardo M, John W, Douglas D)

Gerardo, Betsy, Norna

This morning, after consulting Margot (who had just performed this procedure at LLO with the crew on their ITMy), we removed the CP from the ITMy suspension and removed the pyrolux/flexi-curcuit ESD connections from it's 12 o'clock position.  We used the ergo arm to retrieve the optic from the ITMy sus still mounted to the BSC1 ISI on the test stand.  We then moved the CP to a v-block on a small mobile optics table.  Using a CLASS A razor blade we slowly peeled the flexicurcuit off of the pyralux "glue layer" and then worked that layer off in the same fashion.  We then rotated the CP 180deg, while still on the ergo arm, and stuffed it back into the suspension.  By eye, the mass seemed to hang with minimal pitch/yaw/position error after rehanging the mass in the reaction chain.  Back to IAS and testing now...

I am testing a modified version of the code described here to address the problem listed here. The work permit is number 3531.

I recently made a new set of isolation filters level 2 for HAM3-ISI. 

1- I tried them with the new Step_8_Performance_Analysis commissioning script. Spectra are attached*. The blend filters used are the new 250mHz blend filters **. There are some discrepancies between the expected isolation and the measurement. This is especially noticeable along Z. I am not sure why yet.

2 - I also tried the same configuration with the new 100mHz blend** engaged on X and Y. I compared the spectra measured then, with the ones measured earlier this week. Isolation loops show good performance. There is some amplification of motion between 10Hz and 50Hz. This is mainly noticeable along X.

* .pdf created with a new matlab script. I am still perfecting. I should be able to add it to Step_8 soon.
** svn revision 6187

Cheryl, Rodica

Yesterday we measured isolation and transmission of the H1 Faraday isolator with the 4 mm thick DKDP installed. In the first run we measured while ramping up the power to ~140 W and optimizing the HWP and DKDP, the secon set was measured 3 hours later after the system cooled down slightly but without any additional optimization, and the third set was measured immediatelly after the second run, while ramping the power down.

Transmission is ~97%, forward extinction is ~ 25 dB and isolation stays above 25 dB at maximum power. Graphs are attached. The isolation is limited by the amount of stray light from ghost beams from the FI crystals that are dirrected toward the same power meter. 

Two viewports were fully installed on the south door of HAM01,  BF1 (ISC beam) and BF2 (PSL input).  The viewports are currently covered with viewport protectors.

Attached are plots are dust counts > .3 microns and > .5 microns in particles per cubic foot. Also attached are plots of the modes of the dust monitors to show when they were running. The data was taken from approximately 6 AM to 6 PM.

All control room TV displays are now configured to be used with h1.

I encountered some problems yesterday in moving the Beckhoff system at end Y from H2 to H1. The links were lost when I did a global search and replace in the PLC code to change H2 to H1. It is now running with H1 EPICS channel names, but as a temporary hack. The internal variables are still running as H2, I just changed the names to H1 in the EPICS database records. I will try doing a more selective search and replace and see if the links are still lost.

I also had to remove ONAM and ZNAM fields from a long record type. This will have to be fixed in the Beckhoff code, I believe in one of the libraries.

I copied/pasted/renamed the filters files used by the HEPI and the ISI at EY from H2 to H1. ISI currently is damped and HEPI is controlled.

I copied/pasted/renamed the filters files used by the TMS and the QUAD at EY from H2 to H1. The two systems are now damped. Coil driver analog whitening filters are turned ON (State 2) and FM2s of COILOUTF of the TMS are disengaged.

In the modified code I set it to ignore a dust monitor once it encounters an error with it. This was to avoid slowing down the loop waiting to read disconnected dust monitors. It appears that it is encountering these types of errors at random. So dust monitors are being set to invalid and then being ignored after momentary errors. I'm not yet sure the best way to address this. In the mean time, if a dust monitor goes invalid at random, you can bring up the expert screen for it and hit start. This should start it running again.