I've setup the GC650 camera (ID 32223) to look at the mode cleaner transmission. I've also added an alias to the camera server and client for this camera.
To use, type: "pserv1 &"on the machine you want to run the server on and "pcam1 &" on the machine you want to actually view the video. At the moment, this only works for the 64-bit Centos 5 machines, Rosalba, Allegra and Ottavia.
Note, you will generally want to start the client first (pcam1 or pcam2) to see if a server is already running somewhere. The server will complain that it can't connect to a camera if it already is in use.
I've setup the GC750 camera (ID 44026) to look at the the right most analog quad TV. This can be run by using "pserv2 &" and "pcam2 &".
If the image stops playing you can try starting and stoping the server to see if will start back up.
You can also try increasing or decreasing the exposure, to see if that helps. The increase and decrease buttons change the exposure by a factor of 2 for each press.
Lastly, the button "Read Epic Channel" reads in the current value from the channel: "C1:PEM-stacis_EEEX_geo" and uses it as the exposure value, in microseconds (in principle 10 to 1000000 should work).
For example, to exposre for 10000 microseconds, use "ezcawrite C1:PEM-stacis_EEEX_geo 10000" and press the "Read Epic Channel" button.
Osamu and Kiwamu received 40m safety training on Thursday, Feb 19, 2009
Comparing PSL-FSS-RMTEMP and PEM-MC1-TEMPS
So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.
MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf
Change the room temperature, see what happens to the chamber temperature
A while ago, somebody was fiddling around with the room temperature. See compare_temperature_channels_zoom4.pdf. This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.
Calibration equation for PEM-MC1-TEMPS
For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:
How does the chamber temperature compare with the air temperature?
It looks like the chamber may be warmer than the air around it sometimes.
I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.
When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.
Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.
New temp-sensor power supply vs old temp-sensor power supply
The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.
I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV --> apprx +/-0.03degF). So, it's less noisy.
I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.
Just for kicks
Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at 918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf.
I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!
The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)
Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.
While continuing our efforts to lock, we noticed the procedure failed at a point it had gotten past last night: turning on the bounce/roll filters in MICH, PRC, and SRC. We checked the MICH transfer function and noticed that the unity gain point was ~10 Hz, well below the bounce modes. We tried increasing the gain but found saturation, and Rob suggested that there could be misalignment on the AP table, which Steve worked on today. We went out and found two of the PDs (ASDD133 and AS166) to be badly misaligned probably due to a bumped optic upstream. We re-aligned.
I checked a broken QPD, which was placed for PSL angle monitor, and finally I cocluded one segment of the quadrant diode was broken.
The broken segment has a offset voltage of -0.7V after 1st I-V amplifier. It means the diode segment has a current offset without any injection of light.
Tomorrow I will check a new QPD for replacement.
The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!
The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.
Come forward now with your confession and I promise that I won't let Steve hurt you.
We centerd the input of WFS QPD.
c1susvme1 is behaving weirdly. I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking. I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it. It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable.
I have been getting ready for the annual safety inspection in the past 2-3 days.
I added a PA current limiter.
It is only a voltage devider (composed with 3.09k and 1.02k resiste) between DAC and PA current adjustment input.
The output range of DAC is +/- 10[V] and the conversion factor of PA current adjustment is 0.84[A/V] (measured value), so the PA current adjustment is limited +/- 2.1[A] ( 10[V]*1.02k/(1.02k+3.09k)*0.84[A/V] ).
Actually, the manual of the PA tells that the conversion factor is 0.25[A/V].
There is 3 possibility.
1) There are some mistakes in channels of digital system.
2) The PA manual is wrong.
2-1) The conversion factor of current adjustment is wrong.
2-2) The conversion factor of current monitor is wrong.
I measured the signal of current adjustment and current monitor directly, and confirm that they are consistent to the value monitord from MEDM.
Hence the PA manual must be wrong, but I don't know which factor is wrong (or both?).
If the suspect 2-2) is guilty, it means we adjust PA current with very small range.
This is a completly safety way, but a wast of resource.
Now, the slider to control current adjustment indicate the output of DAC.
I will improve this to indicate current adjustment input, but it takes some time for me to learn about EPICS.
So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11. So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.
During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table. It seemed like a temperature sensor.
The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.
Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.
So, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?
After the ISS work, I aligned the IFO and confirmed that DRMI locks with good SPOB and AS166 values.