| ID |
Date |
Author |
Type |
Category |
Subject |
|
17424
|
Thu Jan 26 00:18:54 2023 |
Koji | Update | Cameras | Recording CCD cameras |
Connect any video signal supported by the adapter. Use Windows / Mac or any other OS. If it keeps complaining, contact Magwell support. |
|
16802
|
Fri Apr 22 07:01:58 2022 |
Jc | Update | Coil Drivers | Adding Resistors and Reinstalling |
[Koji, JC]
Coil Drivers LO2, SR2, AS4, and AS1 have been updated a reinstalled into the system.
LO2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100008
LO2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100530
SR2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100614
SR2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100615
AS1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100610
AS1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100611
AS4 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100612
AS4 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100613 |
| Attachment 1: IMG_0536.jpeg
|
|
| Attachment 2: IMG_0539.jpeg
|
|
| Attachment 3: IMG_0542.jpeg
|
|
| Attachment 4: IMG_0545.jpeg
|
|
| Attachment 5: IMG_0548.jpeg
|
|
| Attachment 6: IMG_0551.jpeg
|
|
| Attachment 7: IMG_0554.jpeg
|
|
| Attachment 8: IMG_0557.jpeg
|
|
|
16804
|
Fri Apr 22 12:09:51 2022 |
Anchal | Update | Coil Drivers | Please update DCC pages |
Nice. Please put this information on the DCC pages of the coil driver units. You'll find links to all the units in this document tree LIGO-E2100447. For each page, click on "Change Metadata" from the left panel and add the change made to the resistor (including the resistor name on PCB, previous and new value), and add a link to your previous elog post which has more details like photos, to "Notes and Changes", and upload an updated version of the circuit schematic by creating an annotation in the previous circuit schematic pdf. Every unit that has a serial number in the lab has a DCC page (if not, we should create one) where we should track all such hard changes.
|
|
16814
|
Wed Apr 27 10:05:55 2022 |
JC | Update | Coil Drivers | Coil Drivers Update |
18 (9 pairs) Coil Drivers have been modified. Namely ETMX/ITMX/ITMY/BS/PRM/SRM/MC1/MC2/MC3.
ETMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100624 ETMX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100631
ITMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100620 IMTX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100633
ITMY Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100623 ITMY Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100632
BS Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100625 BS Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100649
PRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100627 PRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100650
SRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100626 SRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100648
MC1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100628 MC1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100651
MC2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100629 MC2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100652
MC3 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100630 MC3 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100653
Will be updating this linking each coil driver to the DCC |
|
16823
|
Mon May 2 13:30:52 2022 |
JC | Update | Coil Drivers | Coil Drivers Update |
The DCC has been updated, along with the modified schematic. Links have been attached.
| Quote: |
|
18 (9 pairs) Coil Drivers have been modified. Namely ETMX/ITMX/ITMY/BS/PRM/SRM/MC1/MC2/MC3.
ETMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100624 ETMX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100631
ITMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100620 IMTX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100633
ITMY Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100623 ITMY Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100632
BS Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100625 BS Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100649
PRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100627 PRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100650
SRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100626 SRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100648
MC1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100628 MC1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100651
MC2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100629 MC2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100652
MC3 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100630 MC3 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100653
Will be updating this linking each coil driver to the DCC
|
|
|
138
|
Thu Nov 29 10:36:47 2007 |
alberto | Configuration | Computer Scripts / Programs | Agilent 82357B GPIB to USB Interface Installation Procedeure |
To run the Agilent Automation-Ready CD provided with the interface is only the first step of the installation. Apparently there should be also a second CD with the drivers for Windows XP but I couldn't find it. So, after Installaing the IO Libraries Suite from the CD, I had to install the drivers with an executable downloaded from the Agilent's website at:
http://www.home.agilent.com/agilent/editorial.jspx?cc=US&lc=eng&ckey=1188958&nid=-35199.0.00&id=1188958
and only then I could plug in the interface.
Anyway, I burned a cd with the file and put it together with the other one. |
|
142
|
Thu Nov 29 18:10:13 2007 |
Alberto | HowTo | Computer Scripts / Programs | GPIB Scripts |
I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems. |
|
143
|
Thu Nov 29 19:35:14 2007 |
rana | HowTo | Computer Scripts / Programs | GPIB Scripts |
| Quote: | I've spent a lot of time trying to configurate the GPIB-USB interface for the HP4195. After installing 1) the Agilent libraries, 2) the drivers, 3) the matlab Instrument Toolbox, 4) Jamie script, 5) Alice's script the computer can see the HP but still they can't 'talk' to each other.
I give up. I asked Alice Wang how she managed to get data. I'm not sure she used the GPIB interace. Rob said she might have used the old fashion floppy disks that we can't read anymore here.
I would really appreciate any suggestion by anyone who happened to have the same problems. |
Alice and Jamie used the USB-GPIB interface. You should just try using the black laptop which already has this capability or ask Jamie Rollins
who actually knows something. |
|
157
|
Mon Dec 3 00:10:42 2007 |
rana | DAQ | Computer Scripts / Programs | linemon |
I've started up one of our first Matlab based DMT processes as a test.
There's a matlab script running on Mafalda which is measuring the height of the 60 Hz peak
in the MC1 UL SENSOR and writing it to an unused EPICS channel (PZT1_PIT_OFFSET).
The purpose of this is just to see if such a thing is stable over long periods of time. Its
open on a terminal on linux3 so it can be killed at any time if it runs amok.
Right now the code just demods the channel and tracks the absolute value of the peak. The
next upgrade will have it track the actual frequency once per minute and then report that
as well. We also have to figure out how to make it a binary and then make a single script
that launches all of the binaries.
For now you can watch its progress on the StripTool on op540m; its cheap and easy DMT viewer. |
|
159
|
Mon Dec 3 17:55:39 2007 |
tobin | HowTo | Computer Scripts / Programs | linemon |
| Matlab's Signal Processing toolbox has a set of algorithms for identifying sinusoids in data. Some of them (e.g., rootmusic) take the number of sinusoids to find as an argument and return the "most probable N frequencies." These could be useful in line monitoring. |
|
160
|
Mon Dec 3 19:06:49 2007 |
rana | DAQ | Computer Scripts / Programs | linemon |
I turned up my nose at Matlab's special tools. I modified the linetracker to use the
relationship phase = 2*pi*f*t to estimate the frequency each minute. The
code uses 'polyfit' to get the mean and trend of the unwrapped phase and then determines
how far the initial frequency estimate was off. It then uses the updated number as the
initial guess for the next minute.
I looked at a couple hours of data before letting it run. It looks like the phase of the
'60 Hz' peak varies at 20 second time scales but not much faster or rather anything faster
would be a glitch and not a monotonic frequency drift.
From the attached snapshot you can see that the amplitude (PZT1_PIT) varies by ~10 %
and the frequency by ~40 mHz in a couple hour span. |
| Attachment 1: spd64d1.jpg
|
|
|
166
|
Wed Dec 5 16:57:36 2007 |
tobin | HowTo | Computer Scripts / Programs | SR785 data converter on linux |
| I was pleased to find that the SR785 Data Viewer (including the command line conversion utility) installs and works in linux using WINE (on my laptop at least). There are some quirks, of course, but I was able to extract my data. |
|
175
|
Thu Dec 6 18:11:15 2007 |
rob | HowTo | Computer Scripts / Programs | Making DMF monitors |
I was able to use the matlab compiler to compile a version of the linetracker written by Rana, and run the compiled version on mafalda.
I believe I made the necessary edits to our mDV config file so that it should be easy for others to follow these steps:
1) Write the DMF routine you want, as a matlab function (not a script).
2) If it runs correctly in matlab, then from the matlab command line compile
it using the -m flag (i.e., mcc -m myfun.m). You should run the
compiler from the directory where you want the executable to end up (don't use the mDV/extra
directory so it doesn't get all cluttered).
3) prior to running the resulting executable (which should be called simply myfun),
prepend the directories
/cvs/cds/caltech/apps/linux/matlab/bin/glnx86
/cvs/cds/caltech/apps/linux/matlab/sys/os/glnx86/
to the LD_LIBRARY_PATH enviroment variable. These directories must be prepended as the
versions that already exist in /usr/lib don't work; I'm loathe to do this in the cshrc.40m
for fear of later conflicts, so it will need to be done in some sort of shell script which
calls the matlab executable.
|
|
180
|
Fri Dec 7 14:14:48 2007 |
rob | Metaphysics | Computer Scripts / Programs | tdsread problems on Solaris |
tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.
This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls. |
|
181
|
Fri Dec 7 18:28:30 2007 |
tobin | Update | Computer Scripts / Programs | compiled matlab hoses itself |
Andrey pointed out to me that some matlab functions in the Signal Processing Toolbox were dying with errors. Looking into the .m file (identified using the "which" command), I was surprised to see binary garbage rather than glistening, clear Matlab prose. Then I noticed the directory in which it was finding the .m file:
>> which decimate
/cvs/cds/caltech/apps/mDV/extra/linetrack_c_mcr/toolbox/signal/signal/decimate.m See that "linetrack_c_mcr" directory? This is what is generated when a "compiled" (grumble) Matlab program is run--it decompresses itself into a subdirectory containing weird semi-compiled binary .m files. Unfortunately this is somehow getting incorporated into the matlab path. (I assume there is something in mDV that says "put all subdirectories into the path.")
I hate the Matlab compiler. |
|
182
|
Fri Dec 7 18:31:30 2007 |
tobin | Update | Computer Scripts / Programs | compiled matlab hoses itself |
Addendnum. The reason the linemon_mcr command was in the path was because of the user issuing the command "addpath(genpath(pwd))" where genpath(D) "returns a path string starting in D, plus, recursively, all the subdirectories of D."
The Matlab compiler is still bad, however. |
|
184
|
Mon Dec 10 13:54:26 2007 |
rob | HowTo | Computer Scripts / Programs | Don't blame the Matlab compiler |
For human error. We should be careful to only run the compiler outside the mDV directory (thus placing the _mcr outside of the range the addpath command in the mdv_config files). Or maybe there's a smarter solution... |
|
187
|
Mon Dec 10 20:35:59 2007 |
tobin | Configuration | Computer Scripts / Programs | autolocking scripts |
I added this tidbit of csh code to the MZ autolocker to prevent multiple copies from running (on one computer):
if (`pgrep lockMZ | wc -l` > 1) then
echo lockMZ is already running!
exit
endif Similarly, here's some bash code that does something similar; I'll add it to the other autolocker scripts:
if
pgrep `basename $0` | grep -v $$ > /dev/null
then
echo Another copy of this program is already running. Exiting!
exit 1
fi This code searches for all processes with the same name as this script ($0) and then use grep to exclude (-v) the current process ID ($$). |
|
191
|
Thu Dec 13 23:56:02 2007 |
Andrey | Configuration | Computer Scripts / Programs | Overnight measurements |
After my disease (fever, vomitting, nose problem, overall weakness) I returned to LIGO today for the first time after the weekend, and I am running the script for the XARM-measurements over this night.
So, suspension dumping gains should undergo changes in the interval from 1 to 10 in both ITMX and ETMX.
XARM has been of course locked.
I started running the script for the first time at about 10PM, but I realized after an hour and a half that my step of gain increase 0.2 was too shallow, too small to execute my program during one night. Therefore, I needed to terminate the program, change my program so that it increases the gain with increment 0.5, not 0.2, and started it again around midnight.
Going home.
P.S. The red pump that I borrowed from the lab (Steve's pump?) is back at its previous place. The tire-worker tells me that I absolutely need to change all four tires for almost 500 dollars. I regret a lot about that huge money loss. |
|
194
|
Mon Dec 17 23:42:08 2007 |
Andrey | Configuration | Computer Scripts / Programs | Overnight measurements in X-arm |
I am making overnight measurements this night (from Monday to Tuesday) in XARM.
The X-arm is now locked, and the values for suspension damping gain will be changed in the interval from 1 to 7 with the step 0.5 in both ITMX and ETMX.
This is the second, repeated measurement. The results of the first measurement from Saturday to Sunday night will be reported in the separate ELOG entry (sorry, I did not make an ELOG entry on Saturday evening about running the program overnight).
The very first attempt to run the script in the night from Thursday to Friday was not successful. |
|
195
|
Tue Dec 18 00:51:39 2007 |
Andrey | Update | Computer Scripts / Programs | Results of Saturday overnight measurements |
As I indicated in the previous e-log entry (#194), I made overnight measurements in XARM in the night from Saturday to Sunday.
Root-mean-square values of the peaks in calibrated spectra were calculated, and I plotted them as functions of suspension gains in ITMX and ETMX "position" degrees of freedom.
More specifically, Q_ITMX means the value in the channel "C1:SUS-ITMX_SUSPOS_GAIN", while Q_ETMX means the value in the channel "C1:SUS-ETMX_SUSPOS_GAIN".
Root-mean-square values (RMS) were calculated during that night in three intervals:
1) around 0.8 HZ in the interval (0.6 Hz <-> 1.0 Hz);
2) around 3.0 Hz in the interval (2.0 Hz <-> 3.6 Hz);
3) in the broad interval from 0.6Hz to 3.6Hz.
I plotted three results for RMS in the abovementioned three intervals in three different ways:
1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);
2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);
3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9), above accelerometer spectra (attachments 10-11).
Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 12AM and 3AM, 12AM and 6AM, 12AM and 9AM) are given below, see attachments 10-11.
Tomorrow I will try to compare the results with the second measurements that are being taken tonight. |
| Attachment 1: RMS_08Hz_top_view.png
|
|
| Attachment 2: RMS_3Hz_top_view.png
|
|
| Attachment 3: RMS_broad_top_view.png
|
|
| Attachment 4: RMS_08Hz_Qsum-Qdiff-axes.png
|
|
| Attachment 5: RMS_3Hz_Qsum-Qdiff-axes.png
|
|
| Attachment 6: RMS_broad_Qsum-Qdiff-axes.png
|
|
| Attachment 7: RMS_08Hz_Qaxes.png
|
|
| Attachment 8: RMS_3Hz_Qaxes.png
|
|
| Attachment 9: RMS_broad_Qaxes.png
|
|
| Attachment 10: Accel_ITMX.png
|
|
| Attachment 11: Accel_ETMX.png
|
|
|
198
|
Tue Dec 18 23:27:36 2007 |
Andrey | Configuration | Computer Scripts / Programs | New overnight measurements (this night from Tue to Wed) |
I am making overnight measurements in XARM tonight.
This is the third night of measurements in XARM, but tonight I am scanning the narrower region between values of damping gain 1.00 and 4.50 with the smaller step 0.25. (for comparison, during two previous measurements the region was between 1.0 and 7.0 with the step 0.5).
I have relocked the XARM before the start of the measurements.
I started running the program at 9.30PM, and it should collect all the data by 9.00AM wednesday morning.
Below are explanations why I chose these different parameters for the interval and step:
I am going to put the results of previous night measurements into the next ELOG entry, and it we be pretty obvious from those graphs that results in XARM from the two previous (different) nights agree well with each other, and the approximate positions of minima and areas of "big growth" of the surfaces are pretty obvious from those graphs. It is clear that RMS are too big for the values of the damping gain bigger than 4.0, and that minima are somewhere near the values of 2.0. But those graphs were too rough to locate a somewhat precise value for the minima. Therefore, I am studying tonight the interval of gains between 1.00 and 4.50 with a smaller step.
A short note how I estimate time that is necessary to collect the experimental data.
there are 15 experimental points for each ETMX and ITMX suspension gains in the interval between 1.00 and 4.50 with the step 0.25. They are: 1.00, 1.25, 1.50, 1.75, 2.00, ..., 3.75, 4.00, 4.25, 4.50. As I am changing both ETMX and ITMX gains, I have an array of 15*15=225 elements.
It takes 3 minutes for each point to collect the data (I wrote the program that way). Therefore, the total time it takes to run the program is: 225*3=675 minutes, or 675/60=11.25 hours, almost 11 and a half hours. |
|
199
|
Tue Dec 18 23:41:00 2007 |
Andrey | Summary | Computer Scripts / Programs | Results of Mon/Tue overnight measurements (entry #194) |
Here I inform our community about the results of the measurements of RMS values in XARM during the previous night from Monday to Tuesday (I announced those measurements in ELOG entry #194).
All the plots in today's report seem to agree well with the analogous plots from the night from Saturday to Sunday (those results are given in ELOG entry # 195).
All the intervals in which RMS have been calculated are the same as in yesterday's ELOG entry #195.
I plotted three results for RMS in the abovementioned three intervals in three different ways:
1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);
2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);
3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9, also attch. 12), above accelerometer spectra (attachments 10-11).
Also, I compared the ground noise level by comparing spectra of accelerometer signals at different times during that night. As a reminder, before my disease I installed one accelerometer near ITMX and another accelerometer near ETMX (see entries 161 and 172 in ELOG). The plots of ratios of accelerometer signals at different times (pairs of times that were used: 11PM and 2AM, 11PM and 5AM, 11PM and 8AM) are given below, see attachments 10-11. The program was running from 11PM on Monday till 9AM on Tuesday.
As I explained in the previous ELOG entry # 198, tonight I am taking experimental data in the narrowere interval from 1.00 to 4.50 with a smaller step 0.25. |
| Attachment 1: RMS_08HZ_Top_View.png
|
|
| Attachment 2: RMS_3HZ_Top_View.png
|
|
| Attachment 3: RMS_broad_Top_View.png
|
|
| Attachment 4: RMS_08HZ_Side_View.png
|
|
| Attachment 5: RMS_3HZ_Side_View.png
|
|
| Attachment 6: RMS_broad_Side_View.png
|
|
| Attachment 7: RMS_08HZ_Q_E_Q_I_Axes.png
|
|
| Attachment 8: RMS_3HZ_Q_E_Q_I_Axes.png
|
|
| Attachment 9: RMS_broad_Q_E_Q_I_Axes.png
|
|
| Attachment 10: Accelerometer_ITMX.png
|
|
| Attachment 11: Accelerometer_ETMX.png
|
|
| Attachment 12: RMS_broad_Q_E_Q_I_Axes.png
|
|
|
201
|
Wed Dec 19 15:51:00 2007 |
Andrey | Update | Computer Scripts / Programs | Daytime measurements in XARM and their results |
I was making measurements in XARM for three different nights. All the results agree with each other (I will put the results from the last night soon).
Steve Vass recommended to me to compare those results with the daytime data, in order to see if there is a real necessity to run the scripts overnight or if daytime results will yield similar results.
XARM has been locked, and I am taking measurements today from 3.30PM till 11.30PM.
I will be changing the suspension damping gains in ETMX and ITMX "position" degrees of freedom in the interval from 1.0 to 3.75 with the step 0.25.
BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY, DEC. 20.
All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation. |
| Attachment 1: RMS-08Hz-Top_View.png
|
|
| Attachment 2: RMS-3Hz-Top_View.png
|
|
| Attachment 3: RMS-broadband-Top_View.png
|
|
| Attachment 4: RMS-08Hz-Side-View.png
|
|
| Attachment 5: RMS-3Hz-Side_View.png
|
|
| Attachment 6: RMS-broadband-Side_View.png
|
|
| Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png
|
|
| Attachment 8: RMS-3Hz-Side_View.png
|
|
| Attachment 9: RMS-broadband-Side_View.png
|
|
| Attachment 10: Accelerometer_ETMX.png
|
|
| Attachment 11: Accelerometer_ITMX.png
|
|
|
202
|
Wed Dec 19 16:07:37 2007 |
Andrey | Summary | Computer Scripts / Programs | Results of overnight measurements Tue/Wed night (entry #198) |
As indicated in ELOG entry 198, I was making overnight measurements during last night from Tuesday to Wednesday.
I was changing the suspension damping gain in ETMX and ITMX in "position" degree of freedom between values of 1.00 and 4.50 with the step 0.25.
Results for RMS of peaks (A) at 0.8Hz, (B) at about 3.0Hz and (C) in the range from 0.6Hz to 3.7Hz ("RMS in a broad interval") are given below:
I plotted three results for RMS in the abovementioned three intervals in three different ways:
1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);
2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);
3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9)
Attachments 10 and 11 show ratios of accelerometer signals at different times of the night/morning.
A little discussion about these graphs:
1) The areas of minima and of rapid growth are the same for all the measurements during all three nights.
2) Tonight there was a strange spike for the values of Q_{ETMX}=2.5 and Q_{ITMX}=4.0. I interpret that as an error of experiment.
3) On all the plots from all three nights there is a wide area of minimum on the plots for RMS at 0.8Hz and for "RMS in the broad interval",
and the graph for "RMS at 3Hz" indicates a clearer minimum in a localized area for Q_{ITMX}=2+-1, Q_{ETMX}=2+-1. Note that this area 2+-1
is included into the wide region of minimum for "RMS at 0.8Hz" and "RMS in a broad range".
Therefore, my guess at this stage is that we can choose the optimized value of suspension damping gains for both Q_{ITMX} and Q_{ETMX} somewhere
around 2+-1. I would like to make another overnight measurement (tonight) in that narrowed region with a small step to have more certainty.
By the way, I realized that I was a little bit careless and at some plots Q_I stands for {Q_ITMX}, and Q_E stands for Q_{ETMX}.
|
| Attachment 1: RMS_08Hz_Top_view.png
|
|
| Attachment 2: RMS_3Hz_Top_view.png
|
|
| Attachment 3: RMS_broad_Top_view.png
|
|
| Attachment 4: RMS_08Hz_Side_view.png
|
|
| Attachment 5: RMS_3Hz_Side_view.png
|
|
| Attachment 6: RMS_broadband_Side_view.png
|
|
| Attachment 7: RMS_08Hz_Q_I-Q_E-axes.png
|
|
| Attachment 8: RMS_3Hz_Q_I-Q_E-axes.png
|
|
| Attachment 9: RMS_broadband_Q_I-Q_E-axes.png
|
|
| Attachment 10: Accelerom_ETMX.png
|
|
| Attachment 11: Accelerom_ITMX.png
|
|
|
205
|
Thu Dec 20 02:04:09 2007 |
Andrey | Update | Computer Scripts / Programs | New overnight measurements in XARM and their results |
I ran in the daytime/evening time my program, changing the damping gains in suspension "position" degree of freedom for ETMX and ITMX
in the interval from 1.00 to 3.75 with the step 0.25 (see entry # 201).
Now I am running overnight (from 2AM till 9AM) the program changing the gains in the interval from 1.3 to 3.5 with the step 0.20,
12 X 12 = 144 experimental points. I started so late because I fell asleep after my Wednesday evening dinner, then woke up half an hour ago and hurried to the lab.
BELOW: RESULTS OF MEASUREMENTS WERE ADDED ON THURSDAY EVENING, DEC. 20.
All the meaning of the attachments 1-3, 4-6, 7-9, 10-11 is the same as in previous ELOG entries # 195, # 199, # 202, see in those entries which graph corresponds to which coordinate axes orientation. |
| Attachment 1: RMS-08Hz-Top-View.png
|
|
| Attachment 2: RMS-3Hz-Top-View.png
|
|
| Attachment 3: RMS-broadband-Top-View.png
|
|
| Attachment 4: RMS-08Hz-Side_View.png
|
|
| Attachment 5: RMS-3Hz-Side_View.png
|
|
| Attachment 6: RMS-broadband-Side_View.png
|
|
| Attachment 7: RMS-08Hz-Q_I-Q_E-Axes.png
|
|
| Attachment 8: RMS-3Hz-Q_I-Q_E-Axes.png
|
|
| Attachment 9: RMS-broadband-Q_I-Q_E-Axes.png
|
|
| Attachment 10: Accelerometer-ETMX.png
|
|
| Attachment 11: Accelerometer-ITMX.png
|
|
|
208
|
Thu Dec 20 21:57:34 2007 |
Andrey | Update | Computer Scripts / Programs | Measurements in XARM today |
Today at 2PM I started a program, it should change the suspension gains in the interval from 1.0 to 3.8 with the step 0.2. Estimated running time is till 3.30AM coming night.
Results will be reported on Friday.
BELOW: ADDITION MADE ON FRIDAY EVENING.
Due to some unforeseen circumstances, I was unable to add results on Friday. I have so far accelerometer spectra only, which I add to this ELOG entry.
I have files with the measurement results, and I will process them after Christmas and add to this ELOG entry. I might not be in the lab on Dec. 24 and 25. |
| Attachment 1: Accelerom_ETMX.png
|
|
| Attachment 2: Accelerom_ITMX.png
|
|
|
209
|
Thu Dec 20 21:58:28 2007 |
Andrey | Summary | Computer Scripts / Programs | Results for 2 previous XARM measurements have been added |
I attached results (plots) of yesterday's daytime and overnight measurements to the initial reports about those measurements.
These are ELOG entries # 201 and # 205. |
|
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
|
|
|
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. |
|
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. |
|
311
|
Tue Feb 12 16:18:29 2008 |
rob | Configuration | Computer Scripts / Programs | autoburt cron moved to op340m |
I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.
There are no more cron jobs running on op440m now. |
|
338
|
Fri Feb 22 20:42:44 2008 |
Andrey | Summary | Computer Scripts / Programs | It seems I succeeded in theoretical simulations |
I am pretty happy at this moment.
I definitely feel that it took me too much time to understand how to do the Matlab program and how to overcome difficulties,
but eventually at last my Matlab program seems to start working.
Briefly: What the program does?
--> take time-domain signal from two accelerometers near ITMX and ETMX (use 'get_data');
--> calculate the time-evolution of those two signals through the system "stack + pendulum" to the test-masses ITMX and ETMS (use 'lsim' in Matlab),
which gives us the time-domain evolution of the deviation of the position of individual test-mass from its average position.
--> Subtract the two results from each other in time-domain, this gives us the deviation of the length of the XARM-cavity from its average value
(roughly speaking, deviation of the length of the cavity from exactly 40 meters, although I am aware that the exact average length of XARM is less than 40 meters).
--> Take the amplitude spectrum of the result, using Sqrt(pwelch) and calibrate it from "counts" to "meters".
--> Calculate root-mean-square of peaks at different frequency intervals, for example near 0.8Hz,
and plot the three-dimensional surface showing the dependence of RMS on Q-factors Q_{ETMX} and Q_{ITMX}.
Eventually I am able to create these dependences of RMS.
I see that the minimum of the dependence is close to the diagonal corresponding to exact equality of Q_ETMX} and Q_{ITMX}, but not exactly along the diagonal. The plot allows to say
which of two conditions "Q_I > Q_E" or "Q_E < Q_I" should be fullfilled for optimization reasons. My plot is raw, I might have made a mistake in axis-label, I do not garantee now that the axis label "Q_ITMX - Q_ETMX" is correct,
maybe I need to change it for "Q_ETMX - Q_ITMX". I need some more time to determine this on Monday, but clearly there is asymmetry between Q_I and Q_E.
The peak at 0.8 Hz is pretty stable, while the peak at around 3Hz is not very repeatable, therefore in both experimental measurements and these simulations the amplitude of RMS of peak at 3Hz) is several orders of magnitude smaller than for RMS of peak at 0.8Hz, and I do not see minimum somewhere in the RMS-dependence, I see now only steady growth of RMS as Q_factors increase.
I will need to spend some time on Monday trying to understand how the sampling frequency and number of fft-points influence my results when I take amplitude spectrum using pwelch-command, as well I will need to double-check the correctness of normalization from counts to meters (I am not confident right now that amplitude of order of 10^(-12) meters is correct).
So, I need some time after the weekend to analyze my results and maybe make some slight changes, but I am glad that my Matlab model started to work in principle. I wanted to let others know about the status of the progress in my work. The fact that Matlab program works now is a good ending of a week.
Andrey. |
| Attachment 1: RMS_peak_08Hz-Theoretical.png
|
|
| Attachment 2: RMS_peak_08Hz-QI-QE.png
|
|
| Attachment 3: RMS_peak_3Hz-Theoretical.png
|
|
| Attachment 4: RMS_peak_broad-interv-Theoretical.png
|
|
|
339
|
Fri Feb 22 21:19:38 2008 |
Andrey | Bureaucracy | Computer Scripts / Programs | MDV library does not work at "LINUX 2" |
While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".
Andrey. |
|
343
|
Thu Feb 28 12:31:33 2008 |
rob | Bureaucracy | Computer Scripts / Programs | MDV library does not work at "LINUX 2" |
| Quote: |
While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".
Andrey. |
This turned out to be due to /frames not being mounted on linux2, as a result of a reboot. The issue is discussed in entry 270. I remounted the /frames, and added a line to mdv_config.m to check whether the frames are mounted. |
|
359
|
Wed Mar 5 12:35:09 2008 |
John | Summary | Computer Scripts / Programs | Plot photodiode responses in MatLab |
A matlab function to plot the responses of photodiodes. There's still plenty of room for improvement but it should work for all our diodes without any changes. You may want to adjust which points are used in the fit to remove time delay.
% Plot data from diode response measurements
function out = diodeplot(f_Hz,mag_dB,phase_deg,f_beat_MHz)
% $$$ clear all
% $$$ close all
% $$$ clc
% $$$
% $$$
% $$$ mag = dlmread('D:\40m\PD6\M7.txt','\t', 15, 0);
% $$$ phase = dlmread('D:\40m\PD6\P7.txt','\t', 15, 0);
% $$$
% $$$ % Frequency i.e. x-axis
% $$$ f = mag(:,1);
% $$$
% $$$ % Magnitude in dB
% $$$ mag_dB = mag(:,2);
% $$$
% $$$ % Phase in degrees
% $$$ phase_deg = phase(:,2);
% $$$
% $$$ % Frequencies of interest
% $$$ f_beat_MHz = [33 133 166 199]*1e6;
% $$$
% $$$ diodeplot(f, mag_dB, phase_deg, f_beat_MHz)
% x axis limits
xmin = 10e6;
xmax = 500e6;
% Unwrap phase
phase_deg = (180/pi)*unwrap((pi/180)*phase_deg);
%Find values at our freqeuncies of interest
Mag_f_beat = interp1(f_Hz,mag_dB,f_beat_MHz);
% Remove the time delay from the phase data
% (May want to adjust which points are selected here)
straight = @(a, x) a(1) * x + a(2);
xdata = f_Hz;
ydata = phase_deg;
aguess = [10 0.1];
a = lsqcurvefit(straight,aguess,xdata,ydata);
fit = straight(a,xdata);
phase_deg = phase_deg-fit;
figure(1)
ha = axes('units','normalized','position',[0 0 1 1]);
uistack(ha,'bottom');
I=imread('PDbw.jpg');
hi = imagesc(I);
colormap gray
set(ha,'handlevisibility','off', ...
'visible','off')
plot(xdata,ydata,'r')
hold on
plot(xdata,fit,'k')
plot(xdata,phase_deg,'b')
hold off
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',12)
title('Removing the time delay','FontSize',16)
legend('data','fit','data-fit',0)
set(hi,'alphadata',.35)
set(gca,'Color','None')
box off
figure(2)
set(gcf,'Color', [1 1 1])
subplot(4,1,[1 3])
semilogx(f_Hz,mag_dB,'k','LineWidth',2.5)
title('Response of PD6','FontSize',16)
ylabel('Magnitude/ dB', 'FontSize',12)
xlim([xmin xmax])
grid
MagLayout = get(gca, 'Position');
YLimits = get(gca, 'YLim') ;
LabelExt = [];
for ivar = 1:length(f_beat_MHz);
a = text(f_beat_MHz(ivar),1.05 * min(Mag_f_beat),...
sprintf('%2.1fdB @ %dMHz', Mag_f_beat(ivar),f_beat_MHz(ivar)/1e6),...
'FontSize',10,'FontWeight','Bold','HorizontalAlignment','right',...
'VerticalAlignment','top','BackgroundColor',[.7 .9 .7],...
'Margin',0.5, 'Rotation',90);
LabelExt = [LabelExt; get(a,'Extent')];
LabelPos = get(a,'Position');
end
% Change YLim so that it is around the bottom of the labels
% There must be a better way
set(gca, 'YLim', [min(LabelExt(:,2)) YLimits(2)])
% Remove the last tick mark so that it doesn't overlap with the
% +180 of the phase plot
YTickLabelNew = str2num(get(gca, 'YTickLabel'));
YTickNew =[[] YTickLabelNew(2:end) ];
set(gca,'XTickLabel', [], 'YTick', YTickNew)
% Add lines now we know what the YLims are
for ivar = 1:length(f_beat_MHz);
line([f_beat_MHz(ivar) f_beat_MHz(ivar)], get(gca, 'YLim'))
end
subplot(4,1,4)
semilogx(f_Hz,phase_deg,'r','LineWidth',2.5)
xlim([xmin xmax])
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',16)
grid
PhaseLayout = get(gca, 'Position');
PhaseLayout(4) = MagLayout(2)-PhaseLayout(2);
% Make the top of the phase plot align to the bottom of the
% magnitude plot
set(gca, 'Color', 'None', 'Position',PhaseLayout, 'YTick',[-180:45: ...
180])
set(gcf,'units','normalized','outerposition',[0 0 1 1]); |
| Attachment 3: PDbw.jpg
|
|
|
375
|
Thu Mar 13 12:11:58 2008 |
aivanov | Update | Computer Scripts / Programs | routing PEM -> ASS -> SUS_MCL |
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
|
376
|
Thu Mar 13 13:15:09 2008 |
aivanov | Update | Computer Scripts / Programs | new sfotware intall, backup files |
New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o
Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08 |
|
380
|
Fri Mar 14 15:06:24 2008 |
rob | Update | Computer Scripts / Programs | routing PEM -> ASS -> SUS_MCL |
| Quote: |
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1. |
|
430
|
Sun Apr 20 20:29:46 2008 |
rana | Update | Computer Scripts / Programs | tdsread bugs |
There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob.
I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.
I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.
My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS> |
|
433
|
Mon Apr 21 13:12:21 2008 |
rob | Update | Computer Scripts / Programs | tdsread bugs |
| Quote: | There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob.
I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.
I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.
My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS> |
This is the same bug described in entry 180. I believe it has nothing to do with tdsread, which did not change in the time period before the bug appeared, but perhaps has something to do with other EPICS libraries somewhere (tdsread relies on these epics libraries to do its dirty work). Here is entry 180 for reference:
| Quote: | tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.
This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls. |
The solution that's been in effect for the past few months has just been to modify the scripts to not make these kinds of calls. |
|
440
|
Wed Apr 23 22:39:54 2008 |
Andrey | DAQ | Computer Scripts / Programs | Problem with "get_data" and slow PEM channels |
It turns out that I cannot read minute trends for the slow weather channels for more than 1000 seconds back (roughly more than 15 minutes ago) using "get_data" script.
For comparison, I tried MC1 slow channels, and similar problem did not arise there. Probably, something is wrong with the memory of slow weather channels. At the same time, I can see minute-trends in Dataviewer as long ago as I want.
In response to
>>get_data('C1: PEM-weather_outsideTemp', 'minute', gps('now') - 3690, 3600);
I get the error message:
"Warning: Missong C1: PEM-weather_outsideTemp M data at 893045156". |
|
441
|
Thu Apr 24 11:50:10 2008 |
josephb | Summary | Computer Scripts / Programs | Useful tidbits learned while tracking the network setup |
In process of understanding the network setup I've learned several things:
1) The status lights on C0DAQ_RFMNETWORK.adl are controlled by the fiber network, as opposed to the ethernet network. However, even if everything is working properly on the VME end, you may still need to reboot it in order to be able to contact it via the ethernet (ssh or telnet).
2) After disconnecting the hub out by 1Y9, I was able to telnet into c1vac1, but not c1vac2. I was told that the Turbo pump and Ion pump readbacks on C0VACMONITOR.adl had not been working for awhile (years?). So I went out and rebooted the c1vac2 card. This seemed to restore the epic channels and we now have correct readbacks on the turbo pumps. The ion pumps all are reading no voltage, which is good because they're turned off. However C1:Vac-IPSE_mon is reading "On", although Steve assures me the actual unit is currently off, so there may be a minor channel issue there. |
|
458
|
Mon Apr 28 23:44:33 2008 |
Andrey | Update | Computer Scripts / Programs | Weather.db |
I was trying to figure out how to modify the file "Weather.db" so that the atm.pressure would be recalculated from Pa to bar before appearing in the EPICS screen, but so far I did not succeed. I restarted processor "c1pem1" several times. I will continue this tomorrow, and also I will modify the nmaes of the weather channels. |
|
484
|
Sun May 18 18:14:30 2008 |
rana | Summary | Computer Scripts / Programs | autlockers and cron |
Today I noticed that the MC was unlocked, the MC autolocker was off, the PSL autolocker was off,
and the PSL Slow loop was off.
Reading through .log files and our elog it seems like things have been this way since Tuesday
when Andrey went around rebooting computers to bring things back.
And it looks like the ETMY optical lever is dead.
I restarted the PSL & MC scripts on op340m. I also locked and aligned the X arm to verify that
not everything is broken. The Y Arm is unalignable until we replace the HeNe. |
|
490
|
Wed May 21 15:21:33 2008 |
rob | Update | Computer Scripts / Programs | autolockers and cron |
I added hourly cron jobs to op340m to ensure that
MC autolocker
FSS Slow Servo
PSL watch
are running. I've also edited the wiki procedure to reflect the fact that these no longer need to be restarted by hand. |
|
500
|
Tue May 27 16:24:54 2008 |
tobin | Configuration | Computer Scripts / Programs | ndsproxy |
The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.
I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.
So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?
The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
that directory. |
|
535
|
Mon Jun 16 18:26:01 2008 |
Max Jones | Update | Computer Scripts / Programs | Noise Budget Changes |
In the directory cvs/cds/caltech/NB the following changes were made:
I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m
In getmultichan.m I added a C1 case.
In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic
I appreciate and suggestions. Max.
|
|
542
|
Wed Jun 18 18:32:09 2008 |
Max Jones | Update | Computer Scripts / Programs | NB Update |
I am reconfiguring the the noisebudget code currently in use at the sights. To that end, I have done the following things (in addition to the elog I posted earlier)
In get_dtt_dataset.m - I added C1 specific cases for DARM_CTRL, SEIS, and ITMTRX changing the specific channels to make those in use at caltech
In LocalizeSite.m - I changed the NDS_PATH to match caltechs. I left NDS_HOST untouched.
Since I am trying to get SEIS and DARM to work initially I added C1 specific cases to both of these.
Better documentation may be found in /users/mjones/DailyProgressReport/06_18_08. Suggestions are appreciated. Max. |
|
565
|
Wed Jun 25 11:36:14 2008 |
Max Jones | Update | Computer Scripts / Programs | First Week Update |
For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is
1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.
2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.
Any suggestions are appreciated. Max. |
| Attachment 1: C1_NoiseBudgetPlot_Day.eps
|
|
| Attachment 2: C1_NoiseBudgetPlot_Night.eps
|
|