I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get 40m data from outside and inside of the 40m.

YES ! We got the green light coming out from the OMC chamber to the PSL table !

 (Koji, Kiwamu, Yuta)

Background

As a result of the work in the chambers, the green beam reached the OMC chamber yesterday.
Today's mission was to let the green beam coming out from the chambers to the PSL table.

What we did:
1. Installed the last three steering mirrors.
  The mirrors were 532 HR mirror with AR and 1deg wedge (CVI Y2-LW-1-2050-UV-45-P/AR).
  Two of them are placed to the MC chamber. Another one was to the OMC chamber

During putting the mirrors to the MC chamber, we found that a cable tower was sitting on a position exactly where we wanted to put one of the mirrors.

So we moved the tower to the very south west corner. 

2. Installed a periscope to the MC chamber

The function of this periscope is to lower the beam height of the green light which is risen up by another periscope in the BS chamber.

We aligned it to the green beam, so that the beam hits the center of the mirrors on the periscope.  

3. Aligned the optics

We aligned the green mirrors so that we can let the green beam go out from the chamber.

Actually the inside of the OMC chamber didn't look like the same as that of our optical layout.

For example there is unknown base plate, which apparently disturbs the location of our last steering mirror.

Therefore we had to change the designed position of the steering mirror.

Now the mirror is sitting near the designed position (~ 1/2 inch off), but it's fine because it doesn't clip any 1064 beam.

 
Result:

The green beam is now hitting the north wall of the PSL table.

Notes:

The green beam looks having some fringes, it may be caused by a multiple reflection from a TT when the green beam goes through it. We are going to check it. 

Next work:

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

Today I checked the CCD cables which is connected to the VIDEOMUX.

17 cables are type of RG59, 8 cables are type of RG58. I have not figured out the type of other cables(23 cables) yet.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

To check the impedance of each CCD cable, I went to the VIDEOMUX and looked for the label on the cable's surface.

Type of RG59 is designated to the cable of impedance 75ohm. I wrote down each cable's input or output channel number with observation(whether it is of type RG59 or not).

The result of observation is as follows.

For 23 cables that I have not figured out their type, cables are too entangled so it is limited to look for the label along each cable.

I will try to figure out more tomorrow. Any suggestion would be really appreciated.

Kiwamu, Koji, Yutah, Rana, Jan and Steve

We removed the west access connector this afternoon.

We moved the filters for the mode cleaner optics over from the C1SUS.txt file in /opt/rtcds/caltech/c1/chans/ to the C1MCS.txt file, and placed SUS_ on the front of all the filter names.  This has let us load he filters for the mode cleaner optics.

At the moment, we cannot seem to get testpoints for the optics (i.e. dtt is not working, even the specially installed ones on rosalba). I've asked Yuta to enter in the correct matrix elements and turn the correct filters on, then save with a burt backup.

You can find the sitemap medm screen in

/opt/rtcds/caltech/c1/medm/master

The settings for the screens were last saved by burt in the original system on Sept 29, 2010 at 11:07.  So go to the

/cvs/cds/caltech/burt/autoburt/snapshots/2010/Sep/29/11:07

directory.  You can grep for the channels in the files in this directory.

You can also then use the autoBurt.req file in the /opt/rtcds/caltech/c1/target/sysname/sysnameepics (c1sus/c1susepics) to backup the settings entered.  Save to the /opt/rtcds/caltech/c1/target/snapshots directory for now.

Apparently when updating front end codes from rtlinux to the patched Gentoo, certain files don't get deleted when running make clean, such as the sysfe.rtl files in the advLigoRTS/src/fe/sys directories.  This fouls the start up scripts by making it think it should be configured for rtlinux rather than the Gentoo kernel module.

 I installed the package x264-devel on allegra.martian.  This package provides headers and libraries for the popular h264 video codec.  I am going to use this in the GStreamer streaming media server on Allegra.

Fb is now once again actually recording trends.

A section of the daqdrc file (located in /opt/rtcds/caltech/c1/target/fb/ directory) had been commented out by Alex and never uncommented.  This section included the commands which actually make the fb record trends.

The section now reads as:

# comment out this block to stop saving data

#
start frame-saver;
sync frame-saver;
start trender;
start trend-frame-saver;
sync trend-frame-saver;
start minute-trend-frame-saver;
sync minute-trend-frame-saver;
start raw_minute_trend_saver;
#start frame-writer "225.225.225.1" broadcast="131.215.113.0" all;
#sleep 5;

 With a help from Joe, I made a diagram of the simulated plant for green locking in order to get better understanding and consensus.

Eventually these simulated plants will help us developing (sometimes debugging) the digital control systems.

Here is the diagram which tells us how we will setup and link the control/plant models and on which machine they will be running.

Basically upper side represents the realtime control, and the lower side is the simulated plant.

The models are talking to each other via either a local shared memory (orange line) or the reflective memory network (purple line).

 Each model is stil not systematically named, at some point we have to have an absolute standard for naming the models.

- current model names -

  GCV = Green Control model at Vertex

  GCX(Y) = Green Control model at X (Y) end

  GPV = Green Plant model at Vertex

 - things to be done -

1. let the RFM work

2. revise the old plant models : SUP, SPX(Y) and LSP

Accelerometers xyz were moved from IOO-south/west  corner to under PSL table. They were turned off for ~20 minutes.

Guralp was also moved eastward about 2 ft. It is not leveled.

This is part of the preparation to remove access connector.

(Koji, Kiwamu, Yuta)

Lots of progress for the optics placement in the vacuum chamber.
We are ready to go to the next step: open the access connector between IMC and OMC. 

Background:

The actual work in the vacuum chamber started.
The first goal of the vent is to get the green beam coming out from the chambers to the PSL table.

What we did:

1. Inspection of the tip-tilt suspension

The alignments of the TTs were inspected. We had five TTs having been sitting on the table in Bob's clean room.
Prior to their installation we checked the alignments of those because they sometimes showed large hysteresis mainly in the pitch directions.

If a TT has the hysteresis, the pitch position doesn't come back to the previous position. This may cause an issue of the interferometer operation.

- SN001, SN003, SN005 looked well aligned and show no hysteresis.

- The alignment of SN002 was not so good (theta ~ 0.004 rad ) compared to those three, but no hysteresis, we think this guy is still acceptable for the installation.

- SN004 had an apparent hysteresis. This guy doesn't come back to the previous place, being applied a touch. We have to fix this at some point.

2. Work in the ITMX chamber

Now all of the optic in this chamber was installed in the approximate place.

- Installed POX/POP steering mirrors.

- TT(SN003) was placed.

- The two steering optics for ITMX OPLEV were placed at the designed positions.

3. Work in the BS chamber

Installed 2 TTs to the BS chamber.
- SR3: TT(SN001)
- PR3: TT(SN005)

After the alignment of the green steering mirrors, we confirmed
the green beam is successfully hitting the west wall of the OMC chamber.

Those TTs are approximately aligned using the weakly reflected green beams.

Next work:

- Open the access connector

- Place another periscope and two steering mirrors for green

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

I modified the dhcpd.conf file in /etc/dhcp on the fb machine.  I added a entry for c1ioo, listing its MAC address and ip number near the bottom of the file.  I then restarted the dhcp server using "sudo /etc/init.d/dhcpd restart" while on the fb machine.

I also modified the rtsystab, which is used to determine which front end codes start on boot up of a machine.  I added a line: c1ioo   c1x03  c1ioo

I am now in the process of getting c1ioo to come up as a Gentoo machine so I can build a model with an RFM connection in it and test the communication between c1sus and c1ioo.  This involves removing the hard drives and checking to make sure the boot priority is correct (i.e. it checks for a network boot).

 I uninstalled gstreamer-devel and gst-plugins-base-devel on Rosalba.  Here is the command I ran:

$ sudo yum remove gstreamer-devel gstreamer-plugins-base-devel

Actually, I had installed these myself a few days earlier, before I knew that I should be recording such changes in the elog.  I'm sorry!

I've updated the CDS wiki page listing the wiring of the 40m suspensions with the correct binary output channels.  I previously had confused the wiring of the Auxillary crate XY220 (watchdogs) with the SOS coil dewhitening bypasses.  So I had wound up with the wrong channels (the physical cables we plugged in were correct, just what I thought was going on channel X of that cable was wrong).  This has been corrected in the plan now.  The updated channel/cable list is at http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/Suspension_wiring_to_channels

Inside the FSS box, the FAST path has a ~10 Hz pole made up from the 15k resistor and the 1 uF cap before the output connector.

This should be moved over to the output of the driver to make the driver happy - without yet measuring the high frequency response,

it looks like to me that its becoming unhappy with the purely capacitive load of the NPRO's PZT. This will require a little surgery inside

the FSS box, but its probably justified now that we know the Thorlabs box isn't completely horrible.

 We measured the Thorlabs HV Driver's TF today. It is quite flat from 1k to 10k before going up to 25 dB at 100k,

and the response does not change with the DC offset input.

The driver is used for driving the NPRO's PZT which requires higher voltage than that of the previous setup.

We need to understand how the driver might effect the FSS loop TF, and we want to make sure that the driver

will have the same response with DC input offset.

Setup

We used SR785 to measure the TF. Source ch was split by a T, one connected to Driver's input, another one connected to the reference (ch A). See fig2.

The driver output was split by another T. One output was connected to NPRO,

another was connected to a 1nF capacitor in a Pomona box, as a high pass filer (for high voltage), then to the response (ch B)

 The source input is  DC offset by 2V which corresponds to 38 V DC offset on the driver's output.

The capacitance of the PZT on the NPRO is 2.36 nF, as measured by LC meter.

 The result shows that the driver's TF is flat from 1k to 10k, and goes up at higher frequency, see fig1.

The next step is trying to roll of the gain at high frequency for PZT. A capacitor connected to ground might be used to roll off the frequency of the driver's output.

We will inspect the TF at higher frequency (above 100 kHz) as well.

We realized we cannot build code with the current RCG compiler on c1ioo or c1iscex, since these are not Gentoo machines.  We need either to get a backwards compatible code generator, or change the boot priority (removing the harddrives also probably works) for c1ioo and c1iscex so they do the diskless Gentoo thing.  This would involve adding some MAC address to the framebuilder dhcpd.conf file in /etc/dhcp along with the computer IPs, and then modifying the /diskless/root/etc/rtsystab with the right machine names and models to start.

I also need to bring some of the older, neglected models up to current build standards. I.e. use cdsIPCx_RFM instead of cdsIPCx and so forth. 

Need to fix the binary outputs for c1sus/c1mcs.  Need to actually get the RFM running, since Kiwamu was having some issues with his green RFM test model.  We have the latest checkout from Rolf, but we have no proof that it actually works.

The c1sus model was split into 2, so that c1sus controls BS, PRM, SRM, ITMX, ITMY, while c1mcs controls MC1, MC2, MC3.  The c1mcs uses shared memory to tell c1sus what signals to the binary outputs (which control analog whitening/dewhitening filters), since two models can't control a binary output.

This split was done because the CPU time was running above 60 microseconds (the limit allowable since we're trying to run at 16kHz). Apparently the work Alex had done getting testpoints working had put a greater load on the cpu and pushed it over an acceptable maximum.    After removing the MC optics controls, the CPU time dropped to about 47 microseconds from about 67 microseconds.  The c1mcs is taking about 20 microseconds per cycle.

The new model is using the top_names functionality to still call the channels C1SUS-XXX_YYY.  However, the directory to find the actual medm filter modules is /opt/rtcds/caltech/c1/medm/c1mcs, and the gds testpoint screen for that model is called C1MCS-GDS_TP.adl.  I'm currently in the process of updating the medm screens to point to the correct location.

Also, while plugging in the cables from the coil dewhitening boards, we realized I (Joe) had made a mistake in the assignment of channels to the binary output boards.  I need to re-examine Jay's old drawings and fix the simulink model binary outputs.

Our visiting graduate student Yuta Michimura received 40m specific basic safety training today.

For some reason, the dhcp server running on the fb machine which assigns the IP address to c1sus (since its running a diskless boot) was down.  This was preventing c1sus from coming up properly.  The symptom was an error indicated no DHCP offers were made(when I plugged a keyboard and monitor in).

To check if the dhcp server is running, run ps -ef | grep dhcpd.  If its not, it can be started with "sudo /etc/init.d/dhcpd start"

1) Need to check 1 PPS signal alignment

2) Figure out why 1PPS and ADC/DAC testpoints went away from feCodeGen.pl?

3) Fix 1PPS testpoint giving NaN data

4) Figure out why is daqd printing "making gps time correction" twice?

5) Need to investigate why mx_streams are still getting stuck

6) Epics channels should not go out on 114 network (seen messages when doing
burt restore/save).

7) Dataviewer leaves test points hanging, daqd does not deallocate them
(net_Writer.c shutdown_netwriter call)

8) Need to install wiper scripts on fb

9) Need to install newer kernel on fb to avoid loading myrinet firmware
(avoid boot delay)

I've added a new directory in /opt/rtcds/caltech/c1/core called rts_simlink.  This directory is now in the 40m svn.  Unfortunately, the simlink files used to generate the front end c codes live in a directory controlled by the CDS svn.  So I've copied the .mdl files from /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/ into this new directory and added them into the 40m svn.  When making changes to the simlink files, please copy them to this new directory and check them in so we can a useful history of the models.

Alex is installing the newly compiled gds code (compiled on Centos 5.5 on Rosalba) which does in fact include the ezca type tools. 

At the moment we don't have a solaris compile, although that should be done at somepoint in the future.  It means the gds tools (diaggui, foton, etc) won't work on op440m.  On the bright side, this newer gds code has a foton that doesn't seem to crash all the time on Linux.

Alex fixed the time issue with the IRIG-B signal being far off, apparently their IRIG-B signal in downs seems to be different.  He simply corrected for the difference in the two signals in the code.

For debugging purposes we uncommented the following line in the feCodeGen.pl script (in /opt/rtcds/caltech/c1/advLigoRTS/src/epics/util/):

print EPICS "test_points ONE_PPS $dac_testpoint_names $::extraTestPoints\n" 

This is to make every ADC testpoint available from the IOP (such as c1x02).

Its pretty exciting to see that Joe got Alex to actually use the ELOG. Its a proof that even rare events occur if you are patient enough.

1) I fixed the MEDM links to point to the new sitemap.adl in /opt/rtcds. There is a link on the new sitemap which points to the old sitemap so that there is nothing destroyed yet.

2) Some of the fields in the screen are white. These are from the new c1sus processor, not issues with the slow controls. I think its just stuff that has not yet been created in the C1SUS simulink module.

3) The PZT steering controls are gone. Without this we cannot get the beam down the arm. Must fix before aliging things after the MC. Since PZT used to be controlled by ASC, we'll have to wire the Piezo Jena PZT controls in from a different VME 4116. Possibly c1iool0's crate?

4) Also, the IPANG and IPPOS are somehow not working right. I guess this is because they are part of the ASC / the old ETMX system. We'll have to wire the IPANG QPD into the new ETMY ADC system if we want to get the initial alignment into the Y-arm correct.

5) I've started migrating things over from the old SITEMAP. Please just use the new SITEMAP. it has a red link to the old one, but eventually everything on the new one will work after Joe, Alex, me, and Kiwamu are done tweaking.

(Kiwamu, Yuta)

Background:
 We wanted to make aldabella and mariabella know how to work.

What we did:
1. Added 2 lines to /etc/rc.local
 /sbin/modprobe ndiswrapper
 sleep 10
 mount linux1:/home/cds/ /cvs/cds

2. Edited ~/.cshrc
 source /cvs/cds/caltech/cshrc.40m

Result:
 Working environment is set to aldabella and mariabella. They have their access to the main system, linux1, now.

Note:
 fstab doesn't work for aldabella and mariabella because the mount should be done after ndiswrapper loads.

The frame builder is timed from the Symmetricom GPS card now, which is getting the IRIGB timecode from the freq. distribution amplifier (from the VME GPS receiver card).

I have adjusted the GPS seconds to match the real GPS time and the DTT seems to be happy: sweeping MC2 MCL filter module produces nice plot.

Test points are working on SUS.

Excitations are working on SUS.

I am leaving the frame builder running and acquiring the data.

Alex

There currently seems to be a timing issue with  the frame builder.  We switched over to using a symmetricom card to get an IRIG-B signal into the fb machine, but the gps time stamp is way off (~80 years Alex said).

If there is a frame buiilder issue, its currently often necessary to kill the associated mx_stream processes, since they don't seem to restart gracefully.  To fix it the following steps should be taken:

Kill frame builder, kill the two mx_stream processes, then /etc/restart_streams/, then restart the frame builder (usual daqd -c ./daqdrc >& ./daqd.log in /opt/rtcds/caltech/c1/target/fb).

To restart (or start after a boot) the nds server, you need to go to /opt/rtcds/caltech/c1/target/fb and type

./nds /opt/rtcds/caltech/c1/target/fb/pipe

At this time, testpoints are kind of working, but timing issues seem to be preventing useful work being done with it.  I'm leaving with Alex working on the code.

Background:
 We need laptops that connect to the wireless network to use them in the lab.

mariabella:
 Dell Inspiron 1210 laptop
 Broadcom Corporation BCM4312 802.11b/g (rev 01) (PCIID: 14e4:4315 (rev 01))

What I did:
1. I followed the same steps I did for aldabella: http://nodus.ligo.caltech.edu:8080/40m/3623
 Except I unzipped R151517-pruned.zip.
   http://myspamb8.googlepages.com/R151517-pruned.zip

2. Note that the PCIID is important for driver selection. Not the model No.
 To check whether your driver selection is correct, run:
  # ndiswrapper -l
 after installing the driver.
 If the driver selection is wrong, it will return only:
  bcmwl5 : driver installed
 If correct, it will return:
  bcmwl5 : driver installed
         device (14E4:4315) present (alternate driver: hoge)
 This page has some information for the driver selection:
   https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx/Feisty_No-Fluff#Step%202:%20Download%20and%20Extract%20Drivers

Result:
 aldabella now connects to the wireless martian network.

Note:
 Broadcom official driver didn't work for mariabella, too.

The control room's north west corner smelled like propane gas  yesterday around 16:30

We all agreed that the smell was real and I called the safety office. I was told that they received 6 other calls from different parts of the campus.

The smell disappeared in about a half an hour.

The centos 5.5 compiled gds code is currently living on rosalba in the /opt/app directory (this is local to Rosalba only).  It has not been fully compiled properly yet.  It is still missing ezcaread/write/ and so forth.  Once we have a fully working code, we'll propagate it to the correct directories on linux1.

So to have a working dtt session with the new front ends, log into rosalba, go to opt/apps/, and source gds-env.bash in /opt/apps (you need to be in bash for this to work, Alex has not made a tcsh environment script yet).  This will let get testpoints and be able to make transfer function measurements, for example

Also, to build the latest awgtpman, got to fb, go to /opt/rtcds/caltech/c1/core/advLigoRTS/src/gds, and type make.  This has been done and mentioned just as reference.

The awgtpman along with the front end models should startup automatically on reboot of c1sus (courtesy of the /etc/rc.local file).

 Atm1, Vertex crane controller unit on horizontal I-beam.

            Module CCES-407 1HP 2.3A 460V/3 phase on the right was replaced. Speed was increased  to 30 Hz

Atm2, See burned insulation on black wire that was shorting to the large suppressor resistor on Atm3 One can see the pit marks on the right end of it.

        This large power dissipater resistor got hot as the malfunctioning controller 407 broke down.   Touching black power wire insulation melted and made a short.

          So the heat was created and finally the fuses were blown. The unnecessary large fuses were replaced by small ones.

Fortunately we had one spare controller on hand that made this repair to be done fast.

We used the new Crane Safety Check list  from LIGO-E1000379-v1 the first time yesterday before doors were removed.

Background:
 We need laptops that connect to the wireless network to use them in the lab.

aldabella:
 Dell Inspiron E1505 laptop
 Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) (PCIID: 14e4:4311 (rev 01))

What I did:
1. I followed this method(Japanese!): http://www.linuxmania.jp/wireless_lan.html
 Except I installed ndiswrapper-1.56 and cabextracted sp32156.exe.
  http://sourceforge.net/apps/mediawiki/ndiswrapper/index.php?title=Broadcom_BCM4311
 Also, I didn't run
  # ndiswrapper -m

2. Then I did step #6 in here: http://nodus.ligo.caltech.edu:8080/40m/1275
 Note that the hardware is eth1 instead of wlan0.

3. Added the following line to /etc/rc.d/rc.local to make ndiswrapper load on every boot:
 /sbin/modprobe ndiswrapper

Result:
 aldabella now connects to the wireless martian network on every boot!!

Note:
 Somehow, the method that uses Broadcom official driver doesn't work.
  http://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom
 It returns the following error when activating eth1:
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1 ; Invalid argument.
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1; Invalid argument.

(Steve, Koji, Joe, Kiwamu, Yuta)

Background:
 The vent was started on Monday, and finished on Tuesday.
 We were to open the doors on Tuesday, but we couldn't because the vertex crane got out of order.
 Now the crane was fixed, and so we opened the doors today.

What we did:
 We opened the north side of the BS chamber and the west side of the ITMX chamber.
 Now, the light doors are put instead.

This is being recorded for posterity so we know where to look for the old controls settings.

The last good burt restore that was saved before turning off scipe25 aka c1dcuepics was on September 29, 11:07.

After asking Alex specifically what he did yesterday after I left, he indicated he copied  a bunch of stuff from Hanford, including the latest gds, fftw, libframe, root.  We also now have the new dtt code as well.  But those apparently were for the Gentoo build   After asking Alex about the ezca tools this morning, he discovered they weren't complied in the gds code he brought over.  We are in the process of getting the source over here and compiling the ezca tools. 

Alex is indicating to me that the currently compiled new gds code may not run on the Centos 5.5 since it was compiled Gentoo (which is what our new fb is running and apparently what they're using for the front ends at Hanford).  We may need to recompile the source on our local Centos 5.5 control machines to get some working gds code.  We're in the process of transferring the source code from Hanford.  Apparently this latest code is not in SVN yet, because at some point he needs to merge it with some other work other people have been doing in parallel and he hasn't had the time yet to do the work necessary for the merge.

For the moment, Alex is undoing the soft link changes he did pointing gds at the latest gds code he copied, and pointing back at the original install we had.

I found that several linux libraries have been moved around and disabled today. In particular, I see a bunch of new stuff in apps/linux/ and ezca tools are not working.

Who did this and why is there no ELOG ???

Also found that someone has pulled the power cable to the function generator I was using to set the VCO offset. This is the one on top of the Rb clocks. Why?? Why no elog? This is again a big waste of time.

We found a small PCB defect which is an excess copper shorting circuit on the daughter board,

it was removed and the signal on mixer monitor path is working properly.

 We were checking the new TTFSS upto test 10a on the instruction, E1000405 -V1. There was no signal at MIXER mon channel.

It turned out that U3 OpAmp on the daughter board, D040424, was not working because the circuit path for leg 15 was shorted

because of the board's defect. We can see from fig1 that the contact for the OpAmp's leg (2nd from left) touches ground.

We used a knife to scrap it out, see fig 2, and now this part is working properly.

The vertex crane drive is overheating, it stopped functioning. Service man will be here tomorrow morning.

I crane was just turned  on for for may be  about 5 minutes. The vertical drive was fine for a while, but the horizontal did not worked at all.

The crane is tagged out again and the controller box is cooling down.

 Looking at the sliders, I apparently still need to connect them properly.  There's a mismatch between the medm screen channel name and the model name.  At the moment there is no "slow" slider effect implemented, so they are effectively instantaneous.  Talking with Alex, he suggests writing a little c-code block and adding it to the model.  I can use the c code used in the filter module ramps as a starting point.

(Koji, Yuta, Kiwamu)

Now the pressure at P1 is 740 torr, which is close to the atmospheric pressure of 760 torr.

We changed the air cylinder twice in this evening, and the last cylinder ran out at about 23:00 pm.

We left it as it is. Steve is going to make a final touch for it tomorrow morning.

 took two runs of the script as usual

The medm screens have been updated further, with the hidden matrices added in bright colors.  An example screen shot is attached.

Megatron has been renamed c1ioo and moved to martian network.  Similarly, c1sus and c1iscex are also on the martian network.  Medm screens can be run on any of the control machines and they will work.

Currently the suspension controller is running on c1sus.

The frame builder is currently running on the fb machine *however* it is not working well.  Test points and daq channels on the new front ends tended to crash it when Alex started the mx_stream to the fb via our new DAQ network (192.168.114.XXX, accessible through the front ends or fb - has a dedicated 1 gigabit network with up to 10 gigabit for the fb).  So for the moment, we're running without front end data. Alex will be back tomorrow to work on it. 

Alex claimed to have left the frame builder in a state where it should be recording slow data, however, I can't seem to access recent trends (i.e. since we started it today).  The frame builder throws up an error "Couldn't open raw minute trend file '/frames/trend/minute_raw/C1:Vac-P1_pressure', for example.  Realtime seems to work for slow channels however.  Remember to connect to fb, not fb40m. So it seems the fb is still in a mostly non-functional state.

Alex also started a job to convert all the old trends to the correct new data format, which should finish by tomorrow.

RA: Nice screen work. The old screens had a 'slow' slider effect when ramping the bias so that we couldn't whack the optic too hard. Is the new one instantaneous?

Blocked PSL output beam  into IFO

Checked: HV at IOO & OMC are off, jam nuts in position,

Closed V1 and VM3, opened VV1 to N2 regulator

We are venting at 1 Torr/min rate

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

Issues I notice on first glance:

1. The OSEM Sensor Input matrix and the DOF2COIL Output matrix screens should be their own screens and linked from the overview. Right now they are not. Where is the input matrix?
2. The SIDE GAIN looks like zero on the main screen, but the side OSEM signal seems to be getting through to the SIDE filter bank. . I think the wiring of the SIDE signal through the input matrix is bogus.
3. The OUTPUT matrix seems to be the transpose of the previous OUTPUT matrix and we have lost the wires that connect the inputs and outputs to the matrix. We ought to think about how best to represent things on the OVERVIEW screen; probably only need to have a minimal representation and allow power users to open up the detailed screen.
4. The TIME string is whited out. How will this be done? Does each FE display its local time on its EPICS screens?
5. So far unable to get any channels on DV. How do we look at channels / test points?
6. As far as we can tell, there is no connection between the output of the SUSPOS, etc. filter banks and the OUTPUT MATRIX. So....nothing actually goes to the coil driver. Its hard to imagine that this new SUS could have ever worked. Is there any evidence that the damping actually worked in the past, or was it something like "well, the watchdog values came down to small numbers eventually..." ???
7. We are trying to debug the simulink file, but....the wiki entry on how to do this is out of date (yet updated as recently as August!) some path stuff just probably needs to be edited.

Basically the suspensions are not functioning yet and we can't attempt locking of the MC.