Patrick, Dave

The DAQ was reconfigured to acquire some CONLOG EPICS channels via the EDCU. A new H1EDCU_CONLOG.ini file was created by Patrick, I added it to the h1dc0 master file. The configuration change was activated by the DAQ restart at noon today.

Jim, Dave

We waited until the HAM2 SUS IM team had completed their measurements before attempting to recover h1sush56 front end. The computer was is a locked state from last night during model changes to h1sussr3. We took the user models out of rtsystab (so they would not auto start), remotely took h1sush56 out of the Dolphin fabric and pressed the RESET front panel button. The computer booted and ran the IOP model with no problems. We restored the systab and started the h1sussr3 (modified) and h1sussrm (unmodified). They both exhibited a 0x2bad DAQ status, but the IOP kept good. We then restarted the DAQ, restarted these models and all is well on h1sush56. Looks like mx_streams between the FE and DAQ was in a strange state, but why was the IOP model good?

After the DAQ restart, the h1susauxey front end went into a bad DAQ state which was cleared by restarting its mx streams.

This morning while Hugh was working on ETMX HEPI actuator installs, I did some investigating on a problematic actuator on corner 3 (SE). This actuator was initially attached, but was found to pull the system down .020", about half of it's range, so it was detached. When the actuator was installed, it had shims added that held it in its nominal position, roughly the middle of its travel, and in this state its position sensor read 3300 cts (0 is center, ideally). When I pulled the shims with the pier valve in the run position, but the Parker valve (HEPI actuator valve) unplugged (to ensure no drive on the actuator) the actuator contracted until it railed the IPS (-32000 cts). When I closed the pier valve, the actuator moved back to -9500 (about .010") cts, which I think is probably a normal shift ( .005 is a normal shift when attaching, but the HEPI main springs are pulling the other direction at that point, not the case here). Pretty sure this means we need to replace the Parker valve.

Updated the Conlog medm and sitemap link.

Restarted Conlog and set the prefix to H1:CDS-CONLOG_. The sitemap CDS->Conlog link should now work.

Cheryl asked if we could get TFs for IM2, IM3 and IM4 to complete the IM1 set from 8287 before the HAM door is removed, so I set them going in parallel in three Matlab sessions on opsws7. They should be done by about 11:30 am.

Data is flowing to the data concentrator again, but h1sush56 is locked up.  Restarting will almost certainly take down the Dolphin IPC network, which will disrupt most of the computers in the corner station.  So don't get too excited about taking data this morning until the system is stable.

I was looking to upload the source code tar ball for the record in LHO aLOG 8325, but after selecting the file in the browser, I hit the "upload file" button and the file just disappears from the browse field without uploading anything.

We've requested that *any* file type should be upload-able, as long as it's under the 10 Mb limit (see LHO aLOG 3798 and subsequent comments) but I guess the infrastructure doesn't allow for it?

P.S. looking if we've requested this before ('cause I thought ), I rediscovered a report of a bug that's still present:
.

J. Kissel

I've now updated the HLTS front-end simulink models as per ECR E1300578, similar to the QUADs, TMTS, and BSFM, as described in G1301192. After successful compilation of both H1SUSPR3 and H1SUSSR3, Fabrice informed me that Arnaud was gathering some data looking for long-term drift on PR3, so I only installed and restarted SR3. Of course, up successful compilation and install, I went to restart the front end with the new process and it hung halfway through, completely taking down the data concentrator / frame builder / DAQ, and took down the entire h1sush56 front end. I attach a screenshot of the CDS overview screen. *sigh*. The reigning king of finding crazy obscure bugs in CDS and exercising them wins again. The only debugging I've done is trying to reboot the data concentrator once, by doing the following

controls@opsws3:models 0$ telnet h1dc0 8087
Trying 10.101.0.20...
Connected to h1dc0.cds.ligo-wa.caltech.edu.
Escape character is '^]'.
daqd> shutdown
OK
Connection closed by foreign host.
controls@opsws3:models 1$

This brought back *some* of the front ends back up and to green status (The SEI and SUS computers at the end stations), but the corner is cooked.

Sorry Arnaud, and anyone else who was gather data overnight.

Giving up for the night and will continue fighting the good fight tomorrow morning.

I tried uploading the source from the target area, but the aLOG doesn't like tar.gz's at all.

------
Here's the status of the sus corner of the SVN repo that's a result of my work:

MM      common/models/HAUX_MASTER.mdl                  # haven't started on the HAUX yet
MM      common/models/HLTS_MASTER.mdl                  # changes complete, but don't want to commit until I can successfully start the front end process
M       common/models/SIXOSEM_T_STAGE_MASTER.mdl       # same as above
MM      common/models/MC_MASTER.mdl                    # haven't started on the HSTS yet
M       common/models/OMCS_MASTER.mdl                  # haven't started on the OMCS yet
M       common/models/SIXOSEM_T_WD_AC_MASTER.mdl       # changes complete, but don't want to commit until I can successfully start the front end process
M       common/models/SIXOSEM_T_WD_DC_MASTER.mdl       # changes complete, but don't want to commit until I can successfully start the front end process
MM      common/models/HSTS_MASTER.mdl                  # haven't started on the HSTS yet

M       h1/filterfiles/H1SUSTMSX.txt                   # Haven't committed since new code has been installed, these still need a hand clean up of now-vestigial filter banks
M       h1/filterfiles/H1SUSTMSY.txt                   #     | 
M       h1/filterfiles/H1SUSBS.txt                     #     | 
M       h1/filterfiles/H1SUSSR3.txt                    #     | 
M       h1/filterfiles/H1SUSETMX.txt                   #     | 
M       h1/filterfiles/H1SUSETMY.txt                   #     | 
M       h1/filterfiles/H1SUSITMX.txt                   #     | 
M       h1/filterfiles/H1SUSITMY.txt                   #     V
 
M       h1/models/h1susprm.mdl                         # haven't started on the HSTS yet
M       h1/models/h1sussrm.mdl                         #     |
M       h1/models/h1suspr2.mdl                         #     V
M       h1/models/h1suspr3.mdl                         # changes complete, but don't want to commit until I can successfully start the front end process
M       h1/models/h1sussr2.mdl                         # haven't started on the HSTS yet
M       h1/models/h1sussr3.mdl                         # changes complete, but don't want to commit until I can successfully start the front end process
M       h1/models/h1susomc.mdl                         # haven't started on the OMCS yet
M       h1/models/h1susmc1.mdl                         # haven't started on the HSTS yet
M       h1/models/h1susmc2.mdl                         #     |
M       h1/models/h1susmc3.mdl                         #     V

I noticed that Conlog was not reconnecting to some PEM channels after their IOCs were restarted.

One hypothesis is that it may need to have the caRepeater running, which it has not been.

I stopped Conlog around 18:12. I set the environment variable $PATH to include the path to the caRepeater binary. I restarted Conlog. I got an error not finding a library needed by caRepeater. I stopped Conlog and set the environment variable $LD_LIBRARY_PATH to include the path to the library. I restarted Conlog and it ran without any further errors. These environment variables are set in /home/controls/bashrc_import which is sourced by /home/controls/.bashrc on h1conlog.

It remains to be seen if this fixes the problem.

Should get the remaining Actuators attached tomorrow morning.

Today's activities:
- Jim W, to LVEA, lock HEPI HAM02.
- Sheila, RefCav locking lesson to operator.
- Richard M, to LVEA, cable work under HAM02.
- Apollo crew, to LVEA, move IOT2L.
- Apollo crew, door prep work, HAM02.
- Betsy, LVEA, SR2 work.
- Jim W, to LVEA, HEPI lock HAM03.
- Apollo crew, to LVEA, door prep work, HAM03
- Filiberto, LVEA and X-end, ESD measurements.
- Mitchel & Thomas, MCB assembly work, West bay area.
- Hugh and Greg, X-end, HEPI work.
- Jim B and Dave B, to Y-End, troubleshooting.

Vendors:
- Porta potty service.

(Sheila, Gerardo)

Sheila showed me how to lock the reference cavity.
One change occurred to get the system to behave, Sheila lowered the resonant threshold down to 0.5 V from 0.9 V.
The reference cavity was able to lock manually, but now it appears misaligned when locked.

Jim, Cyrus, Dave

Rolf added a new feature to RCG2.8 to permit a front end to run without an IRIGB card (GPS time is obtained via EPICS Channel Access from a remote IOC). We are in the process of testing this on h1pemmx. 

To prepare for the test, I added the line "remoteGPS=1" to the CDS block on h1ioppemmx. I added a cdsEzCaRead part, reading the GPS time from the DAQ data concentrator on channel H1:DAQ-DC0_GPS. I svn updated the trunk area, and compiled h1ioppemmx and h1pemmx against the latest trunk.

Test 1: keep the IRIG-B card in the computer, restart the IOP model several times. We noticed that the sync of the GPS time from IOPPEMMX and its reference DC0 does change from restart to restart but keeps synchronized to within a second.

We are in the process of test 2, removing the IRIGB card from h1pemmx. At the same time, Cyrus is reconfiguring the X-ARM switching sysems for the FrontEnd and DAQ switches, which will permit replacement of two netgear switches at MX with media converters. The use of full switches to support a single front end computer is obviously wasteful.

On completion of today's IRIGB tests, we will re-install the IRIGB card and reload the 2.7.2 version of the IOP and PEM code. While this test is progressing the DAQ status from MX is 0x2000 and its data is bad.

I will start transfer functions of top mass of main and reaction chain of ITMX phase 3a (in chamber, under vacuum) on computer opsws2 and top mass phase 2b SRM (test stand) on computer opsws0 from 8pm tonight.

Measurements will run until saturday morning. Please do not close those matlab sessions if you come over the week end.

The channel list used to get the data from the framebuilder (in generate_channel_list.m living in sus/trunk/Common/Matlabtools/SchroederPhaseTools) has been modified to match with the recent model upgrade of the QUADS. Since channels H1:SUS-${QUAD}_${L1/L2}_DAMP_${DOF}_IN1_DQ do not exist any more. They are now called H1:SUS-${QUAD}_${L1/L2}_WIT_${DOF}.
This is related to why we couldn't get data out of the frame for the ETMX on thursday
This is also related to why we couldn't see any good calibrated rotation signal with dataviewer on ETMX for the UIM and the PUM

[Kiwamu, Paul]

Just before the vent today we measured new noise spectra for the frequency and length feedback paths.

The 'whitening filters' in the IMC_X path (see Giacomo's LHO alog entry 5311) were not engaged. They were put in the model at LLO in an attempt to combat the digital noise in IMC_X above ~50Hz (see Anamaria's LLO alog entry 5821) but need to be taken account of when plotting the data.

We corrected the IMC_F frequency to length calibration to give the equivalent motion of MC2, instead of the equivalent round trip length change. This has now been edited in the filter bank for the IMC_X path; the FtoL filter has been changed to a DC gain of 5.8465e-14 (dX=df x lambda/(2FSR)). 

Relevant paramters during the measurement:

Common mode gain 20dB

Common mode filters: Compensation and 1st Boost

Fast gain -2dB

Slow path bypassed offsets and filters

MC2 M3 lock gain -1000, engaged filters: 150:4 and CLP100

MC2 M2 lock gain 0.06, engaged filters: 0.01:0.1, 0.03:1, Stab8:2, 300:1 and ELF80

Damping filter: resg and Ellip50 (the filter in IMC_X path was switched to the wresg filter to reflect this change)