S. Dwyer, D. Hoak, J. Driggers, J. Bartlett, J. Kissel, C. Cahillane

We had trouble with the transition to ETMY, which turned out to be the same problem that we had with ETMX ESD driver this morning (20652) -- the Binary IO configuration was toggled such that high-voltage driver was disconnected, but we were still driving through the high voltage driver.  This was the source of several lock losses during this evening's maintenance recovery. We'd found it by comparing a conlog between now and during yesterday's DARM OLGTF measurements by the calibration group. Once we fixed it, we made sure to accept the configuration in the SDF (where we looked first, but it turns out that the wrong configuration had been stored there).

For the record, the attached screenshot shows the correct configuration for ETMY BIO. The good configuration is with have HI/LO Voltage OFF to run with the low voltage driver and the HI Voltage Disconnected (i..e the switch is OFF). In the same screenshot, we show what the DARM loop gain looks like with (yellow) locked on EX alone, (blue) a half-transition to EY when EY is in the bad configuration, (red) a half transition to EY with EY in the good configurtation.

I have taken the transfer function of the coil A, B, C, and D inputs to outputs on the Satellite Box (D0901284).
The measurement was taken with an SR785 sourcing the input through a Coil Driver Chassis to turn the input into a differential, and then fed through the Satellite Box.
We expected the Satellite Box to be have flat phase response and gain.  We have confirmed that to a tenth of a percent. (0.1%)
The Reference TF was taken of the Coil Driver Chassis by itself, and the residual calculation took our response from the Satellite Box Coil A over Reference TF.
The following was calculated using Satellite_Box_TF_Plotter.m located in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER8/H1/Measurements/Satellite_Box/2015-08-17/.

Dan, Jeff, Jenne, Sheila, TJ

As part of the SUS model restarts, safe.snap restores, and other business, some of the TMs were driven with large broadband signals for a short time.  This has rung up two of the violin modes which we have, until now, never been able to damp.

Part of the issue with recovery today was due to safe.snap files that had recorded the wrong filter settings for the violin mode damping.  When the Guardian turned on the gains, the filters were in the wrong state.  This tripped the L2 watchdogs and led to a fun evening of team-building and shared struggle.

We followed Nutsinee's wiki page and restored the correct filters.  Most of the modes damped rapidly and we were able to transition to DC readout with one stage of whitening on the DCPDs.

However, the excess drive to the ETMs has excited two modes which we've never been able to damp (and, until today, were small enough that we didn't mind).  These are 504.805 and 507.195 Hz.  Right now they're not terribly high, but we'll need to damp them if we want to enable a second stage of DCPD whitening.  Probably damping these modes will be another painful story like 508.289.  Between the two, 504.805 is worse, by a factor of twenty.  Based on the accounting of modes so far I think we can be certain this is an ITMY line.

The attached plot shows that, compared to the black reference from earlier today, many of the modes have been damped, except for the two marked by the crosses.

The other two modes which we've not been able to damp, 501.811 and 507.992, are also excited, but these are slowly damping.  We'll have to see how they evolve over the next couple of days.  I think we can also be sure that 501.881 is an ITMY line.

While Travis was working on initial alignment earlier today, we found that we were once again having trouble turning on the ASC for the X green arm.  I think the trouble was that the DC centering loops' error signals (from the green ITMX camera) were a little bit too large.  This isn't something that happens too often, but it definitely caused the ASC to pull the arm away from resonance.  Engaging the ASC without the DC centering was fine, so it's definitely something with that pair of loops.

By hand, I turned the gain on the DOF 3 loop for both pitch and yaw (which handles the DC centering) to half of the nominal value.  Once the error signals were closer, I put the gain back up at the nominal value for both loops.

Since this is a particularly tricky problem to troubleshoot, I've tried to handle it in the ALS Arm guardians. The modifications were made in the "generator" states, so they are the same for each arm.  The actual gain values for each arm are stored in the alsconst.py file, which is already loaded by the generator states. 

• In the ENABLE_WFS state, if the DOF3 error signal is large for either pitch or yaw, it'll turn the gains for DOF3 on to half of nominal.  If the error signal is not too large, carry on as usual, with the nominal gain.
• In the LOCKED_W_SLOW_FEEDBACK state, if the gain is not at its nominal value (i.e., it has been turned on at half of nominal), it will wait in the run state until the DOF3 error signals are small-ish, then it will ramp the gain up to the nominal value, and allow the guardian to continue.

I have loaded this new code, but it has not been fully tested, since we have not done initial alignment since I loaded it (and that's where it'll get used).  I've tried to test the logic in the guardian shell and that all seems to be fine, but there's no test like doing it live.  If it is giving errors that seem insurmountable, I did an svn checkin of the as-found code before I started modifying it (as well as another checkin after my edits), so we can go back one svn version. 

Jeff K, Jeff B, Dan, Jenne, Sheila

 -3.4 AS36 A I and -1 AS36 B I.  Note that the sign has flipped for AS36B.  

We can not use this matrix at 3 Watts, but it has been better consistently tonight at 15 Watts and above than the original, which was -3 ASA36I +-0.5 AS36BI.  I've added a few lines to the increase power state that changes this matrix once the power is above 15 Watts. 

Right now we are locked stably, but there is large noise that is coherent with ASC.  In the morning if inital alingment is redone it this matrix might not be usefull anymore, in that case you can comment out lines 2175 through 2177 of the ISC_LOCK guardian.

I started the shift taking over for Travis trying to lock DRMI. Sheila suggested another Initial Alignment, so we did and watched for the control signals to settle down between each step. This helped significantly. This eventually brought us up past DRMI but we had a few instances of the PUM watchdogs tripping (see Jeff's alog).

When the PUMs stopped tripping we then saw that the violin modes where very rung up. Dan worked his magic on those while showing me how it works. We got them down to a managable level and then rang into a problem in COIL_DRIVERS. Lost lock several times here, and the commissioners are working on a fix.

J. Kissel, S. Dwyer

Since we always seem to give Master Warner a hard time when he's just trying to do what we've asked, Shiela asked me to prove that commissioning HAM1 HPI, in attempts improve CHARD performance, is worth our time. As such, I attach a bunch of plots that supplement Jim's comparison of LLO vs. LHO HAM1 HEPI performance (see LHO aLOG 20538) taken while we're still trying to recover. I compare (regrettably uncalibrated) pitch and yaw ASDs of the REFL WFS against both the L4Cs in HAM1 and the GS13s in HAM3. We see that HAM1 is coherent with the features seen in the REFL WFS at 5-7 Hz and around the microseism -- which is a region which we can improve with HEPI inertial isolation -- and we see that our good ol' friend, the 0.6 [Hz] in HAM3, (see Integration Issue 1005) is coherent at ... 0.6 Hz, and indeed dominates a good fraction of total the RMS.

So, while the CHARD problem is complicated, because the REFL WFS contain CHARD motion, PR3 / PR2 motion, Input Beam Motion, some CSOFT, and their own motion, we can at least see that some protions of these signals can be improved if SEI were improved, which means we might be able to increase the bandwith of CHARD which would yield a more robust and stationary IFO. 

Sudarshan, TJ, Sheila

Yesterday the ISS second loop caused 4 locklosses.  Times of the first three are 2015-08-17 22:28:26 21:52:13 and 20:54:05, plots are attached. 

The problem seems to be that the first loop diffracted power was large yesterday (13%, maybe a result of PMC misalignment? ).  The reference signal level was hard coded into the IMC guardian, which doesn't seem like a good idea since this does drift somewhat and we don't want to loose lock when it does. 

We have tried to edit the guardian so that iss_diffracted_power_target is now a dictionary, it gets set to the current value of the diffracted power before the second loop is closed.  If we're feeling brave and satisfied that we have recovered from our maintence day, we will try to engage it again.

J. Kissel, T. Shaffer, J. Driggers, S. Dwyer

In addition to the one big blast of the PUM's Analog RMS Current Watchdog Trips this morning, at ~16:50 UTC (mentioned briefly in LHO aLOG 20654), we had three more instances of this silly watchdog tripping, which required drives to the end station.

Attached is a trend of the past 7 hours. The sad thing, is that there is no pattern. 
(1) The ITMs (Blue and Green) appear to *have* tripped when we've sent a blast to the PUM, but we've sent similar blasts since and they do not trip.
(2) ETMX (Black) has tripped when there is no signal sent to it.
This is why we always get into the blame game when we get a rash of these trips: 
- CDS says "What're you doing differently with the drive? It's gotta be you!" and 
- Users say "We're not doing anything different. It's a Tuesday! What did you do near these drivers?"
and nothing gets resolved.

Will someone please write an ECR to remove these Analog PUM WDs? 
The first action in said ECR should be to find what components this which dog is supposedly protecting, and to determine if it is actually protecting anything and/or if that component is actually in danger.
If first action deems that these are worthless, we should just rip them out. If-and-only-if they're not worthless and they're actually protecting some sensitive component that is unique to the PUM driver, then the second action would be to really study these circuits to understand what trips them, if the threshold is set correctly, and why there are so many false alarms. The third action should be, then, to fix them.

The Message: When these watchdogs trip -- especially when just one quadrant trips, and we send any number of large amounts of drive to the L2 stage, we ring up violin modes, and we suffer even more down time.

J. Kissel, B. Weaver
WP #5444
ECR E1500346
II 1097

We've completed the removal of the the violin mode monitoring from the QUAD models this morning. See attached model change screen shots. 

The good news: It has reduced the end-station's QUAD model's CPU clock-cycle turn-around-time from a range of (57 - 67) to a range of (53 - 61); see attached trend (DCUID 88 = ETMX, DCUID 98 = ETMY), which puts these models back under the 1/16384 [hz] = 61 [us] limit, so we should see a drastic reduction in clock-cycle overage timing errors.

The bad news, in the copy over, we've "lost" all of the band-limiting and low pass filters. They're not truely lost, because they're in the filter archive, but because the filter banks no longer exist in the QUAD models, they don't exist in the current foton file, so it's going to be an arduous, by-hand copy and paste between files. Nutsinee and Betsy will work on restoring these tomorrow.

The new front-end library part that is now a part for the violin mode damping that now lives in the OAF model:
/opt/rtcds/userapps/release/sus/common/models/DARMERR_VIOLIN_MODE_MONITOR_MASTER.mdl
which has been committed to the repo. I've also committed the new local version of the top-level model,
/opt/rtcds/userapps/release/isc/h1/models/h1oaf.mdl

They've been removed from this sub-library part of the QUAD_MASTER library:
/opt/rtcds/userapps/release/sus/common/models/FOUROSEM_DAMPED_STAGE_MASTER_WITH_DAMP_MODE.mdl

This closes out the above mentioned ECR and Integration Issue for LHO. 
For LLO to update:
(1) Update the above mention library SUS common library folder
(2) Update the LLO copy of the h1oaf.mdl model for demonstrative purposes
(3) Install SUS block as shown into l1oaf.mdl
(4) The new(ish) screens (see LHO aLOG 20378
for these can be found here:
/opt/rtcds/userapps/release/sus/common/medm/quad/
SUS_CUST_QUAD_L2_VIOLIN_MON_ALL.adl
SUS_CUST_QUAD_L2_VIOLIN_MON.adl

I've also saved new SDF tables such that the channels moved from the QUAD are no longer NOT FOUND.

We started off the morning with immediate PSL work (20638) and SR3 T2 OSEM troubleshooting (20618 requiring a full coil driver swap).  As part of the diagnostic of SR3 T2 OSEM issue, we recalibrated the DAQs on HAM5/6 (which involved restarting all of the user models on h1sush56.)

From there, we performed the planned restarts of the 4 QUAD models, the ODC model, and the OAF model.  While restoring the QUADs from SAFE to ALIGNED after the reboots, we found a bug in the SUS Guardians that caused them to go into error and not complete the transition (20627).  Kissel ended up putting the Guardians into Manual and toggling through states to finish the job.

However, the subsequent DAQ restart did not go well (20637), and we had to pause for a bit Dave to fix.

While PSL PMC work continued, various other planned tasks occured:

- Phone work at the EX

- TCSY Temp Sensor install

- HWS power supply swap

- EY/EX PEM Patch Panel and magnetometer work

- Jim HEPI filter investigations

- Kiwamu ALS DIFF PLL characterization

- ETM charge measurements

Around noon we started initial alignment.  We immediately ran into problems with:

- All 4 QUAD PUM coil watchdogs tripped due to some of the DARM DAMP VIOLIN MODE loop gains restoring to non-zero values and blasting the PUM with junk - I zeroed out these gains in the SAFE.snap files so this doesn't happen again after restarts.  The ISC_LOCK Guardian should set the gains appropriately.

- ITMx PUM had 1 coil watchdog trip which we could not clear from the medm - the PUM chassis was power cycled

- Found that a critical filter in the ITMy M0 LOCK P and Y backs were not restored to being ON after the front end restarts today - if the -140dB FM5 filter is not engaged in these loops the SUS gets a crazy kick due to giant error signals coming in from ASC during WFS steps of locking.  I have captured tha these filters get switched on in the SAFE.snap for future reboots.

- Found ETMy ESD latched to -16k  (20644)

- Found ETMx ESD not in a correct state - toggling HV ON/OFF caused it to latch to -16k (20652)

- Found ALS polarization is incorrect - bit of a stall while we stared at small error messages on the ALS screen - team commiss retuned the polar in the MSR.

So, in summary - we had 9 unexpected things happen today which took alot of troubleshooting time to diagnose and fix.

Back to continued locking - Jenne, Sheila, TJ are working on it. 

To be continued...

and finally to complete the set, here are the svn status of the safe.snap files.
All safe.snap files in the target/NAME/NAMEepics/burt/ directories are symbolic links to the userapps area.

M       /opt/rtcds/userapps/release/als/h1/burtfiles/h1alsex_safe.snap
M       /opt/rtcds/userapps/release/als/h1/burtfiles/h1alsey_safe.snap
M       /opt/rtcds/userapps/release/asc/h1/burtfiles/h1ascimc_safe.snap
M       /opt/rtcds/userapps/release/asc/h1/burtfiles/h1asc_safe.snap
M       /opt/rtcds/userapps/release/cal/h1/burtfiles/h1calcs_safe.snap
M       /opt/rtcds/userapps/release/cal/h1/burtfiles/h1calex_safe.snap
M       /opt/rtcds/userapps/release/cal/h1/burtfiles/h1caley_safe.snap
M       /opt/rtcds/userapps/release/cds/h1/burtfiles/h1ioppemmx/safe.snap
M       /opt/rtcds/userapps/release/hpi/h1/burtfiles/h1hpiham1_safe.snap
M       /opt/rtcds/userapps/release/isc/h1/burtfiles/h1iscex_safe.snap
M       /opt/rtcds/userapps/release/isc/h1/burtfiles/h1iscey_safe.snap
M       /opt/rtcds/userapps/release/isc/h1/burtfiles/h1oaf_safe.snap
M       /opt/rtcds/userapps/release/lsc/h1/burtfiles/h1lscaux_safe.snap
M       /opt/rtcds/userapps/release/lsc/h1/burtfiles/h1lsc_safe.snap
M       /opt/rtcds/userapps/release/omc/h1/burtfiles/h1omc_safe.snap
M       /opt/rtcds/userapps/release/pem/h1/burtfiles/h1pemcs_safe.snap
M       /opt/rtcds/userapps/release/pem/h1/burtfiles/h1pemmx_safe.snap
M       /opt/rtcds/userapps/release/pem/h1/burtfiles/h1pemmy_safe.snap
M       /opt/rtcds/userapps/release/psl/h1/burtfiles/dbb/h1psldbb_safe.snap
M       /opt/rtcds/userapps/release/psl/h1/burtfiles/fss/h1pslfss_safe.snap
M       /opt/rtcds/userapps/release/psl/h1/burtfiles/iss/h1psliss_safe.snap
M       /opt/rtcds/userapps/release/psl/h1/burtfiles/pmc/h1pslpmc_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susbs_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmx_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmy_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sushtts_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susim_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmx_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susitmy_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc1_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc2_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susmc3_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susomc_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr2_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1suspr3_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susprm_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussr2_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussr3_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sussrm_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sustmsx_safe.snap
M       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1sustmsy_safe.snap
?       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmxpi_safe.snap
?       /opt/rtcds/userapps/release/sus/h1/burtfiles/h1susetmypi_safe.snap

Here is the current SVN status of the front end filter file's svn status.

A reminder, in the /opt/rtcds/lho/h1/chans/ directory, all the filter files should be symbolic links to the appropriate userapps filterfiles area.

I found that the following chans directory files are not symbolic links:

H1CAL[CS,EX,EY].txt, H1SUSETM[X,Y]PI.txt

I found that all symbolic links used the absolute path of /opt/rtcds/userapps/release/ except for:

../../../userapps/release/sus/h1/filterfiles/H1SUSBS.txt

Here is the list of the svn status:

M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM1.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM6.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM2.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM3.txt
M       /opt/rtcds/userapps/release/isi/h1/filterfiles/H1ISIHAM3.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM4.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIHAM5.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIITMY.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIBS.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIITMX.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSPRM.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSPR3.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSSRM.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSSR3.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSOMC.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSITMY.txt
M       ../../../userapps/release/sus/h1/filterfiles/H1SUSBS.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSITMX.txt
M       /opt/rtcds/userapps/release/pem/h1/filterfiles/H1PEMCS.txt
M       /opt/rtcds/userapps/release/isc/h1/filterfiles/H1OAF.txt
M       /opt/rtcds/userapps/release/lsc/h1/filterfiles/H1LSC.txt
M       /opt/rtcds/userapps/release/omc/h1/filterfiles/H1OMC.txt
M       /opt/rtcds/userapps/release/lsc/h1/filterfiles/H1LSCAUX.txt
M       /opt/rtcds/userapps/release/asc/h1/filterfiles/H1ASC.txt
M       /opt/rtcds/userapps/release/asc/h1/filterfiles/H1ASCIMC.txt
M       /opt/rtcds/userapps/release/pem/h1/filterfiles/H1PEMMX.txt
M       /opt/rtcds/userapps/release/pem/h1/filterfiles/H1PEMMY.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSETMY.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIETMY.txt
M       /opt/rtcds/userapps/release/isc/h1/filterfiles/H1ISCEY.txt
M       /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSETMX.txt
M       /opt/rtcds/userapps/release/hpi/h1/filterfiles/H1HPIETMX.txt

and here are the scripts which generated it (running in the chans directory):

for i in 'awk '{print $1}' ../cds/model_info.txt';do echo $i|tr [a-z] [A-Z]|awk '{print $i".txt"}'>>/tmp/filtfilelist.txt;done

for i in 'cat /tmp/filtfilelist.txt' ;do ls -al $i >> /tmp/filelonglisting.txt;done

for i in 'grep  "->" /tmp/filelonglisting.txt |awk 'BEGIN{FS=" -> "}{print $2}'';do svn st $i;done

I have checked the SVN status of the source files used to build the front end models.

To do this, from the /opt/rtcds/lho/h1/target directory I ran the script

for i in 'sort -u */src/src_locations.txt';do svn st $i;done

This produced the output:

M       /opt/rtcds/userapps/release/cal/h1/models/h1calex.mdl
M       /opt/rtcds/userapps/release/cal/h1/models/h1caley.mdl
M       /opt/rtcds/userapps/release/isc/h1/models/h1iscex.mdl
M       /opt/rtcds/userapps/release/isc/h1/models/h1oaf.mdl
?       /opt/rtcds/userapps/release/sus/common/models/DARMERR_VIOLIN_MODE_MONITOR_MASTER.mdl
M       /opt/rtcds/userapps/release/sus/common/models/FOUROSEM_DAMPED_STAGE_MASTER_WITH_DAMP_MODE.mdl

On first run through I saw that my h1iopsuse[x,y] changes to add the additional ADC card for PI were not committed, so I have taken care of that.

Yesterday I got a chance to look at the phasing of REFL 45 WFS again, and to measure the sensing matrix for the REFL wfs with a new phasing.  In the end, these phasings were reverted so we could go back to running without recommisioning the loops.

I drove a line in CHARD pit, and phased the 45 WFS quadrant by quadrant to minimize the CHARD signal in I.

The phases of the CHARD pit signals have the appropriate phases for PIT with both the current settings and the ones that minimize the signal in I.  The motivation for doing this was to get a sensing matrix that would allow us to distinguish between CHARD and PR3 motion.  After rephasing I drove a line at 8 Hz in CHARD, IM4, and PR3 and measured the transfer function from the excitation to REFL WFS. For reference, I drove 3 Counts in CHARD P EXC, 100 counts inPR3 M3 drivealing P2P, and 1 count in IM4 M1 drivealign P2P.  The amplitudes of the lines were choosing to give good coherence, and I have not calibrated this measurement in any units, so only comparisons down the colmuns in this table are meaningful:

With these phasings, we should be able to use something in our input matrix like:

A9I+B9I-2*(A45I+B45I) to CHARD which would reduce the coupling of PR3 motion into CHARD which could be causing us some grief (alog 20523.) Currently we use only A9I+B9I.

A45I+B45I for PR3 should be a better option than it used to be for the PR3 loop, although we may still need some 9I terms to cancel CHARD. 

We can try closing loops around these new phases and adjusting our input matrix next time there is a chance. 

SudarshanK, FilbertoC

We installed an accelerometer at ISCTEY  (ISC table at ENDY) and a patch panel (D1300632) that routes the cable from outside the table to the inside. The corresponding channel for this accelerometer is H1:PEM-EY_ACC_ISCTEY_TRANS_X. The first plot is the spectrum of the newly installed accelerometer.

At ENDY, we installed a patch panel and routed the accelerometer (H1:PEM-EX_ACC_ISCTEX_TRANS_Y) through the patch panel on ISCTEX . The second plot is the spectrum before and after the installation.

Both patch panel were installed on the right side of the table on slot 3-7 which had a quintiple blank (D1100422) to start with. The optical table feedthrough layout document D1101126 for EY and D1201495 for EX needs to updated accordingly. Pictures attached.

No replacement of controller for IP-03 took place, the old Multivac controller decided to start working as I was retrieving settings, old controller stays, for now.