The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!
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.
I've updated the digital camera python code as well as changed the network topology.
At the moment, both cameras are connected to a small gigabit switch which only talks to Ottavia. This means all camera servers must be run on Ottavia, allow camera output is still UDP multicast so any machine capable of running gstreamer can pick up the images.
The server and client programs now have the ability to read a configuration file for the setup of the cameras. They default to pcameraSettings.ini, but this can default can be changed with a -c or --config option
For example, "serverV3.py --config pcam1.ini" will run the server using the pcam1.ini settings file. Similarly, "client.py --config pcam1.ini" will also take the IP settings from the config file so that it knows at which port and IP to listen.
These programs and .ini files have been placed in /cvs/cds/caltech/apps/linux64/python/pcamera/
I've updated the cshrc.40m aliases so that it uses the new configuration file options, so now pcam1 calls "client.py -c pcam1.ini" in the above directory.
So to start a client use pcam1 or pcam2 (for the 32223 camera in PSL looking at MC trans or 44026 looking at an analog moniter in the control room respectively). These can be run on Allegra, Rosalba or Ottavia at the moment.
To start a server, use pserv1 or pserv2. These *must* be run on Ottavia.
I've also added a -n or --no-gui option at Yoichi's request, one which just starts up and plays, with no graphical gui.
Lastly, I've made some changes to the base pcamerasrc.py file, which should make display more robust. After a failed transmission of an image from the camera to Ottavia, it should re-attempt up to 10 times before giving up. I'm hoping this will make it more robust against packet loss. The change in network topology has also helped this, allowing 640x480 to be transmitted on both cameras before tens of minutes before a packet loss causes a stop.
I modified the Video.db file used by c1aux located in /cvs/cds/caltech/target/c1aux.
I added the following channels to the db file, intended for either read in or read out by the digital camera scripts.
A better naming scheme can probably be devised, but these will do for now.
To use the Sensoray 2250 USB frame grabber:
Ensure you have the following packages installed: build-essential, libusb-dev
Download the Linux manual and linux SDK from the Sensoray website at:
Go to the Software and Manual tab near the bottom to find the links. The software can also be found on the 40m computers at /cvs/cds/caltech/users/josephb/sensoray/
The files are Manual2250LinuxV120.pdf and s2250_v120.tar.gz
Run the following commands in the directory where you have the files.
tar -xvf s2250_v120.tar.gz
sudo make modules_install
At this point plug in the 2250 frame grabber.
sudo modprobe s2250_ezloader
Now you can run the demo with
./sraydemo or ./sraydemo64
Options will show up on screen. A simple set to start with is "encode 0", which sets the recording type, "recvid test.mpg", which starts the recording in file test.mpg, and "stop", which stops recording. Note there is no on screen playback. One needs an installed mpeg player to view the saved file, such as Totem (which can screen cap to .png format) or mplayer.
All these instructions are on the first few pages of the Manual2250LinuxV120 pdf.
I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.
I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing. Basically I had all 404 Not Found errors.
Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008. So there's a couple things that can be done:
1) Ignore it, and simply not update Mafalda anymore. This also means some newer software and hardware simply won't work with it (like the usb frame grabber)
2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.
3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.
I'd personally lean towards the 3rd option, and go to the 8.04 long term support version. If people agree with it, I could do the upgrade sometime Monday or Tuesday.
I don't see a reason to proliferate operating systems. Is there any reason we actually need Ubuntu? Can we put CentOS on it?
At the request of people down at LLO I've been trying to work on the reliability and speed of the GigE camera code. In my testing, after several hours, the code would tend to lock up on the camera end. It was also reported at LLO after several minutes the camera display would slow down, but I haven't been able to replicate that problem.
I've recently added some additional error checking and have updated to a more recent SDK which seems to help. Attached are two plots of the frames per second of the code. In this case, the frames per second are measured as the time between calls to the C camera code for a new frame for gstreamer to encode and transmit. The data points in the first graph are actually the averaged time for sets of 1000 frames. The camera was sending 640x480 pixel frames, with an exposure time of 0.01 seconds. Since the FPS was mostly between 45 and 55, it is taking the code roughly 0.01 second to process, encode, and transmit a frame.
During the test, the memory usage by the server code was roughly 1% (or 40 megabytes out of 4 gigabytes) and 50% of a CPU (out a total of CPUs).
At Rob's request I've added the following features to the camera code.
The camera server, which can be started on Ottavia by just typing pserv1 (for camera 1) or pserv2 (for camera 2), now has the ability to save individual jpeg snap shots, as well as taking a jpeg image every X seconds, as defined by the user.
The first text box is for the file name (i.e. ./default.jpg will save the file to the local directory and call it default.jpg). If the camera is running (i.e. you've pressed start), prsessing "Take Snapshot to" will take an image immediately and save it. If the camera is not running, it will take an image as soon as you do start it.
If you press "Start image capture every X seconds", it will do exactly that. The file name is the same as for the first button, but it appends a time stamp to the end of the file.
There is also a viedo recording client now. This is access by typing "pcam1-mov" or "pcam2-mov". The text box is for setting the file name. It is currently using the open source Theora encoder and Ogg format (.ogm). Totem is capable of reading this format (and I also believe vlc). This can be run on any of the Linux machines.
The viewing client is still accessed by "pcam1" or "pcam2".
I'll try rolling out these updates to the sites on Monday.
The configuration files for camera 1 and camera 2 can be found by typing in camera (which is aliased to cd /cvs/cds/caltech/apps/linux64/python/pcamera) and are called pcam1.ini, pcam2.ini, etc.
This week, I've been reading some literature concerning PLL and familiarizing myself with LINUX, MATLAB, and high-pass filter circuits. In MATLAB, I started constructing matrices to be used for a beam path analysis from the laser output to the ccd camera. I also built a simple high-pass filter on a bread-board that Joe and I are currently testing with the spectrum analyzer.
This past week, I have building a sine wave rectifier and trying to write a simple program that displays a ccd image to familiarize myself with the code. I also wrote a progress report in which I included the following images of the sine wave rectifier circuit as well as the optical chain including the phase-locked loop. The hirose connector arrived so I can begin soldering the electronics together and testing the trigger box with the ccd. I am waiting on the universal PDH box as well as another fiber coupler to begin setting up the optics. In order to avoid the frustrations associated with sending a laser beam down a long pipe to an optical bench across the room, I will be transmitting laser 1 to the ccd by means of a fiber optic cable and dealing with the alternative new and exciting frustrations.
The plan for the optical setup has been corrected after it was realized that it would be impossible to isolate a 29.501 MHz frequency from a 29.499 MHz one because they are so close in value. Instead, we decided to adopt the setup pictured below. In this way, the low-pass filter should have no trouble isolating 29.501-29.5 MHz from 29.501 + 29.5 MHz. Also, we decided to scrap the idea of sending Alberto's laser through a fiber optic cable after hearing rumors of extra lasers. Since I shouldn't have to share a beam when the second laser comes in, I plan on setting up both lasers on the same optics bench. I've been working on the software while waiting for supplies, but I should be able to start building the trigger box today (assuming the four-pair cable is delivered).
Lately, I have been able to externally trigger the camera using a signal generator passing through the op-amp circuit that I built. The op-amp circuit stabilizes the jitter in the sine wave from the signal generator and rectifies the wave. I wrote the calculations into the code allowing me to find the phase and amplitude from the images I take. I still need to develop code that will plot these arrays of phase and amplitude.
The mysterious dark band at the top of the ccd images continues to defy explanation. However, I have found that it only appears for short exposure times even when the lens is completly covered. During the next couple of days, I will try to write a routine to correct for this structure in the dark field.
Koji recommended that we use the optical setup pictured below. This configuration would require fewer optics and we would have to rely on slight misalignments between the carrier and reference beams to test the effectiveness of the phase camera instead of a wavefront-deforming lens.
Koji recommended that we use the optical setup pictured below. Although it uses fewer optics, I can't think of a way to test the phase camera using this configuration because any modulation of the wavefront with a lens or whatever would be automatically corrected for in the PLL so I think I'll have to stick with the old configuration.
I talked with Zach. So this is just a note for the others.
The setup I suggested was totally equivalent with the setup proposed in the entry http://22.214.171.124:8080/40m/1721, except that the PLL PD sees not only 29.501MHz, but also 1kHz and 59.001MHz. These additional beating are excluded by the PD and the PLL servo. In any case the beating at 1kHz is present at the camera. So if you play with the beamsplitter alignment you will see not only the perfect Gaussian picture, but also distorted picture which is resulted by mismatching of the two wave fronts. That's the fun part!
The point is that you can get an equivalent type of the test with fewer optics and fewer efforts. Particularly, I guess the setup would not be the final goal. So, these features would be nice for you.
This past week, I have mostly been debugging my software. I have tried to use the fluorescent lights to test the camera, but I can't tell for sure if my code is finding the correct amplitude and phase or not. I am currently using Mathematica to double check my calculations in solving for the phase and amplitude.
Also, I have taken dark field images using a lens with a closed shutter. I have found that the dark band across the top of the images only appears after the camera heats up. Also, there is an average electronic noise of 14 with a maximum of 40. However, this electronic noise as well as any consistent ambient noise will be automatically corrected for in the calculations I'm using because I'm taking the differences between the CCD images to calculate relative phases and amplitudes.
I should be able to start setting up optics and performing better tests of my software this week.
This week, Joe and I have been setting up the laser and optics. The mephisto laser is emitting a very ugly beam that we can hopefully remedy using an iris and a lens. After scanning the beam width at a few different distances from the laser, I am currently trying to determine the appropriate lenses to use.
While aligning the optics, we tried to start up the CCD. Although nothing should have changed since the last time I used it, the code claimed it could not find the camera. All the right leds are lit up. The only indication that something is awry is that the yellow led on the camera isn't blinking as it does when there is ethernet activity.
The camera wasn't working because the router has no built-in dhcp server. We had to manually start the server after rebooting the computer.
Shown below are the plots of the amplitude and phase of the Mephisto laser light modulated with a chopper as a square wave at about 1 kHz. The color bar for the phase should run from -pi to pi, and it does when I don't accidently comment out the color bar function. Anyway, the phase is consistently pi/4 or pi/4 plus or minus pi. Usually all three of these phases occur within the same image, as shown below. Also, the amplitude is a factor of two or so higher than it should be where this phase jump occurs. I think these problems are associated with the nature of the square wave. However, there is a software bug that appears to be independent of the input data: there is a rounding error that causes the amplitude to jump to infinity at certain points. This happened for only a dozen or so pixels so I deleted them from the amplitude plot shown below. I am currently working on a more robust code that will use the Newton-Raphson method for nonlinear systems of equations.
The images that I just posted were taken with the CMOS camera. We switched from the CCD to the CMOS because the CCD was exhibiting much higher blooming effects. Unlike the CCD, there is a slight background structure if you look carefully in the amplitude image, but I can correct for this consistent background by taking a uniformly exposed image by placing a convex lens in front of the CMOS. I will then divide each frame taken of the laser wavefront by the background image.
The Chameleon HB (by Knox) video switch that we use for routing video signals into the control room monitors is broken. Well, either it's broken, or something is wrong with the mv162 EPICS IOC which communicates with it via RS-232. Multiple reboots/resets of both machines has not yet worked. The CHHB has two RS-232 inputs--I switched to the second one, and there is now one signal coming through to a monitor but no switching yet. I've been unable to further debug it because we don't have anything in the lab (other than the omega iserver formerly used for the RGA logger) which can communicate with RS-232 ports. I've been trying to get this thing (the iserver) working again, but can't communicate with it yet. For now I'm just going to bypass the video switch entirely and use up all the BNC barrel connectors in the lab, so we can at least have the useful video displays back.
Steve is summarizing the Video Matrix choices into this Wiki page:
Price: < 5k$
Control: RS-232 and Ethernet
Interface: BNC (Composite Video)
Please check into the page on Monday for a final list of choices and add comments to the wiki page.
Composite video matrix switchers with 32 BNC in and 32 BNC channels out are listed.
I finally got around to taking a look at the digital camera setup today. Rob had complained the client had stopped working on Rosalba.
After looking at the code start up and not complain, yet not produce any window output, it looks like it was a network problem. I tried rebooting Rosalba, but that didn't fix anything.
Using netstat -an, I looked for the port 5010 on both rosalba and ottavia, since that is the port that was being used by the camera. Ottavia was saying there were 6 established connections after Rosalba had rebooted (rosalba is 126.96.36.199). I can only presume 6 instances of the camera code had somehow shutdown in such a way they had not closed the connection.
[root@ottavia controls]#netstat -an | grep 5010
tcp 0 0 0.0.0.0:5010 0.0.0.0:* LISTEN
tcp 0 0 188.8.131.52:5010 184.108.40.206:57366 ESTABLISHED
tcp 0 0 220.127.116.11:5010 18.104.22.168:58417 ESTABLISHED
tcp 1 0 22.214.171.124:46459 126.96.36.199:5010 CLOSE_WAIT
tcp 0 0 188.8.131.52:5010 184.108.40.206:57211 ESTABLISHED
tcp 0 0 220.127.116.11:5010 18.104.22.168:57300 ESTABLISHED
tcp 0 0 22.214.171.124:5010 126.96.36.199:57299 ESTABLISHED
tcp 0 0 188.8.131.52:5010 184.108.40.206:57315 ESTABLISHED
I switched the code to use port 5022 which worked fine. However, I'm not sure what would have caused the original connection closure failures, as I test several close methods (including the kill command on the server end used by the medm screen), and none seemed to generate this broken connection state. I rebooted Ottavia, and this seemed to fix the connections, and allowed port 5010 to work. I also tried creating 10 connections, which all seem to run fine simultaneously. So its not someone overloading that port with too many connections which caused the problem. Its like the the port stopped working somehow, which froze the connection status, but how or why I don't know at this point.
We have installed the new Video Matrix.
Its still in an intermediate state, so don't try to "fix" anything before Kiwamu and I get back onto it in the afternoon.
The status so far is that we have removed the old switch (it was a 256 input x 128 output !! mux) and installed the new one in the same rack. We have hooked it up to the CDS network and have set up its matrix by using the web interface (i.e. NOT EPICS).
Along the way, we discovered that there is lack of impedance matching in the video all over the 40m. Video signals are RF and need to be treated that way. The PSL signals are T'd around and sent on 50 Ohm cables to high impedance monitor inputs.
We should eliminate any switches besides the new one (called Luciana) and control the PSL's Video Monitor from the main MUX interface. No more Rogue Video Switches.
Another couple of things we have found is about RCR camera.
(1) The long cable which connects the RCR camera box and the video matrix doesn't work. Although the signal is alive and we can see it by the local tv monitor nearby PSL.
(1) The reflected beam going to the camera is too weak to see in the monitor. We found a strange polarized cube splitter in front of the camera. We should modify it sooner or later.
We restored the good state of the ITMY camera and neatened both the MC2 and ITMY camera.
The MC2 camera was driving a triple T jungle into some random cables and spoiling the image. We removed all T's and the MC2 camera now drives only The Matrix.
The ITMY camera was completely unmounted and T'd. So it was misaligned just by the force of gravity acting on its BNC cable. We swapped the lens for a reasonable sized one and remounted it in its can. We then used orange cable ties to secure the power and BNC cable for the MC2 and ITMY cameras so that tugging on the cables doesn't misalign the cameras. This is part of the camera's SOP.
No more driving 50 Ohm cables and T's with video cables, Steve! If you need a portable video, just use a spigot of the Matrix and then you can control it with a web browser.
I also wiped out the D40's memory card after uploading all of the semi-useful files to the Picasa page.
I fixed up the ITMX camera like we did for ITMY recently (removed T's and added strain relief - the lens was already OK).
I also updated the .SCAN field for the RMTEMP and RCTEMP channels to 0.1 second. This had been done via probe but was wiped out after reboot previously, because I forgot to update the psl.db file.
Not that this is an urgent concern, just a data point which shows that it doesn't just not work at the sites.
I had to restart the dhcpd server on Ottavia that allows us to talk to the camera. I then also changed the configuration script on the camera so that it no longer thinks ottavia is 220.127.116.11, but correctly 192.168.113.97. Overall took 5 minutes.
I also looked up services for Centos 5, and set it using the program serviceconf to start the DHCP server when Ottavia is rebooted now. That should head off future problems of that nature. For reference, to start the dhcp server manually, become root and type "service dhcpd start".
I borrowed the Olympus and forgot to leave a note - I should have it for at most a day. dmassey@ligo if you need it urgently
I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.
You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.
So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.
As you can see from the image, it is illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.
Dear whomever setup the camera on the SW corner of the PSL table,
It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table. As it is now, the cables are in the way of the door. The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables. Squished cables are bad cables.
We have two new Basler acA640-100gm cameras. These are power over ethernet (PoE) and very tiny.
We successfully aligned the X arm. No big deal. Nothing to write in giant colorful letters about. If we thought it was tricky, we'd be excited. But since we're rockstar grad students, we can do this anytime, with one hand behind our back.
Earlier this evening, Kiwamu put a PD at the dark port. After starting with the usual steering beams around and approximately centering them by finding the beam on the SUS tower, we saw that we could see the fringes on a 'scope hooked up to the dark port's new PD. We could make the dip in the scope trace go away by misaligning the ETM, so we were confident that it was due to some kind of resonance in the arm. We then fine-tuned our beam centering by moving the optics in either pitch or yaw until the fringe went away, wrote down the number, then moved the other direction until the fringe went away, and then put the optic back in the middle of those two numbers. We did the ETM first, then the ITM (because the beam on the PD is sensitive to the ITM pointing, so we didn't want to have to move the ITM very far). We saw that the cavity had a visibility of ~56% when we had finished with this method.
We then went to look for the flashes transmitted through the ETM. We were not able to see them on a card, but when we looked with an IR viewer at the back face of the ETM, we could see the flashes. We stole a spare CCD camera found on the PSL table, and the camera power supply from the RefCav Refl camera, and set up a CCD camera with telephoto lens on the ETMX Trans table, looking directly at the back of the ETM. We hooked the camera up to the regular ETMX camera cable, so we can see the flashes in the control room. You can see them here:
While the cavity was aligned, here were the slider positions:
Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?
Correct. We can see the flashes clearly on our new ETM camera, but we see absolutely nothing on the ITM.
Unfortunately, the camera is in the path of the green beam, so we'll have to figure out a more permanent plan. Right now the laser at the end is shuttered.
Measuring the power now....
The power budget for the FPMI is here. The expected Intracavity power and the transmission are at most ~8W and 100uW, respectively.
The Watec 902, 1/2" CCD camera got new Tamron lens: 1/2" 10-40mm F/1.4 manual iris. IR corrective lens. It is designed to have the same focal point in the IR as
in the visible light range. However, as the depth of field in the IR range is very narrow, focus adjustment should be done carefully in the IR.
Now you can see the sus tower that will make alignment easier.
Today I have made the CCD Cable Upgrade Plan for improvement of sysmtem.
I have ~60 VIDEO cables to be worked for upgrades so I would like to ask all of your favor in helping me of replacing cables.
Currently, VIDEO system is not working as we desire.
About 20 cables are of impedance of 50 or 52 ohm which is not matched with the whole VIDEO system.
Moreover, some cameras and monitors are out of connection.
2. What I have worked so far.
I have checked impedance of all cables so I figured out which cables can be used or should be replaced.
I measured cables' pathes along the side tray so that we can share which cable is installed along which path.
I have made almost of cables necessary for VIDEO system upgrades but no label is attached so far.
3. Upgrade plan (More details are shown in attached file)
4. This is a kind of a first draft of the plan.
Any comment for the better plan is always welcome.
Moreover, replacing all the cables indicated in the files is of great amount of work.
I would like to ask all of your favors in helping me to replace the cables (from 1. to 2D. steps above).
After getting some help from the Basler technical support, I was directed to the following ftp link:
I went to the pylon 2.1.0 directory and downloaded the pylon-2.1.0-1748-bininst-64.tar.bz2 file. Inside of this tar file was another one called pylon-bininst-64.tar.bz2 (along with some other sample programs). I ran tar -jxf on pylon-bininst-64.tar.bz2 and placed the results into the /opt/pylon directory. It produced a directory of includes, libraries and binaries there.
After playing around with the make files for several sample programs they provided, I finally have been able to compile them. At several places I had to have the make files point to /opt/pylon/lib64 rather than /opt/pylon/lib. I'll be testing the camera with these programs on Monday. I'd also like to see if this particular distribution will work on Centos machines. There's some comments in one of the INSTALL help files suggesting packages needed for an install on Fedora 9, which may mean its possible to get this version working on the Centos machines.
The Basler acA640-100gm is a power over ethernet camera. It uses a power injector to supply power over an ethernet cable to the camera. Once I got past some initial IP difficulties, the camera worked fine out of the box.
You need to set some environment variables first, so the code knows where its libraries are located.
setenv PYLON_ROOT /opt/pylon
setenv GENICAM_ROOT_V1_1 /opt/pylon
setenv GENICAM_CACHE /cvs/cds/caltech/users/josephb/xml_cache
setenv LD_LIBRARY_PATH /opt/pylon/lib64:$LD_LIBRARY_PATH
I then run the /opt/pylon/bin/PylonViewerApp
Notes on IP:
Initially, you need to set the computer connecting to the camera to an ip in the 169.254.0.XXX range. I used 169.254.0.1 on megatron's eth1 ethernet connection. I also set mtu to 9000.
You can then run the IpConfigurator in /opt/pylon/bin/ to change the camera IP as needed.
Today was the first session for implementing the new video cabling plan laid out in the document " CCD_Cable_Upgrade_Plan_Jan11_2011.pdf" by Joon Ho attached to his elog entry 4139. We started to check and label all the existing cables according to the new naming scheme.
So far we have labeled the following cables. Each has been checked by connecting it to a monitor near the Video Mux and a camera at the other end.
C1:IO VIDEO 8ETMYF
C1:IO-VIDEO 6 ITMYF
C1:IO-VIDEO 21 SRMF
C1:IO-VIDEO 25 OMCT
C1:IO-VIDEO 19 REFL
C1:IO-VIDEO 22 AS
C1:IO-VIDEO 18 IMCR
C1:IO-VIDEO 14 PMCT
C1:IO-VIDEO 12 RCT
C1:IO-VIDEO 9 ETMXF
C1:IO-VIDEO 1 MC2T
Next we need to continue and finish the labeling of existing cables. We then choose a specific set of cables which need to be laid together and proceed to lay them after attaching suitable lables to them.
Computar 75-12.5 zooms were installed for closer look at the resonant spots. Their alignment and focus needs more loving adjustment.
Atm 1, ITMX ( it was 10-40 mm Tamron before )
Atm 2, ITMY ( it was 12mm wide angle showing the towers before )
I focused these lenses so that we could get a clean image of the mirrors and the OSEMs.
Our goal is to have an image where the optic diameter almost fills the entire monitor. We want the focus to be adjusted for the YAG beam (which is almost the same as focusing for the OSEMs). This will NOT produce a nice image of the cage using visible light, but that is just fine.
When Justin Garofoli was here he found a nice lens combo that did the job, so if anyone can find his old email or elog, lets just go back to that.
For now, we do not need a camera/lens system to focus very tightly on the center of the optic.
ITMY gets new Tamron M118FM50 that has improved close focusing. It is a small fixed focal length camera so the video tube cover can be put on.
The Watec LCL-902K 1/2" ccd camera was losing it power supply voltage because of bad connection. It was replaced.
I just tried to adjust the ETMY camera and its not very user friendly = NEEDS FIXING.
* Camera view is upside down.
* Camera lens is contacting the lexan viewport cover; this means the focus cannot be adjusted without misaligning the camera.
* There's no strain relief of the camera cables at the can. Needs a rubber cable grommet too.
* There's a BNC "T" in the cable line.
Probably similar issues with some of the other setups; they've had aluminum foil covers for too long. We'll have a camera committee meeting tomorrow to see how to proceed.
ITMY has been upgraded here I have the new lenses on hand to do the others when it fit into the schedule.
[Suresh / Kiwamu]
The MC REFL camera is now available. The camera name is "MCR" and you can call it from the videoswitch script.
(what we did)
+ repositioned and aligned the MCR camera.
+ checked the MCR camera.
=> found the camera view shows a negative image (i.e. the beam spot is dark and the background is bright !!)
+ replaced the camera by a spare one.
+ modified the videoswitch script because the input channel 3 was wrongly assigned to MCR.
MCR was correctly assigned to the input channel 18.