40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 331 of 337  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  308   Mon Feb 11 14:24:19 2008 steveUpdatePEMmore earthquakes
ITMX and ITMY sus damping restored after Baja earthquake 5.1 mag at 10:29 this morning.

The ground preparation for The ITS building is almost finished.
Activity is winding down, however the Baja California_ Mexico earthquake zone
"Guadala Victoria" started acting up on Friday.

  307   Sun Feb 10 21:43:16 2008 robConfigurationIOOMC alignment tweaked

I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam.
  306   Sun Feb 10 20:47:01 2008 AlanSummarySUSAll watchdogs tripped
A moderate earthquake occurred at 11:12:06 PM (PST) on Friday, February 8, 2008.
The magnitude 5.1 event occurred 21 km (13 miles) NW of Guadalupe Victoria, Baja California, Mexico.
  305   Sat Feb 9 13:32:07 2008 JohnSummarySUSAll watchdogs tripped
When I arrived this afternoon the watchdogs had tripped on all optics. I reset them and enabled the coil currents.

I had to adjust the alignment of the mode cleaner to get it to lock.
  304   Sat Feb 9 13:05:48 2008 JohnSummaryIOOPMC camera/ HEPA
I replaced the Gig-E camera on the PMC trans beam. The PZT was close to railing and I wanted to adjust it. I just did a quick job, there is a little scattered light on the image. If Joe is finished with the Gig-E I'll take another look at it.

The HEPA in the PSL table was turned off for some reason. I turned it back on.
  303   Fri Feb 8 17:55:53 2008 joshConfigurationPEMPEM-AS_MIC now in PSL enclosure
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.

Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam.
  302   Fri Feb 8 17:09:52 2008 Max JonesUpdateComputersChanges to NoiseBudget
Today I altered the following files

In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.

I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.

Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you.
  301   Wed Feb 6 19:39:11 2008 ranaConfigurationCamerasRegions of Interest and max frame rate
We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams...
  300   Wed Feb 6 16:50:47 2008 josephbConfigurationCamerasRegions of Interest and max frame rate
The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.

Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.

The command line I used was

time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000

Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).

As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/.
  299   Wed Feb 6 09:17:31 2008 steveUpdatePEMIST building construction continoues
The bulldosers at work
  298   Tue Feb 5 17:39:05 2008 jweinerConfigurationPEMPEM-AS_MIC taken down from AS table, will put in PSL enclosure soon
I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.
  297   Tue Feb 5 15:32:29 2008 josephbConfigurationCamerasPMC and the GigE Camera
The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.

A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.

The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.

The Gige camera is currently running the Snap code on Linux3 with the following command line:

./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'

So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.

Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535).
  296   Mon Feb 4 22:01:57 2008 JohnSummaryLSCFibres auxiliary locking - Fibers
I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough.
  295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
  294   Sat Feb 2 14:11:27 2008 JohnSummaryComputersOPTLEVmaster screen
I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl
  293   Fri Feb 1 17:17:05 2008 JohnSummaryPSLMach-Zender tweaking
I helped Rob adjust the alignment of the Mach-Zender to try and reduce any AM on the laser light. Our goal was to reduce the large offsets in the DD signals.

We reduced the MZ refl from 0.54 to 0.39. We were able to re-lock the mode cleaner without problems. We then centred the WFS heads.

No change in the DD signal offsets.
  292   Fri Feb 1 15:04:54 2008 josephbConfigurationCamerasSnap with looping functionality available
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.
  291   Fri Feb 1 12:37:39 2008 robUpdateDMFseisBLRMS trends

Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break).
  290   Fri Feb 1 10:43:05 2008 JohnUpdateEnvironmentConstruction work
The boys next door have some bigger noisier toys.
  289   Thu Jan 31 16:53:41 2008 josephbConfigurationCamerasImproving camera user interface
There's a new and improved version of Snap program at the moment people are free to play with.

Located in /cvs/cds/caltech/target/Prosilica/40mCode/

The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.

At the moment, it only runs on mafalda.

Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.

After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).

Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.

I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' "
  288   Thu Jan 31 12:39:14 2008 JohnConfigurationGeneralY arm test mass cameras
I've adjusted the test mass cameras on the y arm to make the beam injected through ETMY more visible.
  287   Wed Jan 30 20:39:31 2008 robUpdateDMFseisBLRMS

In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts.
  286   Wed Jan 30 13:09:55 2008 AndreyUpdateSUSNew results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!
  285   Wed Jan 30 11:49:30 2008 AlbertoSummaryElectronicsRF monitor's filters final schematics and transfer functions
These are the final schematics for the 6th order Chebyshev filters of the RF monitor board. I'm also attaching the TF as I measured. The tuning is probably not optimal, less insertion noise could be achieved.
  284   Tue Jan 29 14:56:39 2008 robUpdateDMFseisBLRMS 1.0

The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly.
  283   Mon Jan 28 19:35:55 2008 ranaSummaryPEMAccelerometer and Seismometer Coherences
The attached PDF shows that there is some strange behavior at low frequencies.

From the plot it looks like to me that the Wilcoxon accelerometers (which are supposed to have good response down to 0.05 Hz) are not displaying real seismic motion below 0.3 Hz. Because the coherence length for seismic waves at those frequencies should be 100's of meters we should expect that the accelerometers would have good coherence (>0.8) down there. Instead, my guess is that its all air currents, temperature, or electronics noise. These sensors are not reliable indicators for the microseism.

The Ranger seismometer, however, seems to work fine down to just below the microseism. The Ranger is mounted down around the X end and pointing in the z-direction. The coherence I plotted between it and EX_Z is larger than any other acc/seis pair (as expected).

JM and I discussed what could be done; if we get a SURF student who's into building stuff we can ask them to make a styrofoam hut for the Wilcoxons to see if that helps anything. JM also asked what the point of all this is.

IF we want to do good Adaptive Noise subtraction then we need sensors which can sense the motion which disturbs the mirrors and they need to sense it with a good SNR to get a good subtraction ratio. If the styrofoam thing doesn't work, we should probably look into getting a Guralp 3-axis seismometer for the corner area and just move the accelerometers down to the ends. The sites have Guralp CMG-40T units (~ 8k$). I think we should check out the CMG-3T or the CMG-3ESP.

Does anyone know someone in the Geo depts that we can borrow one from?
  282   Mon Jan 28 18:56:47 2008 ranaUpdateDMFseisBLRMS 1.0
I made all of the updates I aludded to before:

  • Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer.
  • Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd.
  • Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made.

I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda.

It should be making trends overnight and so we can finally see what the undergrads are really up to.
  281   Mon Jan 28 17:16:54 2008 AndreyConfigurationComputersMatlab libraries DO NOT WORK properly sometimes

Working in Matlab, I encountered at two different times today the license distribution problem:

??? License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
Try again later.
To see a list of current users use the lmstat utility or contact your License Administrator.

Troubleshoot this issue by visiting:
  280   Mon Jan 28 15:11:38 2008 robHowToDMFrunning compiled matlab DMF tools

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.
  279   Mon Jan 28 12:42:48 2008 DmassBureaucracyTMICoffee
There is tea in the coffee carafe @ the 40m. It is sitting as though it were fresh coffee. There is also nothing on the post it.
  278   Sun Jan 27 21:44:48 2008 ranaUpdateCDSSeismic BLRMS on Matlab
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:
  • Use mDV to get data by reading directly from frames.
  • Use the Matlab pwelch function to produce a power spectrum of the channels.
  • Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
  • Makes a tdswrite command string which writes all the values to EPICS channels.
  • The EPICS channels are just a list of simple names in a database file.
  • The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.
  277   Sun Jan 27 13:13:21 2008 tobinMetaphysicsGeneraldeparture
It's been grand. Thanks for having me!


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 JohnUpdateGeneralLSC-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 JohnSummaryComputersRestart 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 ranaHowToComputersextra 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 AndreyUpdateComputer Scripts / ProgramsOvernight 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.

  272   Sat Jan 26 02:08:53 2008 JohnOmnistructureLSCFibres
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 JohnSummaryGeneralNew Channels
I added the following channels.



The old .ini file is /cvs/cds/caltech/chans/daq/C0EDCU_26_1_2008.ini
  270   Fri Jan 25 21:36:40 2008 ranaUpdateCDSmDV / 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 , AndreyConfigurationGeneralNEW_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

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 AlbertoUpdateElectronics40 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.

  267   Fri Jan 25 13:36:13 2008 josephbConfigurationCamerasWorking 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 josephbConfigurationCamerasWorking 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.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)


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 steveUpdatePEMburned 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 robConfigurationGeneralChanges to Dataviewer channels (XARM)

As a general rule,

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 AndreyBureaucracyGeneralAnts 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.

  261   Thu Jan 24 22:10:49 2008 AndreyConfigurationComputer Scripts / ProgramsProblem 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.

  260   Thu Jan 24 20:03:40 2008 AndreyConfigurationSUSChanges 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 JohnSummaryTreasureSugar Napoleons
Some pictures from the group meeting yesterday.
ELOG V3.1.3-