- Resonant at 55MHz. The transimpedance is 258Ohm. That is about half of REFL55 (don't know why).

- 11MHz&110MHz notch

- The 200MHz oscillation of MAX4106 was damped by the same recipe as REFL11.

Alaska M7.5 20:54UTC https://earthquake.usgs.gov/earthquakes/eventpage/us6000c9hg/executive

I looked at the suspensions. The watchdogs have not been tripped.

IMC was locked but continually shaken. (and occasional unlock)

I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.

The cat and donkey? were making much noise.

There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.

please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding.

I assume that we are prepared to live with the pitch bias situation of ETMY (i.e. we can achieve a configuration in which there is some pitch bias to the coils, and the OSEMs are inserted such that the PD outputs are half their maximum value). Or at least that we don't want to go through the whole standoff-regluing procedure for ETMY as well.

So today I took the optic out, and began to make some preparations for the air bake.

• Both optics are now sitting in their respective metal donuts. 
• How do we want to bake the optics? Bob has said he has prepared the oven for this bake, and that he has configured the temperature controller to a setpoint of 34C, and a ramp time of 2 hours to reach that temperature from lab temperature (we should check this before putting the optics in there with our independent temperature sensor - also, he is away for the week now so we can't get his input on any of these). But what about the actual logistics of how the optics are going to be housed? Specifically:
  • Do we want the donut to sit on some sort of tray? Presumably it is not ideal to have the HR surface in close proximity to the oven floor? 
  • Does the oven need any special cleaning?
  • Do we cover the donut+optic setup with a glass jar? If we do, any particles we eject off the optic can't escape the confines of the bowl, and if we don't, detritus from elsewhere may settle on the optic?
  • How long do we want this bake to last? 24hours? 48 hours? Bob didn't have an answer when I asked him earlier in the afternoon...
• I also removed the suspension block from the top of the towers of both ETMX and ETMY, so that Steve could work on sanding them before we acetone-wipe and bake the towers themselves.
  • It was very apparent that the weights of the two pieces were largely different (ETMY suspension block ~350g, ETMX suspension block ~960g), even though they have the same physical dimensions.
  • Investigation into why this was yielded nothing conclusive. But Steve and I think that the ETMY suspension block is made out of Aluminum rather than SS, which would explain why the wire grooves seem deeper in the ETMY piece than the ETMX piece. It is worth noting that the specification calls for SS and not aluminum. But the top piece of the ETMY suspension (and indeed the old ETMX suspension) looks different from the specification, in that they don't have tapped holes for the secondary wire clamps (see Attachment #1).
  • I'm not sure if this is important, but it is worth noting. Steve and I also checked the remaining suspension towers. We think that ITMY, BS, SRM and PRM have the correct (to specification) suspension block. We couldn't get a look at ITMX and didn't want to take the door off. So ETMY (and possibly ITMX) will be the only suspension(s?) with a different suspension block.
• Steve's sanding efforts did not go ideally.
  • He was successful in removing the wire grooves.
  • But the sharp edge which is supposed to clamp the wire seems to have been rounded a little bit (see Attachment #1). 
  • Overall, the section that we was sanded looks lower (i.e. its like we've dug a small channel into the plane of the suspension block)
  • Given that we suspect the ETMY suspension block is Aluminum, it is likely that attempting to sand it will yield an even deeper channel.
• Do we want to bake the suspension towers in the large baking oven? Presumably we don't want to bake the optics with anything else. But does the large oven need any special cleaning before we stick the towers in there?
• ETMY has some acetone marks on it. I will try and have this removed by drag wiping with more acetone and isopropanol prior to the bake tomorrow. Anyways we will first-contact clean the HR (and AR) sides after the bake before installing the optic.

In summary, the questions that remain (to me) are:

1. Are we okay using an Al suspension block?
2. How perfectly do we want wire grooves from prior suspensions removed? It looks like sanding doesn't work well, do we want to consider sending this into the shop?
3. Baking logistics, as described above.

I think we can start the baking of the optics tomorrow. The timeline for the suspension towers is unclear, depends on how we want to deal with the sanding dilemma.

I took the two cages, wires and wire clamps out this morning, back into the cleanroom after their 12 hour 70C bake. 

I've also applied first contact to the AR face of the optics. Steve is preparing a jig which will allow us to apply first contact on the HR side with the optic horizontal. The idea is to apply a large coating first, to clean the bulk of the HR surface, and peel it off before re-suspending the optic. Then we can paint on a smaller area, suspend the optic (and hope the pitch balancing is alright) before taking the whole assembly into the chamber where it will be peeled off. 

Calum recommended that we buy a new ionizing gun + electrometer assembly (apparently our current set up is woefully obsolete) but I don't know if we can have these in time for the first contact peeling...

I just put in the following into the air bake oven for a 12 hour, 70C bake:

• ETMX and ETMY cages (with sanded suspension blocks loosely tightened for now, we will tighten them after the bake)
• 13 new wire clamps that were recently made by the shop
• 7 lengths of suspension wire (since the new wire is unlikely to arrive for another 2 weeks). This should be sufficient in case we overtighten the wire clamps a couple of times and the wire snaps.

I put these in at 10.30pm. So the oven will be turned off at 10.30am tomorrow morning. The oven temperature seems stable in the region 70-80 C (there is no temperature control except for the in built oven control, I just adjusted the dial till I found the oven remains at ~70C.

Tomorrow, we will look to put on first contact onto the ETMs, and then get about to re-suspending them.

I turned off the air bake oven at 8:45AM. I'll leave the optics alone for a bit while it cools.

I put in both ETMX and ETMY into the air-bake oven at approximately 8.45pm tonight. They can be removed at 8.45am tomorrow morning. 

• Given that we had previously melted a thermocouple in this oven, and there have been no high temperature bakes in it since, we ran the oven at 100C for about 3 hours in the afternoon
• After that, I left the oven door open for an hour for the interior to return to room temperature
• I then re-connected the controller (which doesn't seem very precise, it pulses the AC power to the oven in order to control the temperature), and dialled the oven back down to heating level 4, which is what Bob had it set at. I then waited for a couple of hours for the oven to reach ~34C
• Before putting the optics in, I gave the inside of the oven a quick wipe with a clean wipe, and palced a layer of Al foil on the bottom of the oven
• The optics are sitting on their donuts (see Attachment #1) - the copper wire elevates the optic+donut slightly and provides a path for air flow
• ETMY was drag wiped with acetone+isopropanol prior to baking (to remove acetone stains from soaking to remove epoxy residue
• We will of course be cleaning the optics with first contact prior to re-installation in the vacuum chambers
• I am not sure what the extra cylindrical piece in there is, but Bob advised me to leave it in there so that's what I did
• I've observed the temperature over ~2hours since I first put it in, and the oven/controller isn't going bonkers, so I'm trusting the controller and leaving for the night

Air condition maintenance is happening. It should be done by 10am

The air handler on the roof of the 40M that supplies the electronics shop and computer room is out of operation until next week.  Adding insult to injury, there is a strong odor of Liquid Wrench oil (a creeping oil for loosening stuck bolts that has a solvent additive) in the building.  If you don't truly need to be in the 40M, you may want to wait until the environment is back to being cool and "unscented".  On a positive note, we should have a quieter environment soon!

Anchal, Paco and I agreed to follow the polarity conventions below for suspension damping loops.
Some of the polarity/gains were changed to homogenize all the suspensions to the convention.
All the suspensions are homogenized except for MC1 (which have all - in sensor inputs and all - in coil outputs) and AS1 (SDCOIL_GAIN have the same sign as LL).

*SEN_GAIN to be +1
INMATRIX to be the following, and calibrated so that SUSPOS/SIDE_IN will be um and SUSPIT/YAW_IN1 will be urad (calibration to be done later)
+ + + + *
+ + - - *
+ - - + *
* * * * +
SUS*_GAINS to be +
TO_COIL gains to be the following
+1 +1 +1  *
+1 +1 -1  *
+1 -1 +1  *
+1 -1 -1  *
 *  *  * +4
*COIL_GAIN to be the following or flipped one so that SUS*_GAINS will be +
+
-
+
-
+

To do this, the following changes were made

For BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY, MC1, MC2 and MC3 ("old" suspensions), TO_COIL_5_4_GAIN (for side) is changed from +1 to +4 and SUSSIDE_GAINs are divided by 4 accordingly.
For ETMX, the sign of SUSSIDE_GAIN is flipped to +, and SDCOIL_GAIN to be -1 (it was +1).
For MC1, *SEN_GAINs are - (not following the convension; see 40m/16894). The sign of INMATRIX_4_5 (for side) is flipped to +, SUSPOS/PIT/YAW_GAIN are flipped to +, and *COIL_GAIN are flipped to - (not following the convension). IMC WFS output matrix components for MC1 were also flipped. 

It is stored along with the cables that arrived a few weeks ago, awaiting the gauges which are now expected next week sometime.

Chub & Steve,

We swapped in our  replacement of Varian V70D "bear-can" turbo as factory clean.

The new Agilent TwisTorr 84 FS  turbo pump [ model x3502-64002,  sn IT17346059 ]  with intake screen, fan, vent valve. The controller  [ model 3508-64001, sn IT1737C383 ] and a larger drypump IDP-7,  [ model x3807-64010, sn MY17170019 ] was installed.

Next things to do:

1. implement hardware interlock to close V4 at 80% pumping speed slowdown of "standby" rotation speed, estimated to be ~ 40,000 RPM ( when Standby 50K RPM  )
2. set up isolation valve in the foreline of TP2, with delayed start of the IDP-7 and/or use relay to power drypump.  This turbo controller can not switch off or start of the dry pump. [ Agilent isolation valve #X3202-60055, with position indicator, pneumatic actuation, 115V solenoid ]..........as a second thought, we do not need isolation valve if we go with the relay option. The IDP-7 has built in delay of 10-15 sec
3. test performance of new turbo

These are the things that I can think of that we need to do before we can close up:

* Take a close look at both ITMs' OSEMs, and ensure that the magnets aren't too close to either plate in the OSEMs.  Both have had funny business over the past week.

* Do a free swinging test on both ITMs.  (ITMY may not need it, if we haven't touched it since the last free swinging test, but it can't hurt to take the data)

* Confirm that POX is exiting the chamber.

* Is there anything else???

Our goal is to finish this work by tonight, so that we can close doors and start pumping tomorrow.

Gave the elog its afternoon / tea-time reboot, since it was hanging yet again.

What was done:

1) Turn off MC1, MC2, MC3, BS, ITMX, ITMY, PRM, SRM watchdogs.

2) Turn c1sus computer off (sudo shutdown now)

3) Go connect monitor and keyboard to c1sus.  Turn c1sus on.

4) Hit "del" key at the right time to go to setup (BIOS).

5) Go to BIOS advanced tab, CPU options, enable Multi-threading.

6) Hit F10 to save and let the computer continue booting.

What went wrong:

Once c1sus was up, I noticed several red lights and dead keep alives for the c1sus models.

Typing dmesg on c1sus revealed many messages like:

[  107.583420] c1x02: cycle 33737 time 20; adcWait 10; write1 0; write2 0; longest write2 0
[  107.583771] c1x02: cycle 33760 time 19; adcWait 11; write1 0; write2 0; longest write2 0

This indicates the Input/Output Processor (IOP) is not completing its duties within the 15 microseconds (1/64 kHz) that it has.  These lines indicate its take 20 or 19 microseconds.  (I saw messages ranging from 16 to 22 microseconds).

So this seems to agree with Rolf's observations that hyperthreading can cause a 5-10 microsecond increase in computation time.

So the next thing to do is modify which core the codes are running on, and try to get them paired up on the same physical core.

[Jamie, Manasa, Jenne]

We started by verifying that the tip-tilts were getting the correct signals at the correct coils, and were hanging properly without touching.

We started with TT2.  It was not hanging freely.  One of the coils was in much further than the others, and the mirror frame was basically sitting on the back side yaw dampers.  I backed out the coil to match the others, and backed off all of the dampers, both in back and the corner dampers on the front.

Once the mirror was freely suspended, we borrowed the BS oplev to verify that the mirror was hanging vertically.  I adjusted the adjustment screw on the bottom of the frame to make it level.  Once that was done, we verified our EPICS control.  We finally figured out that some of the coils have polarity flipped relative to the others, which is why we were seeing pitch as yaw and vice-versa.  At that point we were satisfied with how TT2 was hanging, and went back to TT1.

Given how hard it is to look at TT1, I just made sure all the dampers were backed out and touched the mirror frame to verify that it was freely swinging.  I leveled TT1 with the lower frame adjustment screw by looking at the spot position on MMT1.  Once it was level, we adjusted the EPICS biases in yaw to get it centered in yaw on MMT1.

I then adjusted the screws on MMT1 to get the beam centered at MMT2, and did the same at MMT2 to get the beam centered vertically at TT2.

I put the target at PRM and the double target at BS.  I loosened TT2 from it's base so that I could push it around a bit.  Once I had it in a reasonable position, with a beam coming out at PR3, I adjusted MMT1 to get the beam centered through the PRM target.  I went back and checked that we were still centered at MMT1.  We then adjusted the pitch and yaw of TT2 to get the transmitted beam through the BS targets as clear as possible.

At this point we stopped and closed up.  Tomorrow first thing AM we'll get our beams at the ETMs, try to finalize the input alignment, and see if we can do some in-air locking.

The plan is still to close up at the end of the week.

Just for reference! The changes made to the TT matrix in order to fix the polarity problem:

The old matrix values are mentioned in elog!

PIT    YAW                   New                   

Pit slider           |  -100   -100  |  UL  


     0               | -100    100   |  LL


Yaw slider           |  100   -100   |  UR


    0                |  100    100   |  LR

Before lunch we took a closer look at two of the suspensions that were most problematic: ITMY and ETMY.  Over lunch we took new free swinging data.  Results below:

• For ITMY we discovered that the whitening on the UL sensor was not switching.  This was causing the UL sensor to have a different response, with a steeper roll of, which was causing all of the transfer function estimates to the other sensors to have large imaginary components.   We took new free swing data with all of the whitening turned OFF.  The result is a much improved matrix and diagnalization.  The input matrix elements are mostly the same, but the coupling is basically gone.  We'll fix the whitening after the pump down.

ITMY

pit     yaw     pos     side    butt UL    0.157   1.311   1.213  -0.090   0.956  UR    1.749  -0.490   0.886  -0.038  -1.042  LR   -0.251  -2.000   0.787  -0.007   1.066  LL   -1.843  -0.199   1.114  -0.059  -0.936  SD   -0.973  -0.205   1.428   1.000   0.239

4.34779

• ETMY has a very problematic SIDE OSEM.  The magnet does not line up with the OSEM axis, and since there is no lateral adjustment in the side OSEMs, there's not much we can do about this.  We're using aluminum foil to wedge the OSEM over as far as possible, but it's not quite enough.  With the OSEM plates horizontal there is a lot of POS->SIDE coupling.  With the OSEM plates vertical, the magnetic sits a little too close to the rear face, which can cause the magnet to get stuck to the LED plate.  We're trying to decide where to leave it now, but the new diagnalization with the OSEM plates vertical is definitely better: 

ETMX

pit     yaw     pos     side    butt UL   -0.138   1.224   1.463  -0.086   0.944   UR    0.867  -0.776   1.501  -0.072  -1.051   LR   -0.995  -0.896   0.537  -0.045   0.754   LL   -2.000   1.104   0.499  -0.059  -1.251   SD    0.011   0.220   1.917   1.000   0.224

4.42482

[Rana / Kiwamu]

 We put some elements in the BS output matrix to mitigate the actuator coupling from SIDE to POS.

As a result the degree of the coupling reduced by a factor of 2 or so.

Rana did the "Q of 5" test on the SIDE damping servo after putting the elements and set the gain to be 40.

The attached screen shot is the new elements that we put in the suspension output matrix.

(How to)

• Excite the SIDE motion by AWG at 3 Hz.
• Monitor the POS signal in DTT
• Try some numbers in the matrix elements until the peak at 3 Hz in the POS signal is minimized

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

The following code is incredibly useful when creating  MATLAB plots as it adds the filename of the script to the plot itself. I think it should be used for all MATLAB plots that go on the elog.

For example, I have no idea where the data/script is that was used to generate these plots.

orient landscape

xposn = 0.0;

yposn = -0.13; % you sometimes have to tweak this value depending on the page size and the number of subplots


text(xposn,yposn,[filename('fullpath'), '.m'], ...

     'Units', 'normalized', ...

     'Interpreter', 'none', ...

     'FontSize', 6)

print('-dpdf', [filename('fullpath'), '.pdf'])

Today I updated the ETMY suspension model to include 4 new filters at the output of the position, pitch, yaw and side summers and before the "To Coil Matrix". The library that was changed and updated is "sus_single_control_new". These callibration filters are labeled in the orange box as POSCAL, PITCAL, YAWCAL, and SIDECAL. The four filters are important as the will allow us to callibrate the position and side from counts to micro meters, and pitch and yaw from counts to micro radians.

The next steps for utilizing this update will be

    - create a few experiments to find the callibration constants for the 4 degrees of freedom

    - edit and update the ETMY Suspension screen to include selectable filter boxes to implement the callibration constants

For future reference, preform the update and restore the models to their previous states you may use the following:

to install the models we ssh into the computers running the ETMY suspension models (for example)

     ssh c1sus

then for each model using the suspension library (we used c1sus c1mcs c1scx c1scy c1su2 c1su3) do

     rtcds build-install c1sus

the watchdogs will need to be shut down for c1sus and the model will need to be restarted next

     rtcds restart c1sus

Now we restore the filter values to the last saved point (about an hour before the update) in cds folder

     python burtRestoreRTSepics.py -m c1sus c1mcs c1scx c1scy c1su2 c1su3 -o 10

Last we reset the watchdogs again using the following script in SUS>medm

     python resetFromWatchdogTrip.py MC1 MC2 MC3 BS PRM SRM ITMX ITMY ETMX ETMY
 

The callibration constants were updated for the oplev pitch and yaw. The values were changed as denoted in 17471 were:

     PITH: 175.7→ 155 cts/urad

     YAW: 193 → 241 cts/urad

To make these changes for the oplev callibration constants I went to ETMY - SELECTED OPLEV SERVO BOX

I then opened OLMATRIX and turned off PITCH and YAW servos in the ETMY SUSPENSION SCREEN such that the system does not attempt to actively make corrections while values are being changed. 

Then I adjusted the matrix to include our updated calibration constants and reinitiated the oplev ptich and yaw servo's

This updated the calibration constants for everything

The next change that was made was the addition of the calibration filters for position, pitch, yaw and side into the sitemap view for the suspension systems.

Adding calibration filters will allow us to callibrate the pos, pitch, yaw, and side to true values of urad and umeters (see 17459)

The final screen may be seen bellow (the updated area is outlined in red):

When each of the filter buttons is clicked, the following screen will now appear (circled in yellow is the calibration constant gain we will be calculating and entering into the system):

To create the edits to the controls screen we must complete the following process

We can edit the original screen - right click > evaluate > edit this screen

Then I adjusted the width of the overall screen, and moved the right half of the modules over to the right so I could fit in some filter buttons. I then Navigated to the c1ioo wfs master screen using the open feature to copy a pre existing filter module

I then adjusted the filter module and its contents to correspond to the features and autogenerated model files from RTCDS

There was some rearranging and adjusting needed to get these files in place first. The autogenerated files from the RTCDS can be found in dir = "/opt/rtcds/caltech/c1/medm/c1sus/"

They were autogenerated with names "C1SUS_BS_PITCAL.adl", "C1SUS_BS_POSCAL.adl", "C1SUS_BS_YAWCAL.adl","C1SUS_BS_SIDECAL.adl" 

We copied these files to dir = "/opt/rtcds/userapps/trunk/sus/c1/medm/templates/NEW_SUS_SCREENS/"

The file names were changed to "SUS_PITCAL.adl", "SUS_POSCAL.adl", "SUS_YAWCAL.adl", "SUS_SIDECAL.adl" 

The directory we placed them in is where the models for c1 sus can be found that are referenced by the sitemap suspension monitor screen

Each file was then opened in Vscode and a few changes were made such that the specific naming values referenced by the different screens of the sitemap and different optics, are replaced by the overarching values seen in each instance of the screens.

There are approximately 50 referenced file names of "C1:SUS-BS_PITCAL" etc. In each instance we made the following changes:

"-BS" was changed to "-$(OPTIC)"

"C1:" was changed to "$(IFO):"

The new strings should read "$(IFO):SUS-$(OPTIC)_PITCAL"

Once this change was made we can now right click on the filter module box, click on "Label/Name/Args" button

In the display file, we must add the path name for the calibration directory "/opt/rtcds/userapps/trunk/sus/c1/medm/templates/NEW_SUS_SCREENS/SUS_POSCAL.adl"

And for the arguments box we will enter OPTIC=$(OPTIC), IFO=$(IFO)

You can also copy and paste the directory names in the file boxes using right click copy from the file manager and paste into the box using a single click of the mouse scroller wheel

Lastly, the PV limits were changed for each number output right click value box > PV limits > Precision > Source changed to "Default" with a value of 1.

The shown value of the position, pitch, yaw, and side was then changed to show the output from the newly added filter. This is done also by right clicking the value box and adjusting the "Readback Channel".

Value changed from "$(IFO):SUS-$(OPTIC)_TO_COIL_1_#_INMON" to the outputs from the filters which are

       "$(IFO):SUS-$(OPTIC)_POSCAL_OUTMON" (for others changing POSCAL to the appropriate variable)

This is how to edit and add the Medm screens for single suspension optics into the sitemap IFO SUS screen

Lastly, Tomohiro and I worked on acquiring 6 data sets from DC stepping through adjustments in pitch and yaw for MC1, MC2 and MC3. These datasets will be fit quadratically and combined with more tests dine by AC driving the stepper motors tomorrow to find the calibration constants for the mirrors.

[Steve Koji]

We are in the process of adding a manual gate valve between TP1 (Osaka Maglev) and the other gate valves (I suppose V1 and VM2).
The work is still on going and we will continue to work on this tomorrow. Because this section is isolated from the main volume, this work does not hold off the possible rough pumping tomorrow morning.

The motivation of this work is as follows:
- Since TP2 failed, the main vacuum volume has been pumped down by TP1 and TP3. However TP3 is not capable to handle the large pressure difference at the early stage of the turbo pumping. This cause TP3 to have excessive heating or even thermal shutdown.
- The remedy is to put a gate valve between TPs and the main vacuum to limit the amount of gas flowing into the TPs. This indeed slows down the pumping speed of turbo, but this is not the dominant part of the pumping time.

Actual work:
- Comfirmed TP1 is isolated.
- Unscrewed the flange of TP1.
- Remove TP1. This required to lift up TP1 with some shim as the nuts interferes with the TP1 body. (Attachment1, 2, 3)
- Now remove 10inch flange adapter. (Attachment4)
-Attach 10"-8" adapter and 8" rotational sleeve. (Attachment5)

I had been working on the Xend table optical layout update. Since the two steering mirrors in the Xend green are too close to each, there is a very small Gouy Phase different between these two mirrors. It was suggested to place two lenses so that we can increase the Gouy Phase. I have been working with Nick on this problem, and we had found a solution by using a la mode. We had written an a la mode code that optimize the Gouy Phase and the Mode Matching at the same time. After trying different lenses, we found the following results: a mode matching of 0.9939 as it is show in the first attachment below, and we found a Gouy Phase different between the two mirrors of about 60 degrees. I took photos of the Xend Table. The first photo is the Xend table as we had it right now. In the second photo, I moved the 2nd lens, and I placed the two more lenses that we need it, with more or lenses the correct position where they will be placed. The three old lenses will be replaced by three lenses of different focal length as it can be seen in the first attachment below. The first lens and third lens will stay in the same position where the old first lens and old third lens are, and the second lens will be moved by about half of an inch. We might have one or two of the lenses that we need, but we will have to order the rest of the lenses that need. My plan is to verify the lenses that we already have. Then, I need to let Nick know with lenses we need to order. Hopefully, we will be able to update the table by the end of this week if everything turn out fine.

[Koji, JC]

Coil Drivers LO2, SR2, AS4, and AS1 have been updated a reinstalled into the system. 

LO2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100008

LO2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100530

SR2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100614

SR2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100615

AS1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100610

AS1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100611

AS4 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100612

AS4 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100613

[Rana]

For the upcoming NN test on the IMC, we need to add some more channels to the frames. Can someone please add the MC2 TRANS SUM, PIT, YAW at 256 Hz? and then make sure they're in frames.

and even though its not working correctly, it would be good if someone can turn the MC WFS on for a little while. I'd just like to get some data to test some code. If its easy to roughly close the loops, that would be helpful too.

[Anchal]

Currently, none of these channels are being written on frames. From simulink model, it seems the channels:

• C1:IOO-MC_TRANS_SUMFILT_OUT_DQ

• C1:IOO-MC_TRANS_PIT_OUT_DQ

• C1:IOO-MC_TRANS_YAW_OUT_DQ

are supposed to be DQed but are not present in the /opt/rtcds/caltech/c1/chans/daq/C1MCS.ini file. I tried simply adding these channels to the file and rerunning the daqd_ services but that caused 0x2000 error on c1mcs model. In my attempt, I did not know what chnnum to give for these channels so I omitted that and maybe that is the issue.

The only way I know to fix this is to make and install c1mcs model again which would bring these channels into C1MCS.ini file. But We'll have to run activateDQ.py if we do that which I am not totally sure if it is in running condition right now. @Christopher Wipf do you have any suggestions?

[Rana]

aren't they all filtered? If so, perhaps we can choose whatever is the equivalent naming at the LIGO sites rather than roll our own again.

@Tega Edo can we run activateDQ.py or will that break everything now?

[Tega]

@Rana Adhikari Looking into this now.

@Anchal Gupta The only problem I see with activateDQ.py is the use of the deprecated print function, i.e. print var instead of print(var). After fixing that, it runs OK and does not change the input INI files as they already have the required channel names. I have created a temporary folder, /opt/rtcds/caltech/c1/chans/daq/activateDQtests/, which is populated with copies of the original INI files, a modified version of activateDQ.py that does not overwrite the original input files, and a script file difftest.sh that compares the input and output files so we can test the functionality of activateDQ.py in isolation. Furthermore, looking through the code suggests that all is well. Can you look at what I have done to check that this is indeed the case? If so, your suggestion of rebuilding and installing the updated c1mcs model and running activateDQ.py afterward should do the trick.

I tested the code with:

which creates output files with an _ prefix, for example _C1MCS.ini is the output file for C1MCS.ini, then I ran

to compare all the input and corresponding output files.

Note that the channel names you are proposing would change after running activateDQ.py, i.e.

My question is this: why aren't we using the correct channel names in the first place so that we have less work to do later on when we finally decide to stop using this postbuild script?

[Anchal]

Yeah I found that these ERR channels are acquired and stored. I don't think we should do this either. Not sure what was the original motivation for this change. I tried commenting out this part of activateDQ.py and remaking and reinstalled c1mcs but it seems that activateDQ.py is called as postbuild script automatically on install and it uses some other copy of this file as my changes did not take affect and the DQ name change still happened.

[Tega]

Ah, we encountered the same puzzle as well. Chris found out that our models have `SCRIPT=activateDQ.py` embedded in the cds parameter block description, see attached image. We believe this is what triggers the postbuild script call to `activateDQ.py`. As for the file location, modern rtcds would have it in /opt/rtcds/caltech/c1/post_build, but I am not sure where ours is located. I did a quick search for this but could not find it in the usual place so I looked around for a bit and found this:

My guess is the last one /opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py.

Maybe we can ask @Yuta Michimura since he wrote this script?

Anyway, we could also try removing SCRIPT=activateDQ.py from the cds parameter block description to see if that stops the postbuild script call, but keep in mind that doing so would also stop the update of the OSEM and oplev channel names. This way we know what script is being used since we will have to run it after every install (this is a bad idea).

It looks like the guess was correct. Note that in the newer version of rtcds, we can use `rtcds env` instead of `env` to see what is going on.

[Suresh, Joe]

We added the following two new DAQ channels into the c1:GCV model.  The daq:analog input channels are on card ADC0 and correspond to channels 3 and 4 on the card.

c1:GCV-EXT_REF_OUT_DAQ   Sampling rate=2kHz  acquiring a 1Hz sine wave from the SRS Function Generator DS345.  This is using the Rb 10MHz signal as an external frequency reference.

c1:GCV-PLL_OUT_DAQ    Sa.rate=2kHz acquiring the demodulated signal from the PLL servo.

This work is connected to the study of VCO PLL loop noise at frequencies below 0.1Hz.    We are trying to measure phase noise in the VCO PLL servo at low frequencies as this noise would result in arm length fluctuations in the green-locking scheme.

I've added the other two temperature sensor modules on Y end (on 1Y4, IP: 192.168.113.241) and in the vertex on (1X2, IP: 192.168.113.242). I've updated the martian host table accordingly. From inside martian network, one can go to the browser and go to the IP address to see the temperature sensor status . These sensors can be set to trigger alarm and send emails/sms etc if temperature goes out of a defined range.

I feel something is off though. The vertex sensor shows temperature of ~28 degrees C, Xend says 20 degrees C and Yend says 26 degrees C. I believe these sensors might need calibration.

Remaining tasks are following:

• Modbus TCP solution:
  • If we get it right, this will be easiest solution.
  • We just need to add these sensors as streaming devices in some slow EPICS machine in there .cmd file and add the temperature sensing channels in a corresponding database file.
• Python workaround:
  • Might be faster but dirty.
  • We run a python script on megatron which requests temperature values every second or so from the IP addresses and write them on a soft EPICs channel.
  • We still would need to create a soft EPICs channel fro this and add it to framebuilder data acquisition list.
  • Even shorted workaround for near future could be to just write temperature every 30 min to a log file in some location.

[anchal, paco]

We made a script under scripts/PEM/temp_logger.py and ran it on megatron. The script uses the requests package to query the latest sensor data from the three sensors every 10 minutes as a json file and outputs accordingly. This is not a permanent solution.

I finally got the modbus part working on chiara, so we can now view the temperature data on any machine on the martian network, see Attachment 1. 

I also updated the entries on /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini, as suggested by Koji, to include the SensorGatway temperature channels, but I still don't see their EPICs channels on https://ldvw.ligo.caltech.edu/ldvw/view. This means the channels are not available via nds so I think the temperature data is not being to be written to frame files on framebuilder but I am not sure what this entails, since I assumed C0EDCU.ini is the framebuilder daq channel list.

When the EPICs channels are available via nds, we should be able to display the temperature data on the summary pages.

[Tega, Paco, Anchal]

We attempted to reboot fb1 daqd today to get the new temperature sensor channels recording. However, the FE models got stuck, apparantely due to reasons explaine din 40m/16325. Jamie cleared the /var/logs in fb1 so that FE can reboot. We were able to reboot the FE machines after this work successfully and get the models running too. During the day, the FE machines were shut down manually and brought back on manually, a couple of times on the c1iscex machine. Only change in fb1 is in the /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini where the new channels were added, and some hacking was done by Jamie in gpstime module (See 40m/16327).

I want to monitor the PMC TRANS and REFL levels on the PSL table - previously there were some cables going to the oscilloscope on the shelf but someone had removed these. I re-installed them just now. While there, I disconnected the drive to the AOM - there must've been some DC signal going to it because when I removed the cable, the PMC and IMC transmission were recovered to their nominal levels.

we hung two new WALL cable racks. One is on the pillar next to the Sp table, the other is next to the PSL computer rack.

To do that we had to drill holes in the wall since the simple screws weren't strong enough to keep them up.

One of the racks, the yellow, is dedicated to 4-pin lemos and other thick cables.

 awesome - I have ordered 5 blue racks so that we can hang power cables. The fat BLUE ones are for fat cables and the orange ones for the coax cables.

Jenne and I renamed the mic channels Den created (elog 6664) to MIC_1, MIC_2, etc from the original accelerometer names to keep things clear. We then added 6 new channels (22-27) for the accelerometers, named ACC_MC1_X, Y, Z, ACC_MC2_X, Y, Z, etc. (See the screenshot below). We also added a DAQ channel block and listed out the IN1 channel of all the sensors. We compiled and started the model, and checked that all the channels were there in DataViewer.

[ian, anchal, paco]

We hooked up the infrasensing unit to power and changed its default IP address from 192.168.11.160 (factory default) to 192.168.113.240 in the martian network. The sensor is online with user controls and the usual password for most workstations in that IP address.

To simulate digitization noise, the easiest way I found was to use the MathFunction block, found in the CDS_PARTS model, under simLinkParts. 

The MathFunction block supports square of input value, square root of input value, reciprocal of input value, and modulo of two input values.

The last is useful because it casts the input values as integers before taking the modulo.By placing this block after the saturation block (set to +/- 32768), adding 32768.5, choosing the 2nd input to be larger than 2 * 32768 (100,000 in this case), and then subtracting 32768, we wind up with a rounding function. 

The above method has been applied to the c1spy model in the CI and SO out sub-blocks.

I have added some control logic and appropriate output DAC channels for the input tip-tilts (TT1 and TT2) to the c1ass model.

The plan is for all the tip-tilt drive electronics to live in a Eurocrate in 1Y2.  They will then interface with a DAC in c1lsc.

c1ass runs on the c1lsc front-end machine, and therefore seemed like an appropriate place for the control logic to go.

I added and interface to DAC0, and a top_named IOO block, to c1ass:

The IOO block includes two TT_CONTROL library parts, one for each of TT1 and TT2:

This is just a start so that I can start testing the DAC output.

I have not recompiled c1ass yet.  I will do that tomorrow.

I modified the C1ADCU_PEM.ini file in /cvs/cds/caltech/chans/daq/ (after making a backup), and added a temporary channel called C1:PEM-TEMP_9, the 9 corresponding to the labeled 9 channel on the front of the BNC breakout in the 1Y7 rack.  The chnnum it was set to is 15008 (it was commented out and called C1:PEM-PETER_FE).  I also set the data rate to 2048.

I then did telnet fb40m 8087, and shutdown, and also hit the blue reconfig button on the DAQ status screen for the C0DCU1 machine.  The framebuilder came back up.  I confirmed the temporary channel, as well as the Guralp channels were still working from C0DCU1.

We have strung a cable in the cable trays from the SP table to the 1Y7 rack, which has been labeled as "Phasecam PD".  This will be used to record the output of an additional photodiode.

I added an alias to the sitemap MEDM screen in /cvs/cds/caltech/target/cshrc.40m

Now you can enjoy launching sitemap from a terminal.

alias sitemap 'medm -x /cvs/cds/rtcds/caltech/c1/medm/sitemap.adl'