Seems to good to be true. Maybe you're over fitting? Please put all the traces on one plot and let us know how you do the parameter setting. You should use half the data for training the filter and the second half for doing the subtraction.

I didn't have a separate training set and data set, so I think that's why the graphs came out looking too good. The units on the graphs are also incorrect, I was interpreting PSD as ASD. I haven't been able to get my Wiener filtering code working well- I get unreasonable subtractions like the noise being larger than the unfiltered signal, so Eric showed me this frequency-dependent calculation described here: https://dcc.ligo.org/LIGO-P990002

This seems to be working well so far:

freq1.pdf

freq2.pdf

freq3.pdf

Here's all the plots on one figure:

frequency_dependent.pdf

Let me know if this looks believable.

I'm working on locking the Michelson now in order to put an excitation on one of the input test masses and measure the resulting error signal at the anti-symmetric port. I aligned the beams from ITMX and ITMY by looking at the AS camera with the video screens, but the fringes were not destructively interfering. Jenne advised that I look at the gain on the MICH servo filter modules in the LSC screen. We flipped the sign on the gain (it was 0.120 and it is now -0.120) and the fringes destructively interfered as desired after this change.

For purposes of documentation, I locked the YARM earlier in the morning before moving on to the Michelson. The purpose of this was to put another excitation on C1:SUS-ETMY_LSC_EXC and then measure the error signal on C1:LSC-POY11_I_ERR.

Today I worked on locking the Michelson. Here's what I did:

1. Open Data Viewer and Restore Settings /users/Templates/JenneLockingDataviewer/MICH.xml. This opens the C1:LSC-ASDC_OUT and C1:LSC-AS55_Q_ERR plots.

2. Check the LSC screen to verify that the path between the Servo Filter Modules and the SUS Ctrls are outlined in green. If not turn on the OUT button within the Filter Servo Modules, enable LSC mode, and turn on the SUS Ctrls for the BS.

3. Misalign all optics other than BS and one of ITMX and ITMY. The ITMY was already well-aligned from my work on locking the YARM, so I actually chose to misalign ITMY at first.

4. Restore BS and ITMX. Use the AS camera on the video screen as your guide when aligning ITMX.

5. Adjust pitch and yaw of ITMX until a bright, circular spot appears near the middle of the AS camera.

6. Now restore ITMY and adjust pitch and yaw until a second circular spot appears on the AS camera.

7. Adjust both ITMX and ITMY until both bright spots occupy the same location. If the spots remain bright when they are in the same location you are locking onto a bright fringe actually, and need to flip the sign of the gain on the MICH servo filter modules. I had to do this today in fact, as discussed in ELOG 7145.

8. If the sign is correct, the two beams should interfere destructively and the formerly bright spots will form a comparatively dark spot. The shape of the spot will likely be two bright lobes separated by a dark middle.

9. C1:LSC-ASDC_OUT should be a roughly flat signal, and the goal now is to minimize the magnitude of this signal. The smaller this signal, the darker the AS camera should look. Decent target values for C1:LSC-ASDC_OUT are around 0.10 to 0.05.

Once I did this, I made measurements by exciting C1:SUS-ITMY_LSC_EXC and measuring with C1:LSC-AS55_Q_ERR. I ran a logarithmic swept sine response from 1 to 1000 Hz again, with an envelope amplitude dependence. Again I looked at the measured transfer function and coherence. I was able to get good coherence, but it was somewhat erratic in that it dipped low at high frequency multiple times.

[Koji / Kiwamu]

The Michelson was locked with the new LSC realtime code.

(what we did)

 --  Fine alignment of the Michelson, including PZTs, BS and ITMY.

  Since the X arm has been nicely aligned we intentionally avoided touching ITMX. The IR beam now is hitting the center of both end mirrors.

  At the end we lost X arm's resonance for IR. This probably means the PZTs need more careful alignments.

-- Signal acquisition

 We replaced the RFPD (AS55) that Aidan and Jamie nicely installed by POY11 because we haven't yet  installed a 55MHz RF source.

The maximum DC voltage from the PD went to about 50 mV after aligning steering mirrors on the AP table.

The RF signal from the PD is transferred by a heliax cable which has been labeled 'REFL33'.

Then the RF signal is demodulated at a demodulation board 'AS11', which is one of the demodulation boards that Suresh recently modified.

Although we haven't fully characterized the demod board the I and Q signal looked healthy.

Finally the demod signals go to ADC_0_3 and ADC_0_4 which are the third and fourth channel.

They finally show up in REFL33 path in the digital world.

-- Control

 With the new LSC code we fedback the signal to BS. We put anti-whitening filters in the I and Q input filter banks.

We found that dataviewer didn't show correct channels, for example C1LSC_NREFL33I showed just ADC noise and C1LSC_NREFL33Q showed NREFL_33I.

Due to this fact we gave up adjusting the digital phase rotation and decided to use only the I-phase signal.

Applying a 1000:10 filter gave us a moderate lock of the Michelson. The gain was -100 in C1LSC_MICH_GAIN and this gave us the UGF of about 300 Hz.

 Note that during the locking both ETMs were intentionally misaligned in order not to have Fabry-Perot fringes.

 The ELOG was frozen, with this in the .log file:   

GET /40m/?id=1279&select=1&rsort=Type HTTP/1.1

Cache-Control: no-cache

Connection: Keep-Alive

Pragma: no-cache

Accept: */*

Accept-Encoding: gzip, deflate

From: bingbot(at)microsoft.com

Host: nodus.ligo.caltech.edu

User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

  (hopefully there's a way to hide from the Bing Bot like we did from the Google bot)

Yesterday elog was excruciatingly slow, and bingbot was the culprit. It was slurping down elog entries and attachments so fast that it brought nodus to its knees. So I created a robots.txt file disallowing all bots, and placed it in the elog's scripts directory (which gets served at the top level). Today the log feels a little snappier -- there's now much less bot traffic to compete with when using it.

We might be able to let selected bots back in with a crawl rate limit, if anyone misses searching the elog on bing.

Oh, this is cool! Thanks!
I could not figure out how to place robot.txt as it was not so obvious how elogd handles the files in the "logfile" directory.

I added an EM172 to my soldered circuit and it seems to be working so far. I have taken a spectra using the EM172 in ambient noise in the control room as well as in white noise from Audacity. My computer's speakers are not very good so the white noise results aren't great but this was mainly to confirm that the microphone is actually working.

white_v_ambient.pdf

[Raji, Ayaka]

Thanks to Den, power supplies for microphone circuit are changed.
So I measured the microphone noise again by the same way as I did last time.

  solid lines: acoustic noise
 dashed lines: un-coherent noise
black line: circuit noise (microphone unconnected)

The circuit noise improves so much, but many line noises appeared.
Where do these lines (40, 80, 200 Hz...) come from?
These does not change if we changed the microphones...

Anyway, I have to change the circuit (because of the low-pass filter). I can check if the circuit I will remake will give some effects on these lines.

I do not think that 1U rack power supply influenced on the preamp noise level as there is a 12 V regulator inside. Lines that you see might be just acoustic noise produced by cpu fans. Usually, they rotate at ~2500-3000 rpm => frequency is ~40-50 Hz + harmonics. Microphones should be in an isolation box to minimize noise coming from the rack. This test was already done before and described here. 

I think we need to build a new box for many channels (32, for example, to match adc). The question is how many microphones do we need to locate around one stack to subtract acoustic noise. Once we know this number, we group microphones, use 1 cable with many twisted pairs for a group and suspend them in an organized way.

 I do not think they are acoustic sounds. If so, there should be coherence between three microphones because I placed three at the same place, tied together. However, there are no coherence at lines between them.

I have made my transfer function model and posted it to the suspension wiki. Here is the link to my model!

Bode Plot Model

Please let me know if there need to be any adjustments, but I have posted the bode plots, a model image, and an explanation of why I think it's right! ^ ___^ V

I am currently working on the photo sensor circuit for the displacement detector. So far, I have gotten the infared LED to light up! ^ ___^ V

I am now trying to get a plot of forward voltage versus current for the LED. HOPEFULLY it will match the curve provided in the LED datasheet.

I'm using the bread board circuit box and when I'm not working at the bench, I have signs posted. PLEASE DO NOT REMOVE THE CONNECTIONS! It is

fine to move the bread board circuit box, but please do not disturb the connections > ____<

Here is a photo of the workspace

The construction people next door seem to be getting pretty excited about pounding things lately.  At my desk the floor was shaking like a mini-earthquake, and all of the accelerometers were pretty much railed. Clara has the Guralp box out right now, so the Guralp is unplugged, but the Ranger didn't seem to be railed.

This either (a) is part of the reason the MC is being wonky lately, or (b) has nothing whatsoever to do with it.  The MC watchdogs haven't been tripping all the time, so maybe this isn't a primary cause of the wonky-ness.

In looking at a many-days/months trend to see how far back this has been going, it looks like the accelerometers are hitting their rails pretty much all day every day.  This may be significantly hindering Clara's Wiener filtering work.  I think the gain on the accelerometer's controler panel is already set to 1, but if it's set to 10, we may want to reduce that.  Alternatively, we may want to put in attenuators just as the signal is entering the PEM ADCU, to help reduce the amount of rail-hitting that's going on. I don't remember this from a couple of months ago, so this may be a problem that will go away once the construction / landscaping is done next door.

As a part of the network analyzer test in the previous entry, the transfer functions of Mini-Circuits filters we have at the 40m were measured.

<<List of the filters>>

- LPF (SMA): SLP1.9, SLP5, SLP21.4, SLP30, SLP50, SLP100, SLP150, SLP750
- LPF (BNC): BLP1.9, BLP2_5, BLP5, BLP30
- BPF (SMA): SBP10.7, SBP21.4, SBP70
- HPF (SMA): SHP25, SHP100, SHP150, SHP200, SHP500

 I made a minor modification to install some output filters in the new global damping GLOBAL box in c1sus.mdl. These will be needed for tuning the suspension drives to compensate for mismatches in the pendulums.

I recompiled and installed the model, but did not start it. Basically same as Jamie left it in 8159. Interestingly, I did not see the new POSOUT that was put in before the SUSPOS DOF filter. I made sure to reopen the .mdl file fresh before making more mods, but for some reason I do not see that update...

I made several small, nit-picky changes to the summary pages.

Motivation:

I'm still working on getting used to editing the summary pages. I also wanted to change some of the easy-to-alter cosmetics of the pages.

What I did:

I changed axis ranges, axis labels, and typos throughout the summary pages. Read below for an excrutiating list of the minor details of my alterations, if you wish:

• Changed axes on LSC control signals plots on the Summary tab (but will probably change these back to their original state)
• Moved an OpLev plot from the Sandbox tab to "Eve" tab
• Increased the y axis range on IOO MC2 Trans QPD and IMC REFLY RFPD DC plots (which may change when I better incorporate triggers into these plots)
• Fixed title on IOO Whitened Spectrogram and Rayleigh Spectrogram
• Fixed degree sign on Weather: Temperature and PSL Table Temperature
• Fixed percent sign on Weather: Humidity
•  

Results:

So far, everything looks good. I'll continue to make more changes later this week and hope to soon get on to more substatial changes.

There was some uncertainty as to which channels were being input into the Adaptive Filtering screen, so I checked it out to confirm.  As expected, the rows on the ASS_TOP_PEM screen directly correspond to the BNC inputs on the PEM_ADCU board in the 1Y6 (I think it's 6...) rack.  So C1:ASS-TOP_PEM_1_INMON corresponds to the first BNC (#1) on the ADCU, etc. 

After checking this out, I put text tags next to all the inputs on the ASS_TOP_PEM screen for all of the seismometers (which had not been there previously).  Now it's nice and easy to select which witness channels you want to use for the adaptation.

While working on c1omc, I created a .cshrc file in the controls home directory, and had it source the cshrc.40m file so that useful shortcuts like "target" and "c" work, among other things.  I also fixed the resolv.conf file so that it correctly uses linux1 as its name server (speeding up ssh login times).

A novice was learning at the feet of Master Daqd. At the end of the lesson he looked through his notes and said, “Master, I have a few questions. May I ask them?”

Master Daqd nodded.

"Do we record minute trends of our data?"

"Yes, we record raw minute trends in /frames/trend/minute_raw"

"I see. Do we back up minute trends?"

"Yes, we back up all frames present in /frames/trend/minute"

"Wait, this means we are not recording our current trends! What is the reason for the existence of seperate minute and minute_raw trends?

“The knowledge you seek can be answered only by the gods.”

"Can we resume recording the minute trends?"

Master Daqd nodded, turned, and threw himself off the railing, falling to his death on the rocks below.

Upon seeing this, the novice was enlightened. He proceeded to investigate how to convert raw minute trends to minute trends so that historical records could be preserved, and precisely when Master Daqd started throwing himself off the mountain when asked to record minute trends.

Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

My elog negligence punchcard is getting pretty full... It's pretty much for the same reason as using Debian for optimus; much of the workstation software is getting packaged for Debian, which could offload our need for setting things up in a custom 40m way. Hacking the debian-focused software.ligo.org repos into Ubuntu has caused me headaches in the past. Allegra wasn't being used often, so I figured it was a good test bed for trying things out.

The dataviewer issue was dataviewer's inability to pull the `fb` out of `fb:8088` in the NDSSERVER env variable. I made a quick fix for it in the dataviewer launching script, but there is probably a better way to do it.

and the song remains the same...

the version of SVN on these workstations is ahead of the one on the other workstations so now we can't do 'svn up' on any of the Ubuntu12 machines. One allegra and optimus I get this error:

controls@allegra|GWsummaries> svn up
Updating '.':
svn: E180001: Unable to connect to a repository at URL 'file:///cvs/cds/caltech/svn/trunk/GWsummaries'
svn: E180001: Unable to open an ra_local session to URL
svn: E180001: Unable to open repository 'file:///cvs/cds/caltech/svn/trunk/GWsummaries'

I'm not sure if its possible to downgrade our chans repo back to the old one, but I highly recommend that no one do 'svn upgrade' in any of our repos until we remove all of the Debian installs in the 40m lab or hire a full-time sysadmin.

[Joe, Alex]

Steve pointed out to me today he couldn't get trends for his PEM slow channels like C1:PEM-count_full. 

I experimented a bit and found for long time requests (over 20 days), it would produce minute trends up to the current time, but only if they started far enough back.  So the data was being written, but something was causing a problem for dataviewer/NDS to find it.

On further investigation it looks to be some incorrect time stamps at several points in the last few months are causing the problems.  Basically when Alex and I made mistakes in the GPS time stamp settings for the frame builder (daqd) code, the wrong time got written for hours to the raw minute trend data files.

So Alex is going to be running a script to go through the roughly 180 gigabytes of affected trend data to write new files with the correct time stamps.  Once it done, we'll move the files over.  We'll probably lose a few hours worth of recent trend data, depending on how quickly the scripts run, but after which minute trends should work as they are supposed to.

Today we met and we finally come up with a lot of cool, clever, brilliant, outstanding ideas to organize the lab.

You can find them on the Wiki page created for the occasion.

http://lhocds.ligo-wa.caltech.edu:8000/40m/40m_Internals/Lab_Organization

Enjoy!

Where are we going to put the tiki bar? The ice cream machine? I am disappointed in the details that appear to have been glossed over..

{Yehonathan, Gavin}

Yesterday we tried to shake ITMX with a function generator in order to observe the 28.8kHz drum mode.

We laid a long BNC cable that runs from the YARM to the XARM. This cable either needs to be collected back to the BNC big plastic cable box under the IMC or be labeled so that it could be found easily in the future.

First, we tried to shake it at a lower frequency (100's of Hz) where the shaking should be easily observed in the POSX channel. We try driving the POS channel on the ITMX servo but nothing happens. Most likely it is disconnected.

While setting up for shaking the individual OSEM channels 4 CDSs crashed (c1lsc, c1ass, c1oaf, c1cal).

 I studied the eigenfrequencies of a mirror support using COMSOL.

I have given Den 4 G&H R>99.99% mirrors to be installed on the 4 active tip tilts.  He's in there working on things (incl. installing and balancing the pitch of the mirrors) right now.  He'll elog his work later.

 I've installed the mirrors on 4 tip-tilts. I was able to align 3 of them in pitch, the last one has a screw with damaged thread, I'll continue with it tomorrow.

Alignment accuracy in pitch is ~0.1 mrad. Mirrors oscillate a lot probably due to air flow coming from the side wall.

[Jenne, Kevin, Kiwamu]

We moved some optics in preparation for measuring the MC mode after the first MMT curved optic, RoC -5m. 

Kevin and I found the box of DLC (sp?) mounts with the 2" Y1-45P optics in the clean tupperware boxes.  We removed one of the Y1-45P's, and replaced it with the MMT1 -5m optic, which was baked several weeks ago.  We left the Y1-45P on the cleanroom table next to where the MMT optics are.  We placed this MMT mirror in the place it belongs, according to Koji's table layout of the BS table. 

We drag wiped one of the other Y1-45P's that was in the box since it was dirty, and then placed the optic on the IOO table, on the edge closest to the BS table, with the HR side facing the BS table, so that the beam reflected off the curved mirror is reflected back in the direction of the BS table.  This was aligned so the beam hits the same PZT mirror we were using last time, to get the beam out of the BS chamber door.  We left a razor dump on the edge of the BS table, by the door, which will need to be removed before actual measurements can take place. 

Rana pointed out that the anticipated mode calculation should be modified to include the index of refraction of the crystals in the Faraday, and the polarizers in the Faraday.  This may affect where we should put MMT1, and so this should be completed before round 2 measurements are taken, so that we can move MMT1.

Also, the optics are in place now, and the beam is going out the BS chamber door, but we have not yet measured distances (design distances quoted on the MMT wiki page), and confirmed that everything is in the right place.  So there is a bit more work required before beginning to measure round 2.

Note:  While I was poking around on the BS table, I had to move several optics so that we could fit MMT1 in the correct place.  When preparing to move these optics, I found 2 or 3 that were totally unclamped. This seems really bad, especially for tall skinny things which can fall over if we have an earthquake.  Even if something is in place temporarily, please clamp it down.

That's true. But I thought that you measured the mode after those optics and the effect of them is already included.

So:

• We need to model the transmissive optics in order to understand the measured mode which is different from the MC mode slightly.
• We just can calculate the modes based on the measurement in order to figure out the realistic positions of the MMT1 and MMT2.

 Yes, the measured mode takes all of this into account.  But in Kevin's plot, where he compares 'measured' to 'expected', the expected doesn't take the Faraday optics into account.  So I should recalculate things to check how far off our measurement was from what we should expect, if I take the Faraday into account.  But for moving forward with things, I can just use the mode that we measured, to adjust (if necessary) the positions of MMT1 and MMT2.  All of the other transmissive optics (that I'm aware of) have already been included, such as the PRM and the BS.  This included already the air-glass curved interface on the PRM, etc.

The angle of incidence of light is for some mirrors on the YARM end table different from 45° even though the mirrors are coated for 45°.

The mirrors below are useful if there are plans to replace these mirrors by properly coated ones.

* This is the new mirror as decribed on http://nodus.ligo.caltech.edu:8080/40m/5623

Yesterday, we were seeing anomalously high low frequency RIN in the y-arm (rms of 4% or so). I swung by the lab briefly to check this out. Turns out, despite TRY of 1.0, there was reasonable misalignment. ASS with the excitation lowered by a factor of two, and overall gain at 0.5 or so aligned things to TRY=1.2, and the RIN is back down to ~0.5% I reset the Thorlabs FM to make the power = 1.0

I then went to center the transmitted beam on the transmon QPD. Looking at the quadrant counts as I moved the beam around, things looked odd, and I poked around a little... 

I strongly suspect that we have significantly mismatched gains for the different quadrants on the ETMY QPD. 

Reasoning: With the y-arm POY locked, I used a lens to focus down the TRY beam, to illuminate the quadrants individually. Quadrants 2 and 3 would go up to 3 counts, while 1 and 4 would go up to 0.3 and 0.6, respectively. (These counts are in some arbitrary units that were set by setting the sum to 1.0 when pitch and yaw claimed to be centered, but mismatched gains makes that meaningless.)

I haven't looked more deeply into where the mismatch is occurring. The four individual whitening gain sliders did affect the signals, so the sliders don't seem sticky, however I didn't check the actual change in gains. Will the latest round of whitening board modifications help this?

Hopefully, once this is resolved, the DC transmission signals will be much more reliable when locking...

I saw FB1 was pushed into the rack (Attachment 1). Thank you very much for the work. But I did not see an elog about it.

Here is a good example of why timely elogs are so important.

• I saw that the seismometer signals were lost 3 hours ago, looking at the StripTool display on the control room wall. I wondered if there was a CDS crash or anything (but there wasn't).
• I went into the lab and found the FB was pushed in. I checked the rear side of the rack and found the ADC SCSI cable was half unplugged. (Attachment 2)
  Pushing the plug back into the connector made the PEM signals back into operation (Attachment 3)
• Even if I asked whether there was a problem with PEM, people would say, "We did nothing." But, this kind of unaware cause of another issue just by the presense of you in the lab is very common.
• If I could see an elog about the FB push written 3 hours ago, I could easily relate these two events, which were not so apparent to be associated.

Write your work of the day before you leave. You will not elog it tomorrow or even in the same evening at home.

Summary: Cannot find beatnotes between the arms and PSL.

I wanted to measure the ALS out of loop noise before putting stuff on the PSL table for frequency offset locking.

But I was not able to find the beat notes between the arms and PSL green. All I could find while scanning through the end laser temperatures is the beatnote between the X and Y green.

EricQ says that he spent some time yesterday and could not find the beatnotes as well.

Debugging and still could not find:

1. Checked the FSS slow actuator. This was close to zero ~0.003

2. Checked the green alignment on the PSL table. Everything seems fine.

3. Checked the actual PSL laser temperature. It was 31.28deg and not very far from when it was last set at 31.33deg elog.

4. Also checked the end laser temperatures. Both the lasers are ~40deg (where I could see the beatnote between the arms). Based on the plot here and  here , we are very much in the regime where there should be a beatnote between the PSL and the arms.

I checked Solidworks models to see the mass/moment of inertia for the BHD SOS masses.
The mass/MoI calculation includes 2" glass optic. MoIs were given at the center of mass.

== 0.25 inch optic / original sleeve ==

- Mass = 185 grams
- Moment of Inertia (grams mm^2)
Lxx = 9.84e4 (Pitch)
Lyy = 9.14e4 (Yaw)
Lzz = 1.74e5 (Roll)

== 0.5 inch optic / thick optic sleeve ==

- Mass = 210 grams
- Moment of Inertia (grams mm^2)
Lxx = 9.37e4 (Pitch)
Lyy = 9.52e4 (Yaw)
Lzz = 1.73e5 (Roll)

== 0.75 inch optic / thick optic sleeve ==

- Mass = 235 grams
- Moment of Inertia (grams mm^2)
Lxx = 9.85e4 (Pitch)
Lyy = 1.00e5 (Yaw)
Lzz = 1.80e5 (Roll)

== Ref: 3" x 1" glass optic ==

- Mass = 255 grams
- Moment of Inertia (grams mm^2)
Lxx = 1.06e5 (Pitch)
Lyy = 1.06e5 (Yaw)
Lzz = 1.85e5 (Roll)

I could not find the model for the 3/8" thick optic. The original metal sleeve was designed for 1/4" optic. It is probably possible to put the 3/8" optic into it (with significant misalignment).
It seems that PR2 was installed on Jan 27, 2022. However, both the photograph record and elogs were not detailed enough to identify which metal sleeve was used for PR2.
We need to look into the viewport to identify it.

To fit the 3/8" optic into the thick optic (3/4") sleeve, 3/16" thick ring spacers were required. I have no record of making such sleeves.

The new PR2 optic has a thickness of 1/2". The Solidworks model has the version with 1/2" optic, which was fit into the thick optic sleeve with two 1/8" spacers.
We made a total of 4 thick sleeves. Even if the current PR2 has the original metal sleeve, we are supposed to have one more of the thick sleeves. We still have to find/manufacture Qty 2 of the 1/8" spacers.

From the ITMX window, I confirmed that PR2 is using the original metal sleeve and the optic is 3/8" thick. (See Attachment 1)

Based on this, I made a SW model to check the mass and the IoM.

== 0.375 inch optic / original sleeve ==

- Mass = 201 grams
- Moment of Inertia (grams mm^2)
Lxx = 1.01e5 (Pitch)
Lyy = 9.41e4 (Yaw)
Lzz = 1.79e5 (Roll)

Thanks to new info from Johannes, I was able to finish setting up the modbus IOC on c1susaux2. It turns out the 17 Acromags draw ~1.9 A, which is way more than I had expected. Hence the reason I had suspected a short. Adding a second DC supply in parallel solves the problem. There is no issue with the wiring.

With the Acromags powered on, I carried out the following:

• Confirmed c1susaux2 can communicate with each Acromag at its assigned IP address
• Modified the EPICS .cmd file to point to the local modbus installation (not the remote executable on /cvs/cds)
• Debugged several IOC initialization errors. All were caused by minor typos in the database files.
• Scripted the modbus IOC to launch as a systemd service (will add implementation details to the documentation page)

The modbusIOC is now running as a peristent system service, which is automatically launched on boot and relaunched after a crash. I'm able to access a random selection of channels using caget.

What's left now is to finish the Acromag-to-feedthrough wiring, then test/calibrate each channel.

 E-log entry for Friday - will attach more plots to this entry on wednesday after i am back   to the 40.

Status	MC_Trans	MC_REF
New Control ON
New Control OFF
Old Control ON

The WFS and QPD servos were working. That was great.
Everything was fine except for the time series plots.

I could not get what story you are telling with the time series.
(e.g. your's are good or bad or anything)

 Well, the data is kind of not enough to be analysed in time domain,

But by far from what I analyse, I think that the new control is not worse than the old one.

I donot also find any better results, except for this one being theoritically stronger.

When Rob and I were getting started on locking for the evening, Mode Cleaner lost lock a few times, but every time it lost lock, it took forever to reaquire, and was pretty insistent on locking in the TEM10 mode.  I proposed that the alignment might be sketchy.  I've been fiddling with the MC alignment sliders for the last hour and a half or so, but I think I'm not 100% in tune with the 3 mirror parameter space.  The mode cleaner now locks, but I'm not in love with its' alignment.  The WFS are definitely catywhompus.  Before doing hardware things like recentering the WFS, I'm going to wait until tomorrow to consult with an alignment expert.

In case this is helpful for tomorrow, before I touched any of the sliders:

Optic, Pitch, Yaw

MC1, 3.1459, -0.7200

MC3, -0.8168, -3.0700

MC2, 3.6360, -1.0576

Now that mode cleaner locks, although not in a great alignment:

MC1, 3.1089, -0.7320

MC3, -0.7508, -3.0770

MC2, 3.6610, -1.0786

If I knew how to kill my script to unlock the mode cleaner, I would.  But I sourced it, and Rob didn't know earlier this evening how to kill something which is started with 'source' since it doesn't seem to get a process number like when you './'  to run a script. So the Mode Cleaner will probably be unlocked in the morning, and it may be persnickity to get it relocked, especially if the tree people are doing tree things with giant trucks again in the morning.

When all things fail (netgpibdata.py is giving me weird data.  When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function.  I don't really know what's up.  I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps.  I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.

* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.

Note to self:  post the data of the TFs in the elog along with the plots, for posterity.

These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.

One with the box, one without the box, and one of just the box for good measure.

 Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase.  Brilliant.   Using that nugget of information, here are the TFs that I measured earlier:

The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.