40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop

40m Log, Page 343 of 348  Not logged in

List |  Find |  Login |  Help

Full | Summary | Threaded | Hide attachments     -- All entries -- Last day Last 3 Days Last week Last month Last 3 Months Last 6 Months Last Year -- Type -- Configuration Update Summary HowTo Bureaucracy Omnistructure Metaphysics Frogs  17373 Entries

Goto page Previous  1, 2, 3 ... 342, 343, 344 ... 346, 347, 348   Next

ID Date Author Type Category Subject   277   Sun Jan 27 13:13:21 2008 tobin Metaphysics General departure It's been grand. Thanks for having me! GWAVES IN '08! Sugar napoleons may be forwarded to T. F., c/o LLO, P.O. Box 940, Livingston, LA 70754-0940.   276   Sat Jan 26 22:00:03 2008 John Update General LSC-TRY_OUT and ETMY-QPD In the path from the ETM to the trans PD and QPD at the Y end I have replaced a BS1-1064-10-2037-45P with a polariser. The power falling on these diodes has been reduced. When the arm is locked in its nominal state the transmitted power is now less than 1. This polariser should serve as an injection point for the auxiliary arm locking. I am attempting to use crossed polarisations to separate this loop from the main arm light.   275   Sat Jan 26 18:48:43 2008 John Summary Computers Restart iscepics iscepics died this afternoon. We restarted it and restored settings from yesterday. I've written up instructions in the wiki.   274   Sat Jan 26 18:12:45 2008 rana HowTo Computers extra processes and crashes There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.) You can check this by running top. IF there's lots of them you can kill them by using 'pkill'. I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup.   273   Sat Jan 26 02:34:34 2008 Andrey Update Computer Scripts / Programs Overnight Measuremts in XARM I am running the program for measuring RMS of peaks in XARM tonight. I just started it, and it will run for about 9 hours until noon on Saturday. Please do not disturb the interferometer. Now the XARM is locked, it should stay locked over the night. Andrey.   272   Sat Jan 26 02:08:53 2008 John Omnistructure LSC Fibres There is now a fibre running from the SP table to the ISCT at the Y-end. In the coming days I will try to mode match the beam from this fibre into the arm through ETMY. To achieve this I will be altering the optical layout of this table.   271   Sat Jan 26 02:02:43 2008 John Summary General New Channels I added the following channels. # C1ASC_QPDs [C1:SUS-ETMY_QPDSUM_MON] [C1:SUS-ETMY_QPDYAW_MON] [C1:SUS-ETMY_QPDPIT_MON] [C1:SUS-ETMX_QPDSUM_MON] [C1:SUS-ETMX_QPDYAW_MON] [C1:SUS-ETMX_QPDPIT_MON] The old .ini file is /cvs/cds/caltech/chans/daq/C0EDCU_26_1_2008.ini   270   Fri Jan 25 21:36:40 2008 rana Update CDS mDV / channel issues Fri Jan 25 21:30:00 2008 As it turns out, the residual problem with the mDV stuff was not to do with our button pushing episode but instead fallout from the 'turning off of the computers' during the water leak caused by the rain and construction. The /frames partition from fb0 (the FrameBuilder) is not mounted to the control machines via vfstab; it does not remount on bootup. I originally did this because Ben Johnson and Dave Barker had warned me that during a power outage, fb0 may not come up right away. This could make the control room machines hang up for awhile. I elected to have the mount be by hand. So the thing to do is to put the mount command into the cold start procedures (Andrey). Its in an old elog entry of mine from Feb '07.   269   Fri Jan 25 17:11:07 2008 Max , Andrey Configuration General NEW_FETCH_SHOUROV and GET_DATA do not work The problem which started yesterday after Andrey's framebuilder restart still persists. It is still impossible to read data in the past from the channels using "get_data" which in turn uses "new_fetch_shourov". Max was trying to read data from the channel "C1:LSC-DARM_CTRL", and he got the same error messages as Andrey. Andrey tried earlier today to read data from "C1:SUS-ITMS_SUS" or "C1:SUS-ETMX_SUS" with the error meassge Error in ==> new_fetch_shourov at 22 at (start_time+duration) > stops(end) So, it seems that Robert Ward fixed just one problem out of two problems. Robert revived the realtime signals in Dataviewer, but did not revive the memory of channels for new_fetch_shourov. To be more precise, channels have memory (it is possible to see the "Playback" curves in Dataviewer"), but "get_data" and "new_fetch_shourov" do not see the data from those channels. The problem appeared immediately after Andrey's clicking on blue buttons to restart the framebuilder. Andrey again apologizes.   268   Fri Jan 25 15:53:59 2008 Alberto Update Electronics 40 dB from the 3rd order Chebyschev I managed to tune the 7 knobs in the 3rd order Chebyshev bandpass filter obtaining the tranfer function attached to this entry. We have now 40 dB of attenuation between 166 Mhz and 133 and 199. With this tuning the insertion loss is rather high. We need a better one. Alberto Attachment 1: 166MhzElog.png   267   Fri Jan 25 13:36:13 2008 josephb Configuration Cameras Working GiGE video on Mafalda Finally got the GiGE camera sample viewer video running on Mafalda by updating to the latest API (version 1.16 from Dec 16, 2007) from Prosilica and then using the modified Sample Viewer code I had written. The API version previously in cvs was 1.14. It can currently be run by ssh -X into Mafalda and going to /cvs/cds/caltech/target/Prosilica/bin-pc/x86 and running the SampleViewer executable found there.   266   Fri Jan 25 11:38:16 2008 josephb Configuration Cameras Working GiGE video on Linux - sort of 1)I have been able to compile the SampleViewer program which can stream the video from the Prosilica 750C camera. This was accomplished on my 64-bit laptop running Ubuntu, after about 3 hours of explicitly converting strings to wxStrings and back again within the C++ code. (There was probably an easier way to simply overload the functions that were being called, but I wasn't sure how to go about doing so). By connecting it to the CDS network, I was able to immediately detect the camera and display the images. Unfortunately, I have not yet been able to get it to compile on Mafalda with the x86 architecture. This may be do the fact that it has wxWidgets version 2.8.7 while my laptop has 2.8.4. Certainly the failure at compile time looks different from the errors earlier, and seem to be within the wxWidget code rather than the SampleViewer code. I may simply need to uninstall 2.8.7 and install 2.8.4 of wxWidgets. The modified code that will compile on my machine has been copied to /cvs/cds/caltech/target/Prosilica/examples/SampleViewer2b. 2)The Snap program (under /cvs/cds/caltech/target/Prosilica/examples/Snap) also will now take full resolution images even on Mafalda. This was achieved by reducing the packet size to 1000 and also increasing the wait until timeout time up to 400 ms, which originally was at 100. Apparently, it takes on the order of 1 ms per packet as far as I can tell. So full resolution at 752x480 required something of order 360 packets. To Do: 1) Get sample viewer to compile on Mafalda, and then statically compile it so it can be run from any Linux based machine. 2) Get a user friendly version of Snap up and running, statically compiled, with options for a continuous loop every X seconds and also to set desired parameters (such as height, width, file name to save to, save format, etc). 3) Figure out data analysis with the images in Matlab and an after the fact image viewer. Attached is an example .tiff image from the Snap program. Attachment 1: snap.tiff   265   Fri Jan 25 10:14:35 2008 rob Configuration SUS Changes to Dataviewer channels (XARM) Quote: 2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen, namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked, and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line). Description of what has happened and of my wrong actions: I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"), and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became a straight line, while signal from "C1:SUS_ETMX_POS" continued to be a random noise. I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal. As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight, but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS". Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels. I apologize for the negative consequences of my channel adding, but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem. I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.   264   Fri Jan 25 09:22:21 2008 steve Update PEM burned toast award goes to DYM for collaborating with the enemy. In order to minimize the number of ants visiting our lab we have to take out side the lab all food left over and organic waste. If you are eating here do not expect someone else to clean up after you. Thanks for your cooperation.   263   Fri Jan 25 08:55:26 2008 rob Configuration General Changes to Dataviewer channels (XARM) As a general rule, Quote: clicking random blue buttons chaotically is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.   262   Thu Jan 24 22:52:18 2008 Andrey Bureaucracy General Ants around a dirty glass (David - please read!) Dear coleagues, there are rains outside these days, so ants tend to go inside our premises. David was drinking some beverage from a glass earlier today (at 2PM) and left a dirty glass near the computer. There are dozens, if not hundreds, of ants inside of that glass now. Of course, I am washing this glass. A.   261   Thu Jan 24 22:10:49 2008 Andrey Configuration Computer Scripts / Programs Problem with channels - help of Rana, Robert or Steve is needed I definitely spoiled something (changes some settings) by chaotically clicking those blue buttons (see my previous entry # 260). Unfortunately, I cannot use standard library of functions for reading from channels from mDV directory. Although I see the curve of a noise in the Dataviewer from the channel "Ch1:SUS_ETMX_POS", when I try to read data from the channel using the program "get_data" from MDV directory, I get the error message "Warning: No data available for [numbers representing "gps_start_time" and "gps_end_time"]. In new_readframedata at 136 In new_fetch_shourov at 71 In get_data at 98" I checked, both gps-times are in the past from now, so as far I understand, nothing is recorded into the channels. Of course, I added two hours ago to the directory "mDV", that is I used addpath(pwd) in that directory. And I also cannot run the program that I used on Tuesday evening which takes data from "C1:SUS_ITMX_POS" (no data from that channel), which worked perfectly on Tuesday. I again apologize for clicking the wrong blue button (see my explanation in my previous message #260). I ask someone who knows how to return normal working of channels (normal interaction of computer and channel memory) to do that. Before that I cannot take data. I do not know how to restore the initial settings which existed before I started adding the channel to Dataviewer. Andrey.   260   Thu Jan 24 20:03:40 2008 Andrey Configuration SUS Changes to Dataviewer channels (XARM) 1) Good news. I added a chanel "C1:SUS-ETMX_POS" to Dataviewer. I followed the instructions from WIKI-40: modify the file "C1SUS_EX.ini" in /cvs/cds/caltech/chans/daq, then telnet to fb40m, then "click the appropriate blue button on the DAQ MEDM screen". So, I can now read a signal from the channel "C1:SUS-ETMX_POS" in Dataviewer, and this allows me to measure Q-factors of ETMX this evening (make similar work for what I did on Tuesday for ITMX). 2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen, namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked, and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line). Description of what has happened and of my wrong actions: I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"), and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became a straight line, while signal from "C1:SUS_ETMX_POS" continued to be a random noise. I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal. As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight, but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS". Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels. I apologize for the negative consequences of my channel adding, but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem. Again, I apologize and hope that the problem is not very serious.   259   Thu Jan 24 12:50:50 2008 John Summary Treasure Sugar Napoleons Some pictures from the group meeting yesterday. Attachment 1: Sweeties.pdf   258   Thu Jan 24 11:52:56 2008 steve Update PEM the mud is cleaned up & MOPA shutter is opened Safety glasses are required again! I have just opened the mopa shutter. One janitor came to help with muddy floor. Rack 1x1 toward ITMX chamber and the south wall of these area were completely covered by mud. I wiped the floor of bottom of the rack with towels. The cables were lifted and still should be wiped. The bottom of LSC rack got less water, only on the west side. We are ready to bring up the computers. Thanks to ALL with the clean up, including Alan Rice who was really helpful.   257   Wed Jan 23 20:52:40 2008 rana Summary Environment Flooding from construction area We noticed tonight around 7 PM that there was a lot of brown water in the control room and also in the interferometer area mostly concentrated around the north wall between the LSC rack and the AP table. The leak was mainly in the NW corner of the interferometer area. The construction crew had set up sandbags, plastic sheet, and gravel to block the drains outside of the 40m along the north wall. The rain had produced ponds and lakes outside in the construction area. Once the level got high enough this leaked through holes in the 40m building walls (these are crappy walls). We called the on-call facilities team (1 guy). He showed up, cut through the construction fence lock, and then unblocked the drains. This guy was pretty good (although inscrutable); he adjusted the sandbags to control the flow of the lake into the drains. He went along the wall and unblocked all 3 drains; there were mini-lakes forming there which he felt would eventually start leaks all along our north wall. In the morning we'll need volunteers to move equipment around under Steve's direction while the floor gets mopped up. There's dirt and mud all over, underneath the chambers and racks. Luckily Alberto spotted this early and he, Jon, Andrey and Steve kept the water from spreading and then scooped it all up with a wet-vac that the facilities guy brought over. Extra Napoleon to them for late evening mud clearing work. Many pictures were taken: Update and pictures will appear later. Attachment 1: Shop-Vac_Action.MOV Attachment 2: Flooding.pdf   256   Wed Jan 23 12:31:36 2008 Andrey Summary SUS Dissapointing Results of XARM optimization (PDF-file) I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain, and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)), but now those dependences are plotted in Q-ITMX and Q_ETMX axes. Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry). The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting. Attachment 1: Sad_Results_XARM.pdf   255   Wed Jan 23 11:41:06 2008 steve Update PEM sulfur smell in 40m Led - acid car batteries were overcharged in the machine shop next door and sulfuric acid smell is coming over to the ifo room. Entry room 103 is specially bad.   254   Wed Jan 23 09:27:55 2008 steve Update   etmy sus damping restored Seismis event trips etmy Attachment 1: etmysus.jpg   253   Tue Jan 22 13:11:03 2008 tobin Update ASC ETMY oplev recentered The light wasn't even on the diode.   252   Tue Jan 22 02:33:45 2008 rob Update LSC DRMI work 0) The ETMY oplev needs work/centering 1) recentered DRMI oplevs 2) Did some light DRMI locking. Looked at the loops and the DD signals. The PODD signals look flaky; the beam may not be on the diode. MICH and PRC handoffs to DD signals were spotty, but not a total disaster. Changed the PD9 phase by 115 degs. Work continues on the DD_handoff subscript. 3) John says "There are ants everywhere." 4) Andrey is now versed in the arts of decimation.   251   Mon Jan 21 23:30:03 2008 Andrey Update Computer Scripts / Programs Matlab Program for Q-factor measurements (XARM -> ITMX and ETMX) Finally I overcame difficulties with adapting Sonia's Matlab programs for XARM (Sonia's program was for MC), and now there exists a Matlab program that makes a fit of a ringdown curve and calculates Q-factor for a mirror ITMX. Specifically, this program allows to measure ringdown, fit it and calculate Q-factor for the ITMX-mirror for a specific value of "C1:SUS-ITMX_SUSPOS_GAIN". Attached is a plot of a ringdown curve and its fit for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN". Calculations yield the result Q=3.7+-0.2 for the value 4.0 in channel "C1:SUS-ITMX_SUSPOS_GAIN". As Robert started 10 minutes ago the long procedure of the whole interferometer locking, I cannot disturb the interferometer now, so I will measure Q-factors for various combinations of suspension damping gain on Tuesday. I will also easily modify the program for measuring Q-factors of ETMX-mirror and make measurements with ETMX on Tuesday. The Matlab scripts are in directory /cvs/cds/caltech/users/rodionov/Q-Factors/ Attachment 1: Example-ITMX_POS_40.png   250   Fri Jan 18 20:53:56 2008 tobin Configuration General ETMY oplev I monkeyed around with the ETMY oplev, adding a folding mirror and moving the HeNe so that John, Sam, and I have more room for our auxiliary laser setup. (The ISCT-EY has more room than ISCT-EX; the latter has an extra photodiode for IP ANG.) I believe I successfully recommissioned the oplev, though it might not be up to the SV standard. I verified that wiggling the ETMY alignment sliders showed corresponding wiggles in the oplev signals. However, it seems poorly diagonalized. Our current plan is to have an NPRO, EOM, and fiber coupler on the SP table. This fiber will take light to ISCT-EY where we'll have a mode-matching telescope and inject light to the Y arm via a polarized beamsplitter. This auxiliary beam will have polarization orthogonal to the beam from the PSL.   249   Fri Jan 18 15:31:47 2008 rob Update LSC Thursday's locking rob, johnnie, andrey On Thursday night we got the intereferometer fully locked in a power-recycled FPMI state. The obstacles included the REFL166 phase being wrong by 180 deg (because that's the correct phase for DRMI locking) and getting confused (again) by the "manual" mode dewhite switching at the ETMs. After turning on the dewhites and the MICH correction, we took the noise spectrum below. Attachment 1: DARMnoise080118.png   248   Fri Jan 18 11:53:50 2008 Alberto Update Electronics RF Monitor Band-pass Filter The response is asymmetric and on the left side of the peak, we have at least 33dB within 33Mhz, which is enough for all the frequencies. We probably don't need an higher order filter but just low pass filters in series. The spike at 320MHz doesn't depend on the circuit board. It's either the cables, their connection, or the splitters. Note that the frequency of this test circuit has still to be tuned exactly at 166MHz (now it's 149). Alberto Quote: After we finalized the schematic for the RF monitor board based on buffered LC resonators, on Richard Abbott's suggestion to avoid the complication brought in by the fast op-amps, we gave another chance to the a passive configuration of the band-pass filter based on a Chebyshev topology. Rich and Ben gave me an old but very powerful software tool to design that kind of filters and showed me the way to circumvent many hassles in making RF test boards. I made a test circuit for the 166MHz line (see attached schematic), using tunable inductors. The TF are also attached. We get more than 20 dB of isolation after 33MHz (with a loss of only few dB at the resonance - it could be less), which is enough for all the other frequencies (33,133,199 MHz) but we would like more for the 166. We are going to add one or two extra orders to the filter. We also have to understand the spike at about 320Mhz and eventually somehow get rid of it. Alberto Attachment 1: Chebyshevb.png   247   Thu Jan 17 20:50:55 2008 tobin Update General fiber coupling Sam, John, and I matched the beam from an NPRO into a fiber on the SP table today. In doing so we used our GigE camera for a physics application for perhaps the first time, viewing the transmitted mode from the fiber during initial alignment. (I used my laptop running Windows and a 100 megabit switch.)   246   Thu Jan 17 18:22:14 2008 Alberto Update Electronics RF Monitor Band-pass Filter After we finalized the schematic for the RF monitor board based on buffered LC resonators, on Richard Abbott's suggestion to avoid the complication brought in by the fast op-amps, we gave another chance to the a passive configuration of the band-pass filter based on a Chebyshev topology. Rich and Ben gave me an old but very powerful software tool to design that kind of filters and showed me the way to circumvent many hassles in making RF test boards. I made a test circuit for the 166MHz line (see attached schematic), using tunable inductors. The TF are also attached. We get more than 20 dB of isolation after 33MHz (with a loss of only few dB at the resonance - it could be less), which is enough for all the other frequencies (33,133,199 MHz) but we would like more for the 166. We are going to add one or two extra orders to the filter. We also have to understand the spike at about 320Mhz and eventually somehow get rid of it. Alberto Attachment 1: RF166Mhz.png Attachment 2: Chebyshevb.png Attachment 3: Chebyshev2b.png   245   Thu Jan 17 15:11:13 2008 josephb Update Cameras Working on Malfalda 1) I can statically compile the ListCamera code (which basically just goes out and finds what cameras are connected to the network) on Malfalda and use that compiled code to run on Linux2 without a problem. Simply needed to add explicit links to libpthread.a and librt.a. (i.e. -Bstatic -L /usr/lib/ -lpthread -Bstatic -L /usr/lib -lrt) With appropriate static libraries, it should be possible to port this code to other linux machines even if we can't get it to compile on the target machine itself. 2)I've modified the Snap.cpp file so that it uses a packet size of 1000 or less. This simply involves setting the "PacketSize" attribute with the built in functions they provide in their library. After un-commenting some lines in that code, I was able to save tiff type images from the camera of up to 400x240 pixels on Malfalda. The claimed maximum resolution for the camera is 752x480, but it doesn't seem to work with the current setup. The max number of pixels seems to about 100 times the packet size. I.e. packet size of 1000 will allow up to 400x240 (96000) but not 500x240 (120,000). Not sure if this is an issue just with snap code or the general libraries used. 3)Will be working towards getting video running over the next day or so.   244   Thu Jan 17 14:13:20 2008 rob Update LSC Wednesday's locking Incremental progress on locking yet again. This time the handoff of DARM to the OMC worked, and progress halted at handing off control of the common mode to REFL166.   243   Wed Jan 16 19:57:49 2008 tobin Configuration Photos ISCT_EX Here's a photo of the ISCT_EX table, for the purpose of planning our auxiliary laser arm locking scheme. Note the (undumped!) beam from the beamsplitter before QPDX (the leftmost gold-colored box); perhaps we could inject there. Attachment 1: trx-annotated-small.jpg   242   Wed Jan 16 18:24:41 2008 rana Update SUS ETMY Watchdog Because Steve keeps complaining about ETMY, I looked at some minute trend to see if there was something exotic happening at that time. It looks like there is some tremendous seismic activity to make it happen. The trend shows that there is nothing special happening on the ETMX accelerometer or the ETMX suspension. At the same time, however, there is a huge jump in the ETMY sensors and therefore the watchdog signal. Whenever the watchdog value goes above 140, it trips. After Andrey moves some accelerometers over to the Y end we can see the effect more directly. Attachment 1: A.pdf   241   Wed Jan 16 14:09:45 2008 rob Update LSC tuesday's locking I got a little further with the locking (PRFPMI) last night, after discovering that the cable going from the CM board to the MC board was unplugged at the MC side. This explains why we weren't able to engage the AO path last night. Tonight, I got up to the point where DARM is handed off to OMC transmission, a step which repeatedly failed. Eventually I realized that although all the lights are the green, the OMC Trans signal was not being updated in the LSC's memory. I suspect this is because the c1ass machine was powered down. Work continues.   240   Wed Jan 16 14:06:24 2008 rob Update LSC monday's locking rob, tobin, johnnie We did some locking work monday night, with decent progress. Working in the PRFPMI style, we managed to get through the part of the script that hands off the offset-CARM DOF to the MCL, but were not successful in engaging the AO path. We also confirmed the problem with tdsread which prevent it from reading from multiple TLS (Three Lettered Subsystems) at the same time. Tobin traced this to a problem with the ezca library which tds uses, but it's not clear how to fix it. For now we just split the tdsread calls so that there are no multiple TLS calls. Tobin will report further on this.   239   Tue Jan 15 13:15:27 2008 tobin Update Environment lots of noise They're throwing concrete around at the construction site.   238   Mon Jan 14 23:11:26 2008 tobin Configuration General fiber John and I removed the fiber that ran from the SP table to the cleanroom. We plan to build a MZ interferometer with this fiber inserted into one of the arms, for the purpose of measuring its phase noise.   237   Mon Jan 14 14:41:09 2008 steve Update SUS etmy sus damping restored & mz relocked Tree days trend of MZ HV drift is typical these days. So as the etmy sus inability to hold damping for longer then 2-3 days. Attachment 1: etmysus&mzhvtrend.jpg   236   Fri Jan 11 17:01:51 2008 pkp Update Cameras GigE again So, here I detail all the efforts on the GigE so far (1) The GiGE camera requires a minimum of 9 kb packet size, which is not available on mafalda or on my laptop ( both of which run Ubuntu and the Camera programs compile there). The programs which require smaller sizes work perfectly fine on these machines. I tried to statically compile the files on these machines so that I could then port them to the other machines. But that fails because the static libraries given by the company dont work. (2) On Linux2, which lets me set a packet size as high as 9 Kb, it doesnt compile because of a GLIBC error. I tried updating the glibc and it tells me that the version already existing is the latest ( which it clearly is not). So I tried to uninstall GLIBC and reinstall it, but it wont let me uninstall (it == rpm) glibc, since there are a lot of dependencies. A dead end in essence. Steps being taken (1) Locally installing the whole library suites on linux2. Essentially install another version of gcc and g++ and see if that helps. (2) IF this doesnt work, then the only course of action I can take is to cannibalize linux2's GigE card and put it on mafalda. ( I need permission for this ). Once again any suggestions welcome.   235   Thu Jan 10 15:04:04 2008 steve Update SUS illuminator light effect on BS position The bs chamber illuminator light was turned on this morning and left on. Earlier on Rana noticed that the bs moved. I follwed up to see what happened. I turned off oplev servo and tried to recenter on oplev pd by adjusting pitch and yaw biases. It did not move. I looked at suspention and realized that the illuminator was still on. I turned it off and to my amazement the the AP spot started flashing Attachment 1: bssusilum.jpg   234   Thu Jan 10 13:45:52 2008 Pkp Update Cameras GLIBC Error So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things) ../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4' collect2: ld returned 1 exit status make: *** [sample] Error 1 I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does. If anyone has any idea how to resolve this issue, please let me know. Thanks Pinkesh.   233   Thu Jan 10 12:08:23 2008 steve Update SUS why did the BS move? Attachment 1: bshopped.jpg   232   Thu Jan 10 10:38:02 2008 steve Update SUS etmy damping restored The IST building onstruction has really started yesterday and continuing today with big heavy ground breaking machinary. The MC is holding lock and the suspentions are hanging on. ETMY does not like this. SUS-MC2_LLPD_VAR monitor is a good indicator of seismic activity on this 12 days plot Attachment 1: etmysus.jpg Attachment 2: sustrend16d.jpg   231   Thu Jan 10 00:12:01 2008 tobin Summary Locking DR [John, Tobin, Rana] 1. We found SUS_BS_SENSOR_UL to have a ratty signal and low DC value. Twiddling the cables at the BS satellite amplifier and vacuum feedthrough brought the signal back (to 0.667V), but it is still spiky, spiking up to a couple times per second. Rana suggested that these spikes might be scattered YAG laser light (as hypothesized in August). The spikes go away when we misalign the PRM or either ITM, and when we unlock the mode cleaner, lending credance to this theory. SUS_BS_SENSOR_UR also spikes, but much less frequently. We turned off C1:SUS-BS_ULSEN_SW2 and continued. 2. After dither alignment the oplev beams were centred and we were able to lock DRM plus either arm reliably (however locking in this state broke ./drstep_bang at the first ``Going DD''). We ran scripts/DRFPMI/bang/nospring/drdown_bang and were subsequently able to lock DRFPMI (i.e., full IFO) a couple times. 3. To do: Debug ./drstep_bang with just the DRM (no arms).   230   Wed Jan 9 20:36:42 2008 Go Update Treasure Money in lab Go's Desk. Attachment 1: DSC_0370.JPG   229   Wed Jan 9 20:29:47 2008 Dmass AoG TMI Coffee Carafe If you have been using the coffee machine in the 40m, you may have noticed small brown flecks in your coffee mug. The carafe in the 40m has accumulated a layer of what is presumed to be old dried up coffee. When a small amount of water is swirled around in the bottom, flecks of the brown layer come off. Pictures below are of the inside of the carafe. But does it provide adequate protection from 1064 light? Attachment 1: DSC_0363.JPG Attachment 2: DSC_0365.JPG Attachment 3: DSC_0368.JPG   228   Wed Jan 9 10:47:15 2008 fricke Update Computers ethernet wiring in office/control room The electrical people have been here for three days, installing ethernet cables and drops in the 40m office area, in the old conduits where there was power and 10base2. Soon we will have reliable ethernet connections, instead of relying on switches hanging from the ceiling, etc!

Goto page Previous  1, 2, 3 ... 342, 343, 344 ... 346, 347, 348   Next

ELOG V3.1.3-