40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 46 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  16774   Wed Apr 13 15:57:25 2022 Ian MacMillanUpdateCamerasCamera Battery Test

Tested the Nikon batteries for the camera. they are supposed to be 7V batteries but they don't hold a charge. I confirmed this with multi-meter after charging for days. Ordered new ones Nikon EN-EL9

  16776   Wed Apr 13 18:55:54 2022 KojiUpdateCamerasCamera Battery Test

I believe that the Nikon has an exposure problem and that's why we bought the Canon.

 

  1333   Mon Feb 23 16:42:08 2009 josephbConfigurationCamerasCamera Beta Testing

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.

  2371   Wed Dec 9 10:53:41 2009 josephbUpdateCamerasCamera client wasn't able to talk to server on port 5010, reboot fixed it.

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 131.215.113.103).  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 131.215.113.97:5010         131.215.113.103:57366       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:58417       ESTABLISHED
tcp        1      0 131.215.113.97:46459        131.215.113.97:5010         CLOSE_WAIT 
tcp        0      0 131.215.113.97:5010         131.215.113.103:57211       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57300       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57299       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103: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.

  1355   Wed Mar 4 17:20:04 2009 josephbUpdateCamerasCamera code upgrades

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.

  2470   Wed Dec 30 22:17:07 2009 kiwamuUpdateGeneralCamera input and monitor output

The input channels of the cameras and the output channels for the monitors are summarized on the wiki.

The channel table on the wiki is very helpful when you want to make a change in the video matrix.

thank you.

  7569   Wed Oct 17 18:41:27 2012 JenneUpdateCamerasCamera looking at ETMY baffle

The camera titled "watec_mobile" is looking at the front of the black glass baffle (i.e. the side facing the ITM) on the ETMY table.  This required (for my quick hacky solution) removing the regular ETMYF camera.  Steve has a genius plan (I think) so that we can have both at the same time.  Anyhow, eventually we'll move the black glass back, so we'll be back to needing just one camera.

After dinner, I'll try aligning the Yarm.

  2276   Mon Nov 16 17:24:28 2009 josephbConfigurationComputersCamera medm functionality improved

Currently the Camera medm screen (now available from the sitemap), includes a server and client script buttons.  The server has two options.  One which starts a server, the second which (for the moment) kills all copies of the server running on Ottavia.  The client button simply starts a video screen with the camera image.  The slider on this screen changes the exposure level.  The snap shot button saves a jpeg image in the /cvs/cds/caltech/cam/c1asport directory with a date and time stamp on it (up to the second).  For the moment, these buttons only work on Linux machines.

All channels were added to C0EDCU.ini, and should be being recorded for long term viewing.

Feel free to play around with it, break it, and let me know how it works (or doesn't).

  16859   Mon May 16 19:14:17 2022 AnchalUpdateBHDCamera set on AS path and BHDBS output path

[Anchal, Paco, Yuta]

  • We aligned AS path avoiding any clipping to the AP table where we setup a camera with a lens.
    • To do this we had to move AS6 in North direction for ~1cm.
    • The Injection table was imbalanced by this move to drop the IMC transmission to half.
    • We did not balance the table again, we steered the input mirror to reach to 1000 counts (out of 1200 nominal) and then used WFS loop to get to the last bit.
    • The input to the arm cavities did not change much, XARM was still flashing to 0.8 max height and YARM to 0.2. We recovered these easily using the cavity mirror pair.
  • We aligned the LO beam to be spatially matched on BHDBS with AS path.
    • The LO beam was steered to roughly overlap with the AS beam outputs on the BHDBS.
    • However, the LO beam size is very large and diverges after LO4.
    • According to 40m/15379, the 0.15m ROC of LO4 right after the beam waist is supposed to collimate the beam to a 522 um waist.
    • We confirmed that LO4 is marked as a 0.15m ROC mirror on its edge and the HR coating is facing the incident beam.
      • Conjecture (AG): The coating was applied to the flat side of the optic instead of the curved side.
      • This would explain why the beam is continuing to diverge after reflecting from LO4, and diverging fast.
    • We need to fix this issue before pumping down otherwise the mode matching would be too poor in BHDBS to have any meaningful results.
  • The output of BHDBS was steered out and a GigE camera is set up to see this path.
    • The camera is set to see the transmitted AS beam from BHD BS (and reflected LO beam).
    • But the camera is unable to see any LO beam due to large divergence.
    • The LO beam essentially disappears after ~30 cm from the BHDBS.

 

  813   Fri Aug 8 10:58:05 2008 josephbConfigurationCamerasCameras and gstreamer
In regards to camera failure:
1) I forgot to reconnect that particular camera to the network (my fault) so thats why it was failing.

2) Even with the correct camera connected, I've realized at full frame rate, op440m is going to get a few frames and then fail, as I don't think it has a fast enough ethernet card. It will work on Rosalba, and will also work ssh-ing from Rosalba because it is using a new ethernet card. It also works on my laptop, which is where I originally tested the command. One way to get around this is to increase the time between pictures, by changing -l 0 to -l 1 (or higher), where the number after the "ell" is the number of seconds to wait between frame captures.

3) What I should do is figure out the UDP transmission plugins for gstreamers and compress first (using the theoraenc since it gets compression ratios of better than 100:1) and transmit that over the network.

I have since reconnected the camera, so it should work on Rosalba and any sufficiently well connected computer. For other machines like linux2 or op440, try the following line:

Running the following command on Mafalda (via ssh -X mafalda) or Rosalba while in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/

CamSnap -F 'Mono8' -c 44058 -E 10000 -X 0 -Y 0 -H 480 -W 752 -l 1 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=1/1 ! ffmpegcolorspace ! ximagesink

This will be at a much slower frame rate (1 per second) but should work on any of the machines. (Tested on linux2).
  16288   Mon Aug 23 11:51:26 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Campus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am (more like 9:34am according to nodus log)

nodus: rebooted. ELOG/apache/svn is running. (looks like Anchal worked on it)

chiara: survived the glitch thanks to UPS

fb1: not responding -> @1pm open to login / seemed rebooted only at 9:34am (network path recovered???)

megatron: not responding

optimus: no route to host

c1aux: ping ok, ssh not responding -> needed to use telnet (vme / vxworks)
c1auxex: ssh ok
c1auxey: ping ok, ssh not respoding -> needed to use telnet (vme / vxworks)
c1psl: ping NG, power cycled the switch on 1X2 -> ssh OK now
c1iscaux: ping NG -> rebooted the machine -> ssh recovered

c1iscaux2: does not exist any more
c1susaux: ping NG -> responds after 1X2 switch reboot

c1pem1: telnet ok (vme / vxworks)
c1iool0: does not exist any more

c1vac1: ethernet service restarted locally -> responding
ottavia: doesnot exist?
c1teststand: ping ok, ssh not respoding

3:20PM we started restarting the RTS

  16290   Mon Aug 23 19:00:05 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Restarting the RTS was unsuccessful because of the timing discrepancy error between the RT machines and the FB. This time no matter how we try to set the time, the IOPs do not run with "DC status" green. (We kept having 0x4000)

We then decided to work on the recovery without the data recorded. After some burtrestores, the IMC was locked and the spot appeared on the AS port. However, IPC seemed down and no WFS could run.

  9412   Tue Nov 19 15:04:14 2013 JenneUpdateCDSCan talk to AUXEY again

The ETMY sliders on IFO_ALIGN were white again this morning, so I went down to the Yend and pushed the RESET button on auxey.  I then did a burt restore to 00:07am this morning for both auxey and auxex (since the stickers on the machines are still the old naming convention, I wonder if the autoburt is also backwards, so I did both).  Now the 'save' and 'restore' scripts for ETMY are working again.

Hopefully it's all better now, but I'll keep an eye on it.

  9375   Wed Nov 13 18:02:08 2013 JenneUpdateCDSCan't talk to AUXEY?

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

  9387   Thu Nov 14 22:23:22 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.


controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
controls@rossa:~ 1$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex >
telnet> ^]
?Invalid command
telnet> exit
?Invalid command
telnet> quit
Connection closed.
controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
  9391   Fri Nov 15 10:19:26 2013 manasaUpdateCDSCan't talk to AUXEY?

Quote:

 

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.

 

This is what was done (as I recollect) when we said "inspected":Tenet into the computer, ping them and look at the status. Since c1auxey is not responding, here is how c1auxex responds.

controls@rossa:/cvs/cds/caltech/target 0$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex > h
  1  i
  2  -help
  3  --help
  4  h
  5  2
  6  h
  7  -help
  8  i
  9  h
value = 0 = 0x0
c1auxex > i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       fde244   0 PEND          87094   fde1ac   3006b     0
tLogTask   _logTask       fdb944   0 PEND          87094   fdb8a8       0     0
tShell     _shell         ddad00   1 READY         6d974   dda9c8  3d0001     0
tRlogind   _rlogind       fbc11c   2 PEND          2b604   fbbdf4       0     0
tTelnetd   _telnetd       fba278   2 PEND          2b604   fba1a8       0     0
tTelnetOutT_telnetOutTa   db7578   2 READY         2b604   db72e0       0     0
tTelnetInTa_telnetInTas   db6060   2 READY         2b5dc   db5d68       0     0
callback   _callbackTas   f7941c  40 PEND          2b604   f793d4       0     0
scanEvent  ee7ca8         ecacb4  41 PEND          2b604   ecac6c       0     0
tNetTask   _netTask       fd75b8  50 READY         6be6c   fd7550       0     0
scanPeriod ee78f8         ecd554  53 READY         6d192   ecd508       0     0
scanPeriod ee78f8         f23e48  54 DELAY         6d192   f23dfc       0     6
tFtpdTask  _ftpdTask      fb7848  55 PEND          2b604   fb778c       0     0
scanPeriod ee78f8         f266e8  55 READY         6d192   f2669c       0     0
scanPeriod ee78f8         f38678  56 READY         6d192   f3862c       0     0
callback   _callbackTas   f7bcbc  57 PEND          2b604   f7bc74       0     0
scanPeriod ee78f8         f906d8  57 DELAY         6d192   f9068c       0    59
scanPeriod ee78f8         f995ac  58 DELAY         6d192   f99560       0   238
scanPeriod ee78f8         f9c908  59 DELAY         6d192   f9c8bc       0   538
callback   _callbackTas   fa4c1c  65 PEND          2b604   fa4bd4       0     0
scanOnce   ee7764         f9f96c  65 PEND          2b604   f9f92c       0     0
epicsPrint f0501c         e88fa0  70 PEND          2b604   e88f64   c0002     0
ts_Casync  ee5bae         f76b7c  70 DELAY         6d192   f76880  3d0004   178
tPortmapd  _portmapd      fb8d60 100 PEND          2b604   fb8c2c      16     0
EgRam      ea00e4         fa14ac 100 PEND          2b604   fa1458       0     0
CA client  _camsgtask     d85878 180 PEND          2b604   d85774  3d0004     0
CA client  _camsgtask     df91e8 180 PEND          2b604   df90e4       0     0
CA client  _camsgtask     d98bf4 180 PEND          2b604   d98af0       0     0
CA client  _camsgtask     e03cd0 180 PEND          2b604   e03bcc       0     0
CA client  _camsgtask     ddf2b8 180 PEND          2b604   ddf1b4       0     0
CA client  _camsgtask     faaec8 180 PEND          2b604   faadc4       0     0
CA client  _camsgtask     d79f3c 180 PEND          2b604   d79e38       0     0
CA TCP     _req_server    f305dc 181 PEND          2b604   f30540       0     0
CA repeaterf109e2         f215a8 181 PEND          2b604   f21474       0     0
CA event   _event_task    d7fe58 181 PEND          2b604   d7fe10       0     0
CA event   _event_task    d6ce5c 181 PEND          2b604   d6ce14       0     0
CA event   _event_task    dab7e0 181 PEND          2b604   dab798       0     0
CA event   _event_task    d76efc 181 PEND          2b604   d76eb4       0     0
CA event   _event_task    d9bddc 181 PEND          2b604   d9bd94       0     0
CA event   _event_task    d9a864 181 PEND          2b604   d9a81c       0     0
CA event   _event_task    da8d8c 181 PEND          2b604   da8d44       0     0
CA UDP     _cast_server   f2f064 182 READY        efcabe   f2efe4       0     0
CA online  _rsrv_online   f2d84c 183 DELAY         6d192   f2d7bc       0   265
EV save_res_event_task    de88dc 189 PEND          2b604   de8894   3006b     0
save_restor_save_restor   df61cc 190 PEND          2b604   df5c44  3d0002     0
RD save_res_cac_recv_ta   fb47d8 191 READY         2b604   fb46a4  3d0004     0
logRestart f05d42         e861c0 200 PEND+T        2b604   e86174      33  1714
taskwd     ef4d46         e85030 200 DELAY         6d192   e84f7c       0   224
value = 0 = 0x0
c1auxex >
telnet> quit
Connection closed.
controls@rossa:/cvs/cds/caltech/target 0$

  9393   Fri Nov 15 10:49:55 2013 jamieUpdateCDSCan't talk to AUXEY?

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

  9394   Fri Nov 15 12:00:28 2013 KojiUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 Don't forget to run burtrestore for the target.

  9395   Fri Nov 15 12:38:50 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

  9402   Mon Nov 18 21:20:54 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 The auxey machine is back, in that I can interact with the IFO_ALIGN sliders, and they actually make the optic move, but I still can't read and write to and from the EPICs channels:

controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 0$ cdsutils read C1:SUS-ETMY_PIT_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:13:52.044973819
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_PIT_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$ cdsutils read C1:SUS-ETMY_YAW_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:14:07.040168660
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_YAW_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$

This is also causing trouble for the BURT save and BURT restore scripts, that are called from the IFO_ALIGN screen.  If I look at the log that is written from an attempted 'save' of the slider values, I see:

**** READ BURT LOGFILE

--- Start processing files
file >/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMY.req<
preprocessing ... done
pv >C1:SUS-ETMY_PIT_COMM< nreq=-1
pv >C1:SUS-ETMY_YAW_COMM< nreq=-1
--- End processing files

--- Start searches
C1:SUS-ETMY_PIT_COMM ... ca_search_and_connect() ... OK
C1:SUS-ETMY_YAW_COMM ... ca_search_and_connect() ... OK
--- End searches
Waiting for 2 outstanding search(es) ...
Waiting for 2 outstanding search(es) ...
did not find 2

--- Start reads
C1:SUS-ETMY_PIT_COMM ... not connected so no ca_array_get_callback()
C1:SUS-ETMY_YAW_COMM ... not connected so no ca_array_get_callback()
--- End reads

--- Start wait for pending reads

-- End wait for pending reads 0 outstanding read(s)

**** END BURT LOGFILE

The burt save file has no values in it.  Even if I copy over the ETMX save file and put in the correct channel names and values, a burt restore is unsuccessful. 

So, I can do locking tonight by restoring and misaligning by hand, but this sucks, and needs to be fixed. Other optics (at least PRM, SRM, ETMX) seem to be working just fine.  It's just ETMY that has a problem.

 

  2516   Fri Jan 15 12:04:26 2010 Sanjit, mevansUpdateAdaptive FilteringCanceling noise again!

 

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
  • Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

 

  7687   Thu Nov 8 09:04:45 2012 SteveUpdateCamerasCanon T3i purchased

Canon EOS Rebel T3i has been purchased. See rating

  16250   Sat Jul 17 00:52:33 2021 KojiUpdateGeneralCanon camera / small silver tripod / macro zoom lens / LED ring light borrowed -> QIL

Canon camera / small silver tripod / macro zoom lens / LED ring light borrowed -> QIL

  16255   Sun Jul 25 18:21:10 2021 KojiUpdateGeneralCanon camera / small silver tripod / macro zoom lens / LED ring light returned / Electronics borrowed

Camera and accesories returned

One HAM-A coildriver and one sat amp borrowed -> QIL

https://nodus.ligo.caltech.edu:8081/QIL/2616

 

  3052   Sun Jun 6 08:08:05 2010 rana, sanjitSummaryElectronicsCapacitor Bridge Test

To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

CapacitanceBridge.png

We measured the cap values with an LCR meter. They were all within a few % of 0.99 nF.

With a 0.5 V drive to the top of the bridge, the A-B voltage was ~2 mV as expected from the matching of the capacitors.

(** Note about the gain in the SR830: In order to find the magnitude of the input referred signal, one has to divide by G. G = (10 V)/ Sensitivity. 'Sensitivity' is the setting on the front panel.)

  1. Directly measuring from Vs to ground gives 0.5 V, as expected. This is done to verify the calibration later on.
  2. Shorting the A and B wires to ground gives ~0 V and lets us measure the noise. On the spectrum analyzer it was ~400 nV/rHz at 100 Hz and rising slowly to 4 uV/rHz at 100 mHz. In this state, the sensitivity was 10 mV, so the overall gain was 1000. That gives an input referred level of ~0.4 nV/rHz at the input.
  3. Hooking up now to A-B: the signal is ~10x larger than the 'dark' noise everywhere. 2 uV/rHz @ 100 Hz, 10 uV/rHz @ 10 Hz, 50 uV/rHz @ 1 Hz. The spectrum is very non-stationary; changing by factors of several up and down between averages. Probably a problem with the cheapo contacts in the breadboard + wind. The gain in this state was still 1000. So at 1 Hz, its 50 nV/rHz referred to the input.

To convert into units of capacitance fluctuation, we multiply by the capacitance of the capacitors (1 nF) and divide out by the peak-peak voltage (1 V). So the bridge sensitivity is 50e-9 * 1e-9 = 5 x 10^-17 F/rHz.

If we assume that we will have a capacitive displacement transducer giving 1 nF capacitance change for a 0.1 mm displacement, this bridge would have a sensitivity of 5 x 10^-12 m/rHz @ 1 Hz. We would like to do ~50-100x better than this. The next steps should be:

  1. Solder it all together on a PCB to have less air current sensitivity and decent contacts.
  2. Use a low-noise FET input. Since the impedance of the bridge is ~5 kOhms at this frequency, we are probably current noise limited.
  3. Estimate the oscillator amplitude noise sensitivity.
  3053   Mon Jun 7 07:39:38 2010 AlbertoOmnistructureElectronicsCapacitor Bridge Test

Quote:

To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

The measurement setup for the Capacitor Bridge Test is still sitting on one of the work benches.

Unless the experiment is supposed to continue today, the equipment shouldn't have been left on the bench. It should have been  taken back to the lab.

Also the cart with HP network analyzer used for the test was left in the desk area. That shouldn't have left floating around in the desk area anyway.

The people responsible for that, are kindly invited to clean up after themselves.

  8736   Fri Jun 21 16:30:04 2013 SteveUpdateGeneralCapacitor Inventory

The 3 Panasonic Ceramic Kits Books, 1206 NPO, SMT are well stocked. The 4 th one needs to be refilled at some values.

I labeled them on the cover for fast access. See Atm1

 

The Metalized Polyester Film Book with through holes mount are in good shape also. Atm2

 

The AVX Ceramic 1206,  Garrett cab, range: 1pF - 22 microF 50V...... 67 values

Note here: that the value of dielectric, capacitance / voltage will vary

NPO: 1 pF - 1 nF /  50V .......37 values

X7R : 1 nF -  0.082 microF /  50V,  0.1 microF /  100V.......27 values

Y5V:  4.7 microF / 6.3 V,  10 microF / 10V,  22 microF / 6.3V.........3 values 

 

  13105   Mon Jul 10 17:13:21 2017 jigyasaUpdateComputer Scripts / ProgramsCapture image without pylon GUI

Over the day, I have been working on a C++ program to interface with Pylon to capture images and reduce dependence on the Pylon GUI. The program uses the Pylon header files along with opencv headers. While ultimately a wrapper in python may be developed for the program, the current C++ program at, 

/users/jigyasa/GigEcode/Grab/Grab.cpp when compiled as

g++ -Wl,--enable-new-dtags -Wl,-rpath,/opt/pylon5/lib64 -o Grab Grab.o -L/opt/pylon5/lib64 -Wl,-E -lpylonbase -lpylonutility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 `pkg-config opencv --cflags --libs`

returns an executable file named Grab which can be executed as ./Grab

This captures one image from the camera and displays it, additionally it also displays the gray value of the first pixel.

I am working on adding more utility to the program such as manually adjusting exposure, gain and also on the python wrapper (Cython has been installed locally on Ottavia for the purpose)!

  1068   Wed Oct 22 16:22:53 2008 steveBureaucracySAFETYCaryn received safety training
Caryn Polatchi has received 40m safety training on Monday, Oct 20
  3356   Wed Aug 4 03:01:56 2010 JenneUpdatePEMCatastrophic Cable Failures

Quote:

After some cable swapping this morning, I have determined which cable is bad.  It's the Gur1 cable between the seismometer and the breakout box.  This is a milspec -> 37pin d-sub cable.  I'll pull out the cable and have a look at it after lunch.

 So, I was wrong about which cable it was, probably in my rush to get some lunch.  The actual culprit was the octopus cable that Bob made waaay back in the day (~2 years ago) to go from the "ADC out" of the breakout box (37pin Male Dsub) to 9 BNCs.  As it turns out, the Gur1Z channel of that cable was broken on both ends!!! 

On one end, we have the 37 pin Dsub.  The cable used was so thick (way too thick for this application) that it made a super rigid connection between the wires and the connector, and any bending of the cable stressed this connection, despite the strain-relief of the backshell.  The Gur1Z connection snapped off when I was gently wiggling the connections to check them out.  Also, since the wires were all so thick, they didn't really fit into the hole in the backshell, so 2 or 3 of them were squished.....straight through the insulation so that several channels were shorted together / potentially shorted to ground.  This may explain some of the nasty behavior that Rana and I had seen (although I might have forgotten to elog? My bad.) that even with the inputs of the breakout box all terminated, there was high coherence between the channels.  Terminated inputs should give random noise, so this was fishy. 

On the other end of the cable we have the 9 BNCs.  I had finished redoing the 37pin end of the cable, and was 'beeping' it to check it out, when to my dismay I found that the Gur1Z channels (the inside and the outer shield of the BNC connector) were shorted together.  I removed these 2 wires from the Dsub connector to confirm that the BNC was at fault.  Koji looked at the BNC with me after I chopped it off of the cable.  Bad news strikes again.  To get the wires to fit in the inner pin of the BNC connector, the cable-maker had cut off several strands of the wire to make it skinnier.  It appears that over the years these cut-off strands wiggled their way to touching the outer shield.  This appears to be a danger for all of the BNCs on this cable: a little bit of torque (which one might expect during plugging and unplugging a BNC) and the 2 sides of the differential measurement will be shorted together.

I then decided to start afresh and make my own cable.  I found some AWG26 8-twisted-pair cable laying around underneath the Yarm (since this was all I could find, I was just going to do the Gur1 and Gur2 channels, and leave out the Gur3's).  The 37 Dsub side was easy, but I seem not able to connect such skinny wire to the BNC connectors in a robust way.  Since this bad cable has so far cost me ~2.5 16-hour days of grief, I don't want my new version of it to also be bad.  At this point, I await the advice of one wiser than I. I think BNC connectors are designed for something a little closer to ~20AWG, but I could be wrong.  Also, they are obviously optimized for coax cable. So what I have now is never going to be great.  Maybe tomorrow I can go to the Electronics Shop / Store and buy BNC connectors that are meant to be soldered-to.  That would be awesome.

Since I currently have no functional cable to go from Breakout box to ADC, the Guralps are unplugged for tonight.

Conclusions for the day / evening:  Frank, Alastair and Jenna are mostly absolved of blame, although the traveling to Bridge and opening and closing the box (which usually involves more plugging and unplugging of cables) probably didn't help this cable out too much.  Also, Bob definitely owes me a Sugar Napoleon or something.

 In other news, since the Gur2Z ADC channel is totally wacked, I have taken over (but not renamed) the Ranger channel for Gur2Z for now.  Jan still has the Ranger hostage over in Bridge, so this is okay for now.

  13116   Thu Jul 13 16:10:34 2017 KaustubhSummaryComputer Scripts / ProgramsCavity Scan Simulation Code

The code to produce a cavity scan simulation and then fitting the data and re-evaluating the initiallt set parameters can be found in this git repo.


The 'CavitScanSimulation' python script now produces a cavity scan with custom parameters which can be easily modified. It also introduces the first TEMs(n+m=0,1,2,3,4) to the laser with power going as (1/(2(n+m)+1))^2 {Selected carefully}. The only care that needs to be taken is that the frequency span should be somewhere near an integral multiple of the FSR so that there are equal number of resonances for all modes and sidebands. This code, as of now also calls the 'FitCavityScan' script which performs the fitting procedure on the data generated above{This data is actually written in a '.mat' file} and generates the Fit parameter data files. The Simulation code then calls the 'CalculatingPhysicalParameters' script which evaluates the data based on the Fit parameters and outputs some physically relevant results like the FSR, Finesse, Modulation Depths, TMS{Current Output is the Estimated RoCs of the two mirrors which isn't something we want directly, so it can be modified a bit to output TMS based on the HOMs}. The scripts do some 'Linearity' checks which might not really be of much significance but can be seen as a reference. Also, the ipython notebook will show all intermediate plots for the actual data and data with custom noise, fit data, FSR fitting, linearity checks, Bessel Ratio plot with mod_depths.

 

Note: The scripts should be run using either an IDE like 'spyder'{for .py files}{Comes with Anaconda} or using an ipython notebook{for .ipynb files}.
  13155   Mon Jul 31 23:39:02 2017 ranaUpdateCOCCavity Scan Simulation Code

Hiro Yamamoto has updated SIS (Static Interferometer Simulation) to allow us to do the MCMC based inference of the 40m arm cavity mirror maps. 

The latest version is in git.ligo.org: IFOsim/SIS/

In the examples directory I have put 3 files:

  1. mcmcCavityScans.m - runs many cavity scans using parfor and saves the data
  2. plotCavityScans.m - loads the .mat file with the data and plots it
  3. plotCavityScans.py - python file which also loads & plots, but nicer since python has a transparency option for the traces.

Attached is the plots and the data. The first attached plot is a low resolution one: 200 scans of 100 frequency points each. Second plot is 200 scans of 300 points each.

The run was done assuming perfect LIGO arm params with a random set of Zernike perturbations for each run. The amplitude of each Zernike was chosen from a Normal distribution with a standard deviation of 10 nm.

We need to come up with a better guess for the initial distribution from which to sample, and also to use the more smart sampling that one does using the MCMC Hammer.

  4585   Fri Apr 29 03:39:49 2011 KojiSummaryLSCCavity lengths

I tried the idea that the PRC can resonate f1 and f2 at the same time if the arm gives the reflection phase to f1 and f2 with the ratio of 1 vs 5.

The details are described on wiki. The point is this removes all of the PRC/SRC/asymmetry mumbo jumbo.

The calculated cavity lengths for f_mod of 11.065399MHz are:

  • Arm Length: 37.7974 [m]

  • PRC Length: 6.7538 [m]

  • SRC Length: 5.39915 [m]

  • Asymmetry (lx-ly): 0.0342 [m]


Here is the actual values derived from the photos.

  • Arm Length: 37.54 [m] (0.26m too short)

  • PRC Length: 6.760 [m] (6mm too long)

  • SRC Length: 5.415 [m] (16mm too long)

  • Asymmetry (lx-ly): 0.0266 [m] (8mm too long)

  7351   Thu Sep 6 17:06:25 2012 Rijuparna ChakrabortyConfigurationelogCavitymode scan

 Aim: to scan the cavitymodes of IMC

The circuit used: 

 Attachment4

Results obtained:

Attachment 1,2,3

 

  10889   Tue Jan 13 01:58:16 2015 ericqUpdateComputer Scripts / ProgramsCdsutils upgraded to 382

I've upgraded our cdsutils installation to v382; there have been some changes to pydv which will allow me to implement the auto y-scaling on our lockloss plots. 

After some brief testing, things seem to still work...

  11124   Mon Mar 9 16:50:35 2015 Champagne DuckFrogsTreasureCelebrating Lock

  10932   Thu Jan 22 22:15:30 2015 diegoUpdateSUSCentered OpLevs

[Diego, Jenne]

We centered the OpLevs for ITMX and ITMY.
 

  16231   Wed Jun 30 15:31:35 2021 AnchalSummaryOptical LeversCentered optical levers on ITMY, BS, PRM and ETMY

When both arms were locked, we found that ITMY optical lever was very off-center. This seems to have happened after the c1susaux rebooting we did in June 17th. I opened the ITMY table and realigned the OPLev beam to the center when the arm was locked. I repeated this process for BS, PRM and ETMY. I did PRM because I've known that we have been keeping its OpLev off. The reason was clear once I opened the table. The oplev reflection beam was hitting the PD box instead of the PD. After correcting, I was able to swithc on PRM opLev loops and saw normal functioning.

  9235   Fri Oct 11 20:30:08 2013 MasayukiUpdateSUSCentering of Oplev of ETMY

I centered the oplev of the ETMY, because I found that Yarm lost lock every 10 minutes, and the ETMY oplev was misaligned very much. I attached the 40 minutes trend of oplev and LSC-TRY. Yarm looks more stable. After centering of the oplev, the YARM looks to be more stable.

 

  7020   Tue Jul 24 18:33:12 2012 YaakovUpdateVIDEOCentering the MCR camera

Jenne and I centered the MCR camera on the AP table.

We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way.

  7026   Wed Jul 25 11:41:00 2012 YaakovUpdateVIDEOCentering the MCR camera

Quote:

Jenne and I centered the MCR camera on the AP table.

We moved the camera as far as it could go on its mount without shifting its screws, and adjusted the optic that the camera looks at for the rest of the way.

 The spot was still off center on the quad display in the control room, so I re-recentered it today.

  7035   Thu Jul 26 02:44:17 2012 JenneUpdateIOOCentering the MCR camera

[Yaakov, Jenne]

The short version:

Rana and Koji pointed out to us that the MCR camera view was still not good.  There were 2 problems:

(1) Diagonal stripes through the beam spot.  Yuta and I saw this a week or 2 before he left, but we were bad and didn't elog it, and didn't investigate.  Bad grad students.

(2) Clipping of the left side of the beam (as seen on the monitors).  This wasn't noticed until Yaakov's earlier camera work, since the clipped part of the beam wasn't on the monitor.

The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. 

The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again.

We moved the 10% BS that splits the main beam into the (MC REFL PD) path and the (MCR camera + WFS) path.  It looked like the transmission through there was close to the edge of the BS.  We didn't think that this was causing the clipping that we saw on the camera (since when we stepped MC1 in Yaw, the beam spot had to move a lot before we saw any clipping), but it seemed like a good idea to make the beam not near the edge of the optic, especially since, being a 2" optic, there was plenty of room, and we were only using ~half of the optic.  We didn't touch anything else in the WFS path, since that looks at the transmission through this BS, but we had to realign the beam onto MC REFL.

The long version:

(1)  The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum.  It looks like that's why the iris was there in the first place.  When we found it this evening, the iris was totally open, so my current theory is that someone was on the AP table doing something, and accidentally bumped the handle for the iris, then left it completely open when they realized that they had touched it.  I think Steve had been doing something on the AP table around then, but since Yuta and I didn't elog our observation (bad grad students!), I can't correlate it with any of Steve's elogs. We were not able to find exactly where this "glow" that the iris is used to obscure comes from, but we traced it as far as the viewport, so there's something going on inside.

(2)  The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again. 

We spent a long time trying to figure out what was going on here.  Eventually, we moved the camera around to different places (i.e. right before the MC REFL PD, with some ND filters, and then we used a window to pick off a piece of the beam right as it comes out of the vacuum before going through the iris, put some ND filters, then the camera).  We thought that right before the MC REFL PD was also being clipped, indicating that the clipping was happening in the vacuum (since the only common things between the MC REFL PD path and the camera path are the iris, which we had removed completely, and a 2" 10% beam splitter.  However, when we looked at a pickoff of the main beam before any beamsplitters, we didn't see any evidence of clipping.  I think that when we had the camera by MC REFL, we could have been clipping on the ND filters that I had placed there.  I didn't think to check that at the time, and it was kind of a pain to mush the camera into the space, so we didn't repeat that.  Then we went back to the nominal MCR camera place to look around.  We discovered that the Y1 which splits the camera path from the WFS path has a ghost beam which is clipping on the top right side (as you look at the face of the optic) of the optic, and this is the beam that was going to the camera (it's a Y1 since we only want a teensy bit of light to go to the camera, the rest goes to the WFS).  There is another beam which is the main beam, going through the center of the optic, which is the one which also reflects and heads to the WFS.  This is the beam which we should have on the camera.  Yaakov put the camera back in it's usual place, and put the correct beam onto the center of the camera.  We did a check to make sure that the main beam isn't clipping, and when I step MC1 yaw, the beam must move ~1.5mm before we start to see any clipping on the very edge of the beam.  To see / measure this, we removed the optic which directs the beam to the camera, and taped an IR card to the inside of the black box.  This is ~about the same distance as to the nominal camera position, which means that the beam would have to move by 1.5mm on the camera to see any clipping.  The MC REFL PD is even farther from MC1 than our IR card, so the beam has to fall off the PD before we see the clipping.  Thus, I'm not worried about any clipping for this main beam.  Moral of the story, if you made it this far:  There wasn't any clipping on any beams going to either the WFS or the MC REFL PD, only the beam going to the camera.

  15274   Fri Mar 13 12:48:47 2020 Larry WallaceUpdateelogCert Renewal

Updated the cert in /etc/httpd/ssl. The new cert is good until March 12, 2022.

  13683   Thu Mar 15 16:00:25 2018 Larry WallaceSummaryComputersCert renewal for NODUS

The cert for nodus has been renewed for another 2 years.

The following is the basic procedure for getting a new cert: (Note certs are only good for two years as of 2018)
openssl req -sha256 -nodes -newkey rsa:2048 -keyout nodus.ligo.caltech.edu.key -out nodus.ligo.caltech.edu.csr
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CaliforniaLocality Name (eg, city) []:Pasadena
Organization Name (eg, company) [Internet Widgits Pty Ltd]:California Institute of Technology
Organizational Unit Name (eg, section) []:LIGO
Common Name (eg, YOUR name) []:nodus.ligo.caltech.edu

Leave the e-mail address, challenge password and optional company name blank. A new private key will be generated.
chown root nodus.ligo.caltech.edu.key
chgrp root nodus.ligo.caltech.edu.key
chmod 0600 nodus.ligo.caltech.edu.key

The nodus.ligo.caltech.edu.csr file is what is sent in for the cert.
This file should be sent to either ryan@ligo.caltech.edu or security@caltech.edu and copy wallace_l@ligo.caltech.edu.

A URL llink with the new cert to be downloaded will be sent to the requestor.

Once the files are downloaded, the new cert and intermediate cert, they can be copied and renamed.

The PEM-encoded host certificate by itself is saved at:

  /etc/httpd/ssl/nodus.ligo.caltech.edu.crt

The nodus.ligo.caltech.edu.key file should be in the same directory or whichever directory is indicated in the ssl.conf located in /etc/httpd/conf.d/  directory.

httpd will need to be restarted in order for it to see the new cert.

 

  5831   Mon Nov 7 14:58:17 2011 steveUpdateGeneralChamber illuminator remote switches installed

nullQuote:

I'm looking for an ether net based  power switch for turning lights on and off for the vacuum system from MEDM screen.  This is what I found

Jamie please take a look at it.

 

 

 I installed 4 remote AC power on/off strip at

1Y1   for the Vertex area 4 chamber illuminating lights ( CIL )

1Y3   for HV ps for PZT steering mirrors that should be interlocked with P1 pressure gauge. Power off above 3 mTorr

1Y4   for  ETMY CILs,

1X9   for ETMX CILs

I need one volunteer to help me to make MEDM screen and connect the network to the switches.

  5212   Fri Aug 12 16:52:49 2011 steveUpdateGeneralChamber illuminator switch

I'm looking for an ether net based  power switch for turning lights on and off for the vacuum system from MEDM screen.  This is what I found

Jamie please take a look at it.

 

 

  309   Mon Feb 11 22:44:29 2008 robConfigurationDAQChange in channel trending on C1SUS2

I removed the MC2 optical lever related channels from trends, and the SRM POUT and YOUT (as these are redundant if we're also trending PERROR and YERROR). I did this because the c1susvme2 processor was having bursts of un-syncy lateness every ~15 seconds or so, and I suspected this might interfere with locking activities. This behaviour appears to have been happening for a month or so, and has been getting steadily worse. Rebooting did not fix the issue, but it appears that removing some trends has actually helped. Attached is a 50 day trend of the c1susvme2 sync-fe monitor.
  693   Fri Jul 18 12:24:15 2008 josephb, EricConfigurationCamerasChanged Lenses on GC750 at ETMX
We removed the giant TV zoom lens and replaced it with a much smaller fixed zoom lens. Currently it views the entire optic. We have another (also small) zoom lens which focuses much better on the spot itself. With how far back the camera is currently placed, neither of these fixed zoom lenses can touch or hit the view port or the chamber while still attached to camera and mount, even using all of the mount's motion range. So this should be less of a safety issue.

Ideally, we'd like to get some images of the full optic (including osems and so forth) with the X-arm locked, and then use the higher zoom lens while still locked, to get images we can use to calibrate the x and y length scales.
  26   Mon Oct 29 12:20:15 2007 waldmanConfigurationOMCChanged OMS filters
I changed the OMS configuration so that some of the OMC-SUS LED channels go to a breakout box so that we can input the PDH error signal. After lunch, we will try to lock the cavity with a PDH error signal and digital filters. Then its on to dither locked stuff. Note that this LED business will have to be changed back some day. For now, it should be extremely visible because there are dangling cables and a hack job interface lying around.
  5433   Fri Sep 16 14:43:43 2011 SureshUpdateComputer Scripts / ProgramsChanged c1ioo model and restarted fb

I had to change the c1ioo model and restart the fb since the paths allowing us to select various signals to demodulate using the lockins were not correct. The signal selection vector was not flexible enough to permit us to select the signals to demod.

fb was restarted twice at following times.  The changes have been commited to the svn.

Fri Sep 16 13:35:47 PDT 2011

Fri Sep 16 14:36:21 PDT 2011


 

ELOG V3.1.3-