I modified /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to include the C1:LSC-DegreeOfFreedom_TRIG_MON channels. These are the same channel that cause the LSC screen trigger indicators to light up.
I vaguely followed Koji's directions in elog 5991, although I didn't add new grecords, since these channels are already included in the .db file as a result of EpicsOut blocks in the simulink model. So really, I only did Step 2. I still need to restart the framebuilder, but locking (attempt at locking) is happening.
The idea here is that we should be able to search through this channel, and when we get a trigger, we can go back and plot useful signals (PDs, error signals, cotrol signals,....), and try to figure out why we're losing lock.
Rana tells me that this is similar to an old LockAcq script that would run DTT and get data.
EDIT: I restarted the daqd on the fb, and I now see the channel in dataviewer, but I can only get live data, no past data, even though it says that it is (16,float). Here's what Dataviewer is telling me:
Connecting to NDS Server fb (TCP port 8088)
LONG: DataRead = -1
No data found
T0=13-03-29-08-59-43; Length=432010 (s)
No data output.
Connecting to NDS Server fb (TCP port 8088)
LONG: DataRead = -1
No data found
T0=13-03-29-08-59-43; Length=432010 (s)
No data output.
I seem to be able to retrieve these channels ok from the past:
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ tconvert 1049050000
Apr 03 2013 18:46:24 UTC
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ ./general/getdata -s 1049050000 -d 10 --noplot C1:LSC-PRCL_TRIG_MON
Connecting to server fb:8088 ...
nds_logging_init: Entrynds_logging_init: Exit
Hit any key to exit:
Maybe DTT just needed to be reloaded/restarted?
apt install source-highlight
then modified bashrc to point to /usr/share instead of /usr/bin
Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings. These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates.
I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics.
An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big. We should considering flipping SR3 instead or SR2 when dealing with the SRC. I'll take responsibility for messing up the calculation for the flipped TTs.
RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor.
I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3. There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.
The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with. I vote we flip SR2, not SR3.
Updated laser inventory and operator list. They are posted in the 40m wiki and entry doors of the 40m IFO room.
Let me know if this list needs correction.
Lightwave M126N-1064-700 NPRO sn 337 in the PSL enclosure got connected to local emergency shut off switch. This is a LIGO operational safety requirement.
In an attempt to clean up the medm situation, I did a bunch of further rearrangement and cleanup. Instead of having c1ifo, I moved a bunch of stuff into a MISC directory, including all of the CDS, IFO, and VIDEO screens:
controls@rossa:~ 0$ ls -1 /opt/rtcds/caltech/c1/medm/MISC | grep -v _BAK
I updated the sitemap and the relevant screens accordingly.
I also updated the IFO_ALIGN script infrastructure a bit. The new IFO ALIGN location is /opt/rtcds/caltech/c1/medm/MISC/ifoalign. The scripts are now called simply:
These run Jenne's new soft restore stuff, and store burt snapshots for optic alignment in /opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt.
This has all been checked into the svn.
I updated the getdata script so that it can now handle downloading long stretches of data.
It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.
I also added a couple new options:
* --append allows for appending to existing data files
* --noplot suppresses plotting during download
I updated the peakFit routines to make them a bit more user friendly:
These changes were committed to the 40m svn.
I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.
After poking at the new configuration more, it also started to show instability. I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.
I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.
Upgraded zita's ubuntu and restarted the striptool script.
Use LISO - see what it tells you. I would think that you should make a differential RC filter to get the right behavior. (e.g. 1K on each leg and 1 uF between them)
Each leg of the diff input of the board has a 4k input impedance.
But surely the AO input to the MC servo should also make sense independently.
I used APTITUDE to install texlive-full on rosalba so that I could work on a paper. pdflatex was not found on pianosa, rosalba, megatron, etc. I used this command:
sudo aptitude install texlive-full
While this was installing, I read a bunch of forums which claim that its better to bypass the apt-get and use the
TexLive installer instead so that we can use its own package updater 'tlmgr'. Otherwise, the standard Ubuntu distributions
are years out of date (e.g. doesn't have RevTex 4.1).
LISO confirms that I did my algebra right in picking the component values, and shows no extra zeros.
I also took some TFs with the SR785 and confirmed that both CM board inputs behave the same, and that including the LPF on the input gives the expected 1/f shape at the slow and fast outputs.
Jenne and Koji
We successfully hung ITMX on the SOS. Side magnet is ~2mm off from the center of the OSEM. ITMX aligned using the QPD. The OSEMs changes the alignment. It looks that something magnetic is inside the OSEM PD or LED.
Reguled ITMY side magnet.
Cleaned up the lab for the safety inspection.
The brand new OSEM LED and PD can be picked up with a weak magnet. These ferrous metals of LEDs and PDs will be magnetized by sitting in the sus next to the
magnets for years. I hanged optics with new OSEMs and never saw this effect before.
We have to demagnetize them.
The OSEM LEDs and PDs from Honeywell have always had some ferromagnetic material in them. These are the same OSEMs we had since 2000.
You must be thinking of the really old 20th century plastic OSEMs.
Last night, I used 1.5 m delay line COARSE and got 5FSR mode scan. The range 5FSR was limited by the range of SR560.
So, this time, we used 6.4 m(21 feet) cable as a delay line for FINE servo. This should increase the sensitivity by factor of 4. But the range will be 4 tmes smaller, ~ 1.3FSR.
Below is the plot of the mode scan.
You can see the peak height difference between TEM00s, but it's just from the resolution of pixels.
You still can see noisiness goes up when blue plot goes down. But this time, 2000 stands for 27 MHz and -2000 stands for 15 MHz in the beat frequency because we flipped the filter gain this time.
Last night, the top of the triangle was about 40 MHz and bottom was about 60 MHz.
We are going to derive mode-matching and some cavity parameters using this plot.
JoeB and JamieR are working somewhat coherently on a set of python libraries to fulfill all of our command line CDS wants. This is being done mostly to satisfy The Guardian and the SkunkTools project.
I did an 'svn up' in /opt/rtcds/userapps (it might finish in ~1000 years) to get the things that they have so far (in particular, Joe's 'pyavg'). There's going to be some issues since the pylib stuff written by Yuta/Kiwamu has never been integrated with anything and is imported as 'epics' in many python scripts. As we move over to the new stuff there will be a lot of broken script functions since the new libraries are also used in that way.
Rana suggested using OSEM sensing voltages as guide lines to look seismic activity.
As you see todays drilling and tumping activity was nothing compared to the EQ of mag 5 and 4
Optic level servos are turned back on.
What Steve means is that there is some drilling going on in the CES shop to accomodate the new water flume group. We want to
make sure that the mirrors don't move enough to break the magnets. On the dataviewer we should look to make sure that the
sensor channels stay between 0-2 V. -Rana
We really need something better to replace the access connector when we're at air. This tin foil tunnel crap is dumb. We can't do any locking in the evening after we've put on the light doors. We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.
It is in the shop. It will be ready for the next vent. Koji's dream comes through.
24" diameter clear acetate access connector is in place. The 0.01" thick plastic is wrapped around twice to insure air and bug tight barrier for the MC to lock overnight. The acetate transmission for 1064 nm is 90 % This was measured at 150 mW 2.5 mm beam size.
Aluminum sheet as shown will replace the acetate. Side entries for your arms and "window" on the top will be covered with acetate using double- sided removable-no residue tape 3M 9425
The second loop of the bungee cord should be on the top of the acrylic and still on the supporting aluminum tube as shown.
We tried not to open chambers above 10,000 particles of 0.5 micron cf/min
New items going in: 2 rasor beam traps, 5 badly oxidized old silver plated setscrew with spring loaded tips......to be replaced in the future, viton tips for eq screws....some are lose, gold plated allen wrench installed at ITMX bottom, reglued magnet on ITMX
Bad hardware things found: nylon ball "locking elements" on OSEM locking set screws with screwdriver slot, lose 1064 nm filter on OSEM pd
This is the first touch to the MC mirrors after the earthquake on 16th.
So far, I have aligned in Yaw such that the yaw peak is minimized.
This seal is good for daily use- operation only. The IFO has to be sealed with light metal doors every night so ants and other bugs can not find their way in.
Our janitor Kevin is mopping the hole IFO room floor area with 5% ant killing solution in water in order to discourage bugs getting close to our openings of the vented chamber.
You may be sensitive to this chemical too. Do not open chamber till after lunch.
Matt and Koji:
We closed the light doors of the chambers.
Cold cathode gauge CC4 is reading normal.
CC1 is glitching, it is probably dirty.
CC2 is fluctuating too much and it is cutting out for 6-7 minutes. It must be insulated by deposits and there is no emission current.
I think the same goes for P1
They will have to be replaced at the next vent
The COVAC_MONITOR.adl was changed. Ion pump labeled as disconnected means: ion pump controller power turned off and ion pump gate valve control connection disconnected.
RP2 roughing pump labeled disconnected means: hardware disconnected.
The actual operational, valve control screen has not been changed yet.
We run out of N2 for the vacuum system. The pressure peaked at 1.3 mTorr with MC locked. V1 did not closed because the N2 pressure sensor failed.
We are back to vac normal. I will be here tomorrow to check on things.
We run out of N2 for the vacuum system 6 hrs ago. The pressure rose to 1.2 mTorr with V1 closed. The interlock worked! See Nirogen presure reading fixed at http://nodus.ligo.caltech.edu:8080/40m/10968
The vacuum interlock: Nitrogen pressure transducer is reading the pneumatic pressure continously at the pump spool and c1vac1 processing it. When it drops below 60 PSI it closes V1 gate valve and V4 & V5. Gate valve V1 needs minimum 60 PSI to close. It is critical that V1 is closed before you run out of Nitrogen so the IFO pressure is contained.
IFO vacuum is back to Vac Normal. The MC is locked.
cc4 = 2E-6 Torr with VM1 open.
Daily N2 consumption measured to be 530PSI as 3 days on 3-27-2015 but note: it does vary !
I have seen it as high as 900 psi The long term average ~750 psi
Amstron batteries replaced after 11 months with SP-12-5.5HR, 2 years warranty from replaceUPSbattery.com
Batteries replaced after 3.5 years with Amstron AP-1250F2, 8x 12V 6Ah
APC Smart -UPS 2200 model: SUA2200RM2U batteries were replaced by compatible RBC43, 8x 12V5A
Note: the replace battery LED did not go out ( well pasted 24 hrs ) till the self test bottom was hold down for 2-3 sec
Ben and I found this vacuum valve relay box intermittently shorthing yesterday.
It effects V4, V5, VA6 and VM1........ Please do not touch this box under the beam pipe next to the vac rack!
The function of this box to send 120VAC to the vacuum valve to move.
Steve and I managed to access the fuse in the vacuum VME crate, but replacing it did not bring it back up. We decided to replace the entire crate.
We manually checked that the most important valves, VC1, VM1 and V1, were all closed. We disconnected their power so that they would automatically close, and we wouldn't have to worry about them accidentally opening when we rebooted the system.
We noted where all the cables were, disconnected everything, and removed the crate. We noted that one of the values switched when we disconnected one of the IPC cables from a VME card. We'll note which one it was in a followup post. We thought that was a little strange, since the VME crate was completely unpowered.
Anyway, we removed the crate, swapped in a spare, replaced all the cards and connections, double checked everything, then powered up the crate. That's when minor chaos ensued.
When the system came back online after about 20 seconds, we heard a whole bunch of valves switching. Luckily we were able to get the medm screens back up so that we could see what was going on.
Apparently all of the ION pump valves (VIPEE, VIPEV, VIPSV, VIPSE) opened, which vented the main volume up to 62 mTorr. All of the annulus valves (VAVSE, VAVSV, VAVBS, VAVEV, VAVEE) also appeared to be open. One of the roughing pumps was also turned on. Other stuff we didn't notice? Bad.
We ran around and manually unplugged all of the ION pump valves, since I couldn't immediately pull up the vacuum control screen. Once that was done and we could see that the main volume was closed off we went back to figure out what was going on.
We got the medm vacuum control screen back (/cvs/cds/caltech/medm/c0/ve/VacControl_BAK.adl. really??) There was a lot of inconsistency between the readback states of the valves and the switch settings. Toggling the switches seemed to bring things back in line. At this point it seemed that we had control of the system again. The epics readings were consistent with what we were seeing in the vacuum rack.
We went through and closed everything that should have been closed. The line pressure between the big turbo pump TP1 and the rest of the pumps was up at atmosphere, 700 Torr. We connected the roughing pumps and pumped down the lines so that we could turn the turbos back on. Once TP2 and TP3 were up to speed, we turned on TP1 and opened V1 to start pumping the main volume back town. The main volume is at 7e-4 Torr right now.
So there are a couple of problems with the vacuum system.
I connect belledona, the laptop at the vacuum station to the wired network, so that it's connection would be less flaky.
[ericq, Gautam, Steve]
Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive.
The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...
Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".
[ Gautam and Steve ]
c1vac1 and c1vac2 were rebooted and the gauges are communicating now. V1, VA6, V5 and V4 were closed and disconnected to avoid unexpected valve switching. All went smoothly.
The new ITcc gauge is at 1e-5 Torr as CC1 This is the gauge that should be logged in slow channel.
TP2 fore line dry pump was replaced this morning after 382 day of operation.
TP3 dry pump is very noisy, but it's pressure still 47 mTorr
There is a planned power outage tomorrow, Saturday from 7am till midnight.
I vented all annulies and switched to ALL OFF configuration. The small region of the RGA is still under vacuum.
The vac-rack: gauges, c1vac1 and UPS turned off.
Vac- rack is powered back up. UPS first, than all other power switches from top to bottom of the rack, except Maglev
Manually started one by one TP2 and TP3 to accelerate to 50 KRPM
Brought up vac.control screen on lap-top at /cvs/cds/caltech/medm/c0/ve/VacControl_BAK.adl
V5 and VM3 were opened so TP3 can pump on the RGA
V4 was opened so TP2 can pump on the Maglev-TP1. The Maglev power was turned on and started acceleration.
The vac control screen positions indicators were checked for true position and annulies vent valves were opened.
RGA manual on/off switch was turned at the top of the RGA-head. Ubuntu copmuter was started at cc4 1.1e-6 Torr
The RGA communication was started with: ssh c0rga from control room
The rga-script was started ./RGAset.py This script turns on the filament, rs-232 and scan parameters etc
Vac -configuration: IFO-P1 at atm, RGA is pumped and running in background mode, all annulos at atm
There is BLANK VacControl_BAK.adl screen only.
I can move a valve by disconnecting it's solenoid power if it's position is normally open.
I will close V1 and check computer cable connections and move on with manual - hand disconnect ea valve to be moved into the right position for vent. Valve positions will be confirmed by looking manual indicators on valves.
Rana stated yesterday that there will be a vacuum control update in the close future. Witnesses : Rich, Chris and Dave
Can you give me this in writing?
Convectron gauge check:
Brand new 10 years old convectron gauge at atm was swapped into the place of existing gauges to see if they read close to 760 Torrs
They did reasonable well at the low end. I tried to imitate calibration and bring down the high end with little success.
( P1 and P2 were reading 7e-4 to ~660 Torr The correction of the upper end pushed up the lower end too. I will correct this later
P3 and P4 high ends are way off )
The point is that they work. Convectron gauges will be replaced and calibrated at the next vent.
Interlocks were not triggered during this test. I was expected to close the PSL shutter when P1 was reading 760 Torr
This hide some problem or not understanding.
It was good to see CC1 and CC4 working at the moment
Somehow I succeded opening VM1 and closed VM2 = vacuum normal
I just hope it stays open overnight to get comparable RGA scan.
In Steve's absence, I've tried to keep an eye on the health of the vacuum system. From Attachment #1, the pressure of the main volume seems stable, no red flags there. I also don't here any anomalously loud sounds near the vacuum pumps. I've changed the N2 cylinders that keep V1 open twice, on Wednesday and Sunday of last week. So in summary, the vacuum system looks fine based on all the metrics I know of.
The pumpdown had stalled because of some ancient vacuum interlock code that prevented opening the valve V1 between the turbo pump and the main volume.
This interlock  compares the channels C1:Vac-P1_pressure and C1:Vac-PTP1_pressure, neither of which is functioning at the moment. The P1 channel apparently stopped reading sometime during the vent, and contained a value of ~700 torr, while the PTP1 channel contained 0. So the interlock code saw this huge apparent pressure difference and refused to move the valve.
To bypass this check, we used caput to enter a pressure of 0 for P1.
Morning condition: vacuum rack power is still off, no MEDM screen reading.....meaning unknown vacuum pressure.We closed PSL shutter immediately.
Joe restored c1iscepis and Jenne powered up the vac-rack UPS. Now the rest of the vac-rack power were restored from starting at the top to bottom.
P1 was reading 15 mTorr. We restarted pumps and set vacuum valve positions. V1 opening required Rob's recipe of elog # 1863 to defeat interlock that
has a non communicating gauge: PTP1
CC1 pressure just reached 1e-6 Torr at VAC NORMAL configuration.