With the completion of Assembly #1 testing, the ISI is locked. Actuator and GS13 Cabling is now disconnected.
For completeness, here is the list of channels currently being acquired by the qts (all at 2048Hz). [L1:QTS-Q1_M0_FACE1_IN1_DAQ] [L1:QTS-Q1_M0_FACE2_IN1_DAQ] [L1:QTS-Q1_M0_FACE3_IN1_DAQ] [L1:QTS-Q1_M0_LEFT_IN1_DAQ] [L1:QTS-Q1_M0_RIGHT_IN1_DAQ] [L1:QTS-Q1_M0_SIDE_IN1_DAQ] [L1:QTS-Q1_M0_X_EXC_DAQ] [L1:QTS-Q1_PEN_LLSEN_IN1_DAQ] [L1:QTS-Q1_PEN_LRSEN_IN1_DAQ] [L1:QTS-Q1_PEN_POS_EXC_DAQ] [L1:QTS-Q1_PEN_ULOUT_EXC_DAQ] [L1:QTS-Q1_PEN_ULSEN_IN1_DAQ] [L1:QTS-Q1_PEN_URSEN_IN1_DAQ] [L1:QTS-Q1_R0_FACE1_IN1_DAQ] [L1:QTS-Q1_R0_FACE2_IN1_DAQ] [L1:QTS-Q1_R0_FACE3_IN1_DAQ] [L1:QTS-Q1_R0_LEFT_IN1_DAQ] [L1:QTS-Q1_R0_RIGHT_IN1_DAQ] [L1:QTS-Q1_R0_SIDE_IN1_DAQ] [L1:QTS-Q1_R0_X_EXC_DAQ] [L1:QTS-Q1_UI_LLSEN_IN1_DAQ] [L1:QTS-Q1_UI_LRSEN_IN1_DAQ] [L1:QTS-Q1_UI_POS_EXC_DAQ] [L1:QTS-Q1_UI_ULSEN_IN1_DAQ] [L1:QTS-Q1_UI_URSEN_IN1_DAQ] Giving a 16 second full frame file size of 3.2MB.
Betsy reported two problems with the QTS DAQ this morning, getting past data and getting real time data using DTT. The DTT issue was due to the system time being 7 seconds off. After correcting the system time, I had to restart the DAQ for DTT to get realtime data. We tested it with DAQ channels and testpoint channels. I have corrected the root crobtab which should keep the system clock synchronized to the LHO NTP server. The trending problem was due to the DAQ not writing trend files since 19 Apr 2009. However full frames are being written, with a look back of 8 days. I noticed that only 25 channels are in the frame, all at 2048Hz acquisition rate. Betsy suggested we get together with Mark next week to see if more channels need to be added to the frame, and perhaps save some at the 16384Hz native rate. I also found that the QTS daq system is very old, with frame file layout as per S5 standards. Could we upgrade this system to aLIGO standards?
After switching to the new "actual flange BNC feed-thrus", power spectra were run for the CPS's with the table un-locked. Attached are spectra taken when the table was LOCKED (w/ both mini-racks on & with only one on---as we've done for the previous measurements). Data is saved at: /opt/svncommon/seisvn/seismic/HAM-ISI/X1/Data/unit_1/dtt/20100722_all_disp_locked_spectra.xml
A few weeks ago, we discovered we had a FAILED Horizontal GS13. From our quick tests, it seemed as though we had a stuck mass inside the GS13---we were able to free the mass when we tilted the Table. For an exercise in checking the effects of a tilted table on our remaining functioning GS13s, we carried out some table tilt measurements on the table and looked at spectra from our GS13s (namely the Horizontal ones). We tilted the table by placing weights on the table in various locations. We used various types of Adjustment Masses D071200. Here are masses for the types of weights we used to tilt the table: Type 1: 0.5 kg Type 2: 1.0 kg Type 3: 2.1 kg As for the tilts, we did a few. Referencing this coordinate drawing(sorry, for some reason, aLOG wouldn't let me upload this picture), we tilted the table along several axis: RY: +RY tilt would have weights placed over the V1 GS13 (-RY had weights on side opposite of V1 Act). The RY tilts would tilt the H3 GS13 up and down along its axis (which is parallel to X RX: +RX tilt would have masses placed over H3 GS13 (-RX would have masses placed on side opposite H3 GS13). This measurement doesn't really line up with a clean tilt for any of the horizontal GS13's; they are all at angles with respect to RX tilts "H1": Here we wanted to perform a tilt for the H1 GS13 (similar to what the RY tilt did for the H3 GS13). A "-H1" tilt had masses placed over the V2 GS13 ("+H1" tilt had masses on spot opposite to V2 GS13. "H2": Here we wanted to perform a tilt for the H2 GS13 (similar to what the RY tilt did for the H3 GS13). A "-H2" tilt had masses placed over the V3 GS13 ("+H2" tilt had masses on spot opposite to V3 GS13. On this coordinate drawing referenced above, +Y & +X are the same as H1's (i.e. +Y points toward Rattlesnake Mountain). Overall, in the measurements we start out with an unlocked & balanced table with it's respective spectra. Small amount of masses are added (they are posted in each plots title). The system is ok with a little tilt, but once you get to a certain tilt the spectra changes noticeably (i.e. the primary resonances around 1-2Hz get knocked down & the high frequency behavior changes). The data for these measurements are saved at: /opt/svncommon/seisvn/seismic/HAM-ISI/X1/Data/unit_1/dtt With file names: 20100713_+RXtilt_geo_spectra.xml 20100713_-RXtilt_geo_spectra.xml 20100713_+RYtilt_geo_spectra.xml 20100713_-RYtilt_geo_spectra.xml 20100713_+H1tilt_geo_spectra.xml 20100713_-H1tilt_geo_spectra.xml 20100713_+H2tilt_geo_spectra.xml 20100713_-H2tilt_geo_spectra.xml
I had to clear the message queues for the TestStand this morning due to too many current message queues. The script to do so is 'rmq' in the scripts directory: '/opt/apps/scripts/'
A quick check on DTT - I loaded a channel in and hit start with default DTT settings loaded (channel was L1:QTS-Q1_MO_FACE1_IN1). After a few seconds of thinking it gave a "Test timed-out" error at the bottom. Richard hinted at a timing problem...? Also - how can I load the "editable" medm? And, we are ready to calibrate channels. Instructions on where to do this would be appreciated. BTW - All 12 Top Mass BOSEMs have been zeroed and are at 50% OLV. So signals and controls on L1:QTS-Q1_MO and Q1_RO channels are live.
The attached document shows the transfer functions used to compute the LZMP. The number we have are good: 0.24 mm and 0.30 mm in the X and Y directions respectively. However, we need a better coherence on the cross couplings in order to confirm these numbers. We are doing another measurement with much more averages (a 6 hours drive in each X direction).
We have redone a low frequency measurement (0.01 hz to 0.1 Hz) with much more averages (222) in order to estimate with more accuracy the lower zero moment point offset (distance between the actuators and zero moment point of the rods). The data is stored in: 100721_LZMP_0p01to0p1Hz_M2M_test2_tfretrieve.mat The script used to take data is : TFcollect_100721_LZMP_0p01to0p1Hz_30avg.m This script does contain 220 averages contrary to what his name says. The result are presented on the plot attached. The offset estimation is lower than it was: Last measurement gives: X offset = 0.24 mm Y offset = 0.30 mm versus X offset = 0.14 mm Y offset = 0.16 mm as presented in yesterday entree base on a measurement using only 30 averages. The numbers we get are very good, and maybe surprisingly low (that's less than .01" offset). However, they are consistently low so that we can conclude that we are good.
(Eric A., Corey G.) Over the last few days, we've bypassed our original BNC feed-thrus on our Interface Board, and are now using actual BNC feed-thrus. The issue here is that the original BNC feed-thrus proved to be troublesome and sacrificed the performance of our Sensors. We've found that using the "real" feed-thrus (and also buying better/expensive feed-thrus) have made our Sensors perform much better. Switching to the new feed-thrus has changed the DC value of of our sensors. At "zero" our Sensors were all under ~1000 counts, but with the new feed-thru the zeroes have increased to around 10,000 counts. Because of this we had to re-gap the Sensors. This sort of change required us to re-do a few more Sensor Tests (according to document T1000329). New Power Spectra for the Displacment Sensors have been run. The measurement is located here: /opt/svncommon/seisvn/seismic/HAM-ISI/X1/Data/unit_1/dtt/unit_1/dtt/20100720_all_disp_spectra.xml Attached are plots of spectra with BOTH Sensor Mini-Racks ON, and with only one ON.
To complete the autoburt alog: how to restore from a snapshot file. Just 'cd' into the directory containing the snapshot files to be used for the restoration. Then use the 'burtwb' command, it takes the snapshot file as an argument. For example, burt restore g1isihamepics to 14:01 snapshot of jul 20th 2010: [controls@seiteststand 14:01]$ cd /data/autoburt/2010/07/20/14:01/ [controls@seiteststand 14:01]$ burtwb -f ./g1isihamepics2010072014:01.snap
I have created an autoburt for seiteststand. It works by scanning the target area for any autoBurt.req files. For each file it finds, it performs a burtrb and saves the snapshot file in the /data/autoburt area. The autoburt runs every hour at one minute past the hour (as a cronjob as user controls on seiteststand). If we need to run at a different rate this is just a crontab change. Currently the script (/opt/rtcds/geo/g1/scripts/autoburt) uses the geo/g1 targets. When we move to X1 this will have to be edited. Here is an example the data directories and snapshot files names: [controls@seiteststand 14:01]$ pwd /data/autoburt/2010/07/20/14:01 [controls@seiteststand 14:01]$ ls g1isihamepics2010072014:01.snap g1x01epics2010072014:01.snap
Richard took another look at the EE QUAD test stand and fixed some current issues, such that signals are now back to expected values of ~32k counts. He also did some work on the satellite box for the AOSEMs, as he determined that jumpers were needed there.
The logbook will be unavailable from 10-noon tomorrow. If you are working on an entry during that period, please save it as a draft before 10am Pacific time. The logbook will undergo some maintenance tomorrow morning. This is to fix some layout issues with the quick search area for webkit based browsers (ie Safari and Chrome). Also it appears that there still is an issue with log session times. It appears that simply extending the Shibboleth SP Session time to a large value is insufficient. I will attempt another short term fix tomorrow. Ultimately it must move to a system that will require re-authentication when the Shibboleth session times out. However it is not quite a quick fix as we must ensure that no data can be lost when handling this. Likely the user will be given a notice that they must login again, but that their post (if there were any pending) have been saved to a draft.
The logbook is going down for maintenance
Maintenance has finished on the aLOG. The following work was done: * Updated CSS and HTML to better layout the quick search fields on Safari, Chrome, Opera, and Internet Explorer * Updated the display logic to highlight search terms better. The search has always been case insensitive, now the highlighting is case insensitive and case preserving. * Another fix to make sure the author name is always filled out. This is a temporary fix, a more correct fix will be needed. * Updated the database to make sure author names matched usernames, ensuring that searching will work properly.
My script which generated the G1ECU.ini file had a bug and built a file with syntax errors in it. This is the reason for the "daqd respawning too fast" error as the daqd process was being autostarted by inittab and crashing out. I fixed the script (/opt/rtcds/geo/g1/scripts/create_edcu_ini.pl) and also changed it to generate a G0EDCU.ini file (not G1). At this point daqd started. However the EDCU complained about another IOC at 10.12.0.13 which had all the channels 10.11.0.24 was serving. Found out that eth1 was active with the 10.12.0.13 IP address, and the IOC was being found on both IP ports. I disabled eth1. we should watch that eth1 is not reinstated on the next reboot Later Corey was having nds issues, so I restarted daqd and nds together since they had a split-start earlier in the day (see above).
(Richard, Dave, Corey) Came in this morning to find INVALID/WHITE medm screens on the iMac near our Test Stand rack in the Staging Bldg. I tried to ssh into the frontend to no avail. Since we were in this state and flying blind (diagnostics-wise), we tried several things to get the frontend re-started: * Hit RESET button on front * Hit REBOOT button on front * Pulled out (both) power cords from back None of these actions did anything (some were tried several times). We had a monitor directly hooked up to the front end, and after various steps, we'd get the following error (right after a login prompt): INIT: Id "fb" respawning too fast: disabled for 5 minutes" Richard logged into the frontend via the login prompt, and was finally able to sorta get the frontend started. We still had issues though. Richard then tracked this down to a network issue (can't remember how he discovered this). He then unplugged the power to the Network router on top of our rack. After this, we were able to get back mostly. There was still a daq/framebuilder issue, and Dave resolved this. Another get_data Issue Towards the end of the day, I tried running a matlab measurement, but there were issues with get_data (our matlab script made 25 attempts at getting data to no avail). Called up Dave, and he ultimately restarted our nds and daq (I believe he said one of them was old). This seemed to have done the trick, since I was able to get_data on my next attempt.
After doing another set of yaw adjustments to get the side BOSEMs in range at the Tablecloth and jacking the TC up by a mm or 2, we continued work to install BOSEMs. So far, we have MO FACE 1,2,3 aligned to 50% OLV, with the rest cabled and mounted to the Tablecloth. This also required the addition of washers behind the FACE magnet flag assemblies in order to get the flag into the BOSEM range. (I recall seeing this at LASTI, but had hoped it had been reconciled in the later drawing revisions. Guess not.) DV and the "InputSignals.adl" medm both proved healthy and useful for this work. Richard verified that the uncalibrated signals which go from 0 to ~ -4000 counts indeed correspond to 0-2V, so we can make some calibration of the channels eventually. Mark Barton came over and began working through input matrices and appropriate signs in various fields. AOSEM installation into Q1 is back on hold, while John re-thinks the RGA scans which had a pretty good air leak. More of the same tomorrow.
I have begun a low-frequency (down to 0.001Hz) measurement on the LHO X1 TestStand. This should take approx. 12hrs, barring any earthquake or major seismic event triggering our watchdogs. It was begun tonight at approx. 18:45 (local). Please no changes to filter banks, medm screens, or use of awgstream. Thanks.
