Patrick T, Daniel S

This was a long time coming, but we finally have an automatic medm/adl generator for the EtherCAT system. For each data structure in TwinCAT, we generate 3 screens:

• A record screen in table format which contains all fields,
• An error screen which contains the error status including the individual error messages, and
• A brief error message screen which can be imported into other medm screens to indicate the status.

The attached screen shot shows a couple of examples for the x end station. The screen at the lower left is the overview screen accessible from the sitemap under the SYS button. The two screen at the top left are record and error screens for H1:ALS-X. All fields are substructures which link to other screens. The two screens to the right show the record and error screens for H1:ALS-X_REFL_LOCK. The fields represent mbbi, ao, ao, ao, (substructure link), bi, longin, bo, longout, and longout EPICS records in this order. The errors are individual messages with no further links. 

The generation is done in two steps:

• The TwinCAT EPICS ioc produces an aml file for each structure it encounters based on the tpy file (which is also used to generated the EPICS database). The ioc also reads the lists of error messages which are stored in separate files. The aml file contains the necessary macro substitutions for the final medm screens.
• The installation script to restart the EPICS interface generates the actual medm screens after the ioc has started up and finished its initialization work . The medm screens get installed in $(USERAPPS)/ecat/h1/medm at LHO.

For this to work Patrick had to modify how the error messages are stored in the TwinCAT code. We now have a constant array of strings containing them rather than hardcoded in the code. There is one of these for each structure type which gets written to a separate file with extension exp. This change should be transparent.

The updated code and scripts have been installed in the x end station. Screens are available for all stations, but for the vertex and y end they could be slightly out of synchronization until we upgrade them as well.

I installed a DSUB9 breakout board at the DSUB9 rear panel output from the output mode cleaner DC photodiode prewhitening amplifier board in rack ISC R5. This is to enable acquisition of broadband (initially 100kHz bandwidth) power spectral densities of the DC photodiode output. 

   Posted below are the March temperature and relative humidity data from the Long Term Storage (LTS) Dry Boxes in the VPW. DB1 and DB4 are in use and partly loaded with parts. DB2 and DB3 were turned on on 03/31/15 and will be reported next month. 

   The trends look good, with mean rH at 0.23% and 0.27% and temperature at 71F for both boxes. The humidity spikes are incursions into the cabinets to add or remove parts. I am not sure what caused the almost 10 degree temperature drop in DB1 (not recorded in DB4) on 03/23/15, however there were no spikes in the rH during this time. Will investigate if a trend develops.    

Next Tuesday is the HAM6 vent!

• There will be a meeting this afternoon.
• East Door will be opened
• Invac accelerometers will not be installed since they are not here yet
• 2 cleanings, starting on Thursday (some of the cleaning crew will not be here on Friday
• See the white board for planned activities during the vent

Aiden will be coming up next week to work on the ETM tables.

Tuesday maintenance 8-12 will continue even though 3IFO is done.

Safety Meeting:

• If you break it, replace it!
• Aluminum found clogging the flutes in end mills
• Do not touch it unless you are authorized and are comfortable working with the equipment. There are many people who would be more than willing to help you out with any of the machine shop euqipment (John, Bubba, Rick, Doug, and more!)
• The authorization list will be updated soon
• Maybe a phone into the shop?
• This is a serious issue, these machines can easily take off appendages or much worse. Please respect the euipment and safelty procedures.

Before commissioning commenced this morning, I received the all clear to rebuild, install and restart the SUS ITMX & ITMY models that were modified last night to include DARM_CTRL signals (see LHO aLOG entry 17599).

- SDF snapshots were taken of both ITMs in SAFE state and checked into the svn
- BSC-ISIs were transitioned to OFFLINE state
- Models compiled, installed and restarted, with no issues
- ITMs WDs un-tripped and recovered to ALIGNED state
- BSC-ISIs WD'd un-tripped and recovered to FULLY_ISOLATED state

As, suspected, it was necessary to restart the DAQ process, which was carried-out courtesy of Jim B at approx 09:30am [PT], with no issues.

Sheila, Koji, Dan, Evan

Summary

Today we recovered a 35 Mpc lock and put the necessary steps in the Guardian.

Details

Bounce mode damping

For EY bounce mode damping, the DARM→EY element in the LSC output matrix is set to −1 and L3 ISCINF is enabled. Length feedback is entirely disabled on EY at this point. Then in the M0 DARM damping filter module, the +60° rotator and the bandpass are enabled, and the gain is −0.1.

Since this new damping feedback topology is not fully implemented on the ITMs, the DARM error signal is routed through LSC-YARM and into IX L3. In M0 DARM filter module, there is no phase rotation, only the bandpass at 9.7 Hz. I found that I needed to flip the sign of the gain compared to what we used to use; −80 seemed to damp the mode alright. Since this is a hack and likely will not be necessary 24 hours from now, it has not been put into the Guardian.

In both cases I have removed the 120 dB of gain from the bandpass FM and put it in a separate FM. This 120 dB is no longer sensible when using DARM control rather than DARM error.

Sheila has pointed out that any test mass which uses this damping scheme is ineligible to be used for feedfoward subtraction of other length DOFs, unless we come up with some workaround.

OMC ASC

As mentioned yesterday, we reverted the HAM6 centering scheme so that we could keep the interferometer ASC working.

Consequently, we now see scattering shelves in the DARM spectrum if the OMC ASC gain is set to 1. Setting it to 0.2 makes the DARM spectrum less painful to look at.

MICH coupling

Although tonight's campaign of noise coupling measurements was cut short by the PSL tripping, Koji and I managed to get a MICH→DARM transfer function with good coherence from 20 Hz to 400 Hz. The DTT files are attached.

For quiet data, one can look at 2015-04­-01 07:50:15 to 07:55:15.

Automation

Now that we have a reliable readback of the EY ESD state, the EX→EY transition has been reenabled in the Guardian.

The new final state is LSC_FF, which enables the MICH and SRCL feedforward and adds a cutoff to the SRCL loop.

Koji, Evan

The NPRO shut off at around 08:11:00 UTC.

The interferometer was locked with no measurements or injections running.

With help from Evan Hall, Jeff Kissel and Ross Kennedy, got preliminary spectra from REFL-I and IMC-I, with the idea of identifying high frequency lines. A plot and some data are attached. Here are the frequencies of lines and clusters identified in these plots. They were taken with the SR785 box next to WHAM1, using the GPIB/ethernet bridge to the control room and Eric Quintero's readout scripts.

There are two attached figures, one with the two ASDs in separate planes, the other with them overlaid. Notice that the cavity length mode at around 36kHz is not in exactly the same place in the two channels, and neither is the first harmonic at around 70kHz. Other narrow peaks, however, do line up.

REFL-Q
Frequency ; ASD 
1. 2440Hz ; 21uVrms/rtHz 
2. 13.9kHz ; 16uVrms/rtHz
3. 34.4kHz ; 16uVrms/rtHz - broadband, bandwidth 1.2kHz
4. 40.4kHz ; 9.7uVrms/rtHz
5. 56.7kHz ; 13.0uVrms/rtHz
6. 60.9kHz ; 5.7uVrms/rtHz
7. 62.4kHz ; 7.4uVrms/rtHz
8. 65.6kHz ; 6.6uVrms/rtHz
9. 66.3kHz ; 6.3uVrms/rtHz
10. 70.2kHz ; 18.9uVrms/rtHz - broadband, bandwidth 3kHz 

IMC-I
Frequency ; ASD
1. 2453Hz ; 2uVrms/rtHz
2. 13.9kHz ; 16uVrms/rtHz
3. 38kHz ; 4uVrms/rtHz - broadband, bandwidth 1.2kHz, but does not line up with REFL-Q peak 3.
4. 40.6kHz ; 2.4uVrms/rtHz 
5. 56.5kHz ; 2.4uVrms/rtHz
6. 62.4kHz ; 2.4uVrms/rtHz
7. 65.6kHz ; 3.1uVrms/rtHz - double peak, just resolved.
8. 69.1kHz ; 3.1uVrms/rtHz
9. 76.6kHz ; 9.3uVrms/rtHz - broadband, bandwidth 3kHz, but does not line up with REFL-Q peak 10.

I took the transfer function between H1:OMC-DCPD_A_OUT and H1:OMC_DCPD_B_OUT while the IFO was still at RF Readout.

The balance of the PD at DC is actually very good (delta<0.5%) but they are not well matched between 10-100Hz.
The difference is as much as 20%. The noise at high frequency is due to shotnoise between two PDs.

This could be caused by a mismatch between the V2cnt filters in the filter modules and the actual preamplifier filters in the vacuum chamber.
I'll look into this issue in the daytime as I don't want to screw up the overall calibration for DARM.

J. Kissel, E. Hall, S. Dwyer

After getting back to a reasonable DARM spectrum, we began experimenting with the new DARM_CTRL damped 9 [Hz] highest vertical mode. We quickly discovered that the change made for the ITMs won't work, because the single pipe in which ISC control comes into the suspension -- which is what we'd picked off the control point from to feed to the top mass -- can no longer contain DARM signals after we split / redistributed the LSC and OMC front-end code (i.e. there are no DARM to ITM output matrix elements in the LSC control).

Evan hacked around the problem for tonight by using the input matrix to pipe DARM_ERR straight through the YARM bank, and out to the ITMs.

However, for a more permanent solution, I've modified the ITM models (again) to include a new PCIe receiver of the H1:OMC-CAL_DARM_CTRL IPC channel (already being broadcast in the corner for the CAL-CS calibration of DELTA L EXTERNAL), which is now piped separately from DARM_ERR into the main QUAD block, and fed to the top mass for bounce damping.

The model changes for h1susitmx and h1susitmy are complete, I've confirmed that they can compile, and I've committed the changes to the userapps repo. The attached screen shots show the various portions of the model that were changed.

We (either Stuart or myself) will install and restart the front-end process in the morning.

 

J. Kissel, D. Barker, J. Batch, J. Warner, S. Aston

Advised by J. Smith that LHO is suffering from Major-Carry transition glitching (LHO aLOG 17555), we've taken advantage of the front-end model restart chaos to re-calibrate the BSC SUS 18-bit DACs -- i.e. taken all front-end "user" processes (i.e. the SUS code) offline, and restarted the IOP process for the h1susex, h1susey, and h1susb123 front end computers / I/O chassis, which runs each chassis' DAC cards through their auto-calibration procedure. Those front ends include DACs for H1SUSETMX, H1SUSTMSX, H1SUSETMY, H1SUSTMSY, H1SUSITMX, H1SUSITMY and H1SUSBS.

Sadly, I realize while writing this entry, and after rereading Josh's entry (LHO aLOG 17555), that he says that it's the -2^16 transitions that are most of the glitches. Indeed, I even got an email I got from P. Fritschel today, en passant, reminding me that J. Betz and he have shown that the recalibration procedure does not reduce the -2^16 [ct] transition glitching (see G1401269). Hurumph.

Anyways, the re-calibration will at least help with the drift in glitchiness of the other two transitions ( 0 and +2^16 , potentially seen in, e.g. 16354).

I attach procedural notes that I gathered during the restart process (I learned quite a bit!)

P.S. There may be a "danger" that auto calibration of the 8th DAC (or DAC cardNum 7 if you count from zero) on the h1susb123, which house the control for the PUM on ITMX and ITMY, as the h1susb123 dmesg reports that the AUTOCAL failed for this DAC:
[6643729.576353] h1iopsusb123: 18-bit dac card on bus 36; device 4
[6643729.576367] h1iopsusb123: pci0 = 0xdfefe000
[6643729.576391] h1iopsusb123: dac pci2 = 0xdfefc000
[6643729.576398] h1iopsusb123: DAC I/O address=0xdfefc000  0xffffc90011b08000
[6643729.576403] h1iopsusb123: DAC BCR = 0x40000
[6643729.576427] h1iopsusb123: DAC BCR after init = 0x20040000
[6643729.576432] h1iopsusb123: DAC OUTPUT CONFIG = 0xff
[6643734.724703] h1iopsusb123: DAC AUTOCAL FAILED in 5133 milliseconds 
[6643734.724712] h1iopsusb123: DAC OUTPUT CONFIG after init = 0x102ff with BCR = 0x40000
[6643734.724719] h1iopsusb123: set_8111_prefetch: subsys=0x8111; vendor=0x10b5
I've confirmed that for every other DAC card (5 in EX, 5 in EY, and the other 7 on B123) we re-calibrated today, the dmesg claims success.

J. Kissel, D. Macleod, J. Betzwieser
WP #5124

The hardware injection team wished to have separate filter banks for transient hardware injections -- one CBC and one for BURST -- to ease the automation of recording the information for later processing. There was previously only one called TRANSIENT. 

As such, Duncan modified the 
/opt/rtcds/userapps/release/cal/common/models/CAL_INJ_MASTER.mdl
library part, committed to the repo, that corner of which I updated, and recompiled, installed, and restarted the 
/opt/rtcds/userapps/release/cal/h1/models/h1calcs.mdl
front end model/code. 

Details:
- See attached screen shot for what the hardware injection corner of the h1calcs.mdl looks like now, with the update.
- The ODC vector for transient injections is now also split into BURST and CBC bits.
- This required a DAQ restart.
- I confirmed that there were no SDF system differences before restarting, so there was no need to capture a new safe SDF file.
- Since this was merely an update to the library part, there are no changes to the top-level model, so there's nothing to commit once finished.

J. Kissel, S. Dwyer

As we battle against wind again tonight, Sheila asked "Are there windy blends on the ITMs?" I replied, "No, but we can easily copy them from the ETMs."

As such, I've copied and pasted FM10, the 90mHz blends, of the H1ISIETMX CPS, L4C, and T240, CUR filter bank on ST1 into the corresponding CUR and NXT filter banks of H1ISIITMX, H1ISIBS, and H1ISIITMY. I attach a comparison between the 45mHz and 90mHz blends, generated by 
/ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/plot_current_blends.m
(where I've removed the RY filters by hand, because they're split between two banks and therefore what would be plotted can't be trusted)
 'cause I've never seen such a comparison before -- at least their complementary filter form.

We'll need more time with the IFO when it's more stable, but preliminary results -- where we'd switched the blends on ITMX in X and ITMY in Y to 90 [mHz] -- say that it isn't better. But they're preliminary, and I can't rule out that I've screwed up the copy-and-paste process. I'll double check everything once I don't have two more aLOGs to write.


P.S. Questions about the blend filters:
90mHz: 
- Do we really like these 90 [mHz] blends? 
- Seems like we should roll off the T240s way faster above 10 [Hz], like is done in the 45 [mHz] blends. 
- Do the Q's of the 0.5 and 1 [Hz] notches need to be that deep, or that what's *really* giving us the improvement when it's windy?
- Seems like the notches are at the wrong frequency, and could be moved down to get similar notching as the 45 mHz blends, and to better match the 0.43 [Hz] mode of the QUAD. Or maybe it's matching the 0.56 [Hz] pitch mode, which is actually the problem under windy conditions?

45mHz:
- Do we really like that much *un*complementarity in the 45 [mHz]? Maybe at this low a frequency, the loop gain is large enough -- even without the boost -- that any phase wiggle doesn't impact the stability during ramp up or nominal operations. But it'll certainly change the isolation loop error signal at low frequency when switching *between* blends. But also maybe not, because we've been able to successfully switch between 90 and 45 mHz blends on the ETMs for months now...

J. Kissel, S. Dwyer, J. Warner

Jim spent some more time trying to understand the difference in noise change in the HAM5 and HAM6 ISI X&Y directions (see LHO aLOG 17521) today, but left the HAMs in an odd configuration, where his new elliptic low-passes were turned ON for HAM5 X&Y and HAM6 X only. 

Having trouble locking the DRMI, we've turned these filters OFF. Not because we actually have reason to think they're the problem, but because we want one less thing to think about whether it *could* be the problem.

Also, because we otherwise can't think of how the additional elliptic low-pass can make anything *worse* -- except if it's only installed sporadically in random HAMs as Jim left it -- Jim has copy-and-pasted the filter to every HAM chamber in the X&Y DOFs, such that we *could* turn on the elliptic for *every* HAM in X&Y if we think it'll help.

These filters currently live in FM5 of the "current" CPS blend filter banks in X&Y (see attached example, called "EllipseP"), and they have a nice slow ramp time, such that you can turn them off and on willy-nilly. BUT because they're in a separate bank the blend switching doesn't work with them. Of course, if we end up really liking these filters, we'll combine them with the 01_28 blends, and we will be able to again blend-switch to our hearts' desire.

J. Kissel, K. Izumi
WP #5128

As per Rana's suggestion (LHO aLOG 17473), we've switched from using (the equivalent of) DARM_ERR to using (the equivalent of) DARM_CTRL for the error signal used for the M0/Top Mass, highest Bound and Roll mode damping of the QUADs on the ETMs. 

Details:
- Thankfully, this did *not* require adding any new IPCs -- all we did was replace the DARM_ERR M0 top-mass input "from" tag with a copy of the L3_ISC_DIST_L "from" tag, which is equivalent to the output of the L3 ISCINF L filter bank, which is post-IPC-signal-conditioned equivalent to the DARM_CTRL pick-off in the OMC model that's (of course!) already sent via RFM IPC from the corner to the end station. See attached screenshots.
- Because the all of the top level QUAD models are unhooked from the library (thanks to how tidal has been implemented differently at both sites, and which ASC sensor is used for damping the violin modes), this was an easy swap of "from" tags to the just-below-top-level QUAD block in each of the four QUAD models:
/opt/rtcds/userapps/release/sus/h1/models/
h1susetmx.mdl
h1susetmy.mdl
h1susitmx.mdl
h1susitmy.mdl 
and required no DAQ restart. This also therefore doesn't impact LLO or the QUAD library parts. All top level models have been committed to the repo.
- The models were compiled, installed, and then the restart was coupled with the recalibration of the QUAD computer's 18-bit DACs (separate aLOG pending).

SUS ADC move, ETM to AUX

Richard, Jim, Stuart, Jeff, Dave:

The second ADC in the h1susex, h1susey IO Chassis were removed and inserted as a fith ADC in the h1susauxex, h1susauxey chassis. The IOP models h1iopsusex and h1iopsusey were modified to remove ADC1. This did not affect the SWWD code, it only reads ADC0 channels. The IOP models h1iopsusauxex and h1iopsusauxey were modifed to add ADC4. These models were started when the front ends were powered back up after the hardware swap.

PEM Mainsmon DAQ rate increase [WP5123]

Robert, Dave:

I increased the DAQ data rate for the PEM MAINSMON channels, including the quadrature sum, from 256Hz to 1024Hz as approved by Peter in DCC document T1400768. I discovered that the ODC part in the model did not differentiate between end stations, resulting in duplicate channels in the DAQ ini files. I renamed these parts ODC_X and ODC_Y to remove the duplication. The 60Hz mains AC voltage now looks like a clean sine wave in the DAQ (please see attached image). This closes WP5123.

Suspensions recalibration of 18bit-DACs

Jeff, Jim, Dave:

Jeff restarted the SUS QUAD IOP models to perform a recalibration of the 18bit-DAC cards. He noted that some restarts completed too rapidly for the calibration to have been performed successfully (should be 5 seconds per DAC card). This was an intermittent problem, we should investigate on the DTS.

Sheila, Ed, Ross, Evan

This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402.  Some screenshots are attached.  There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ).  Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking.  As before this problem went away after a while, without us doing anything to fix it.  Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm.  The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm.  There are no coincident gliches in the Optical levers or in the Fiber control or error signals. 

It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss.  Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series.  I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.  

I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.