40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 236 of 348 Not logged in
ID Date Author Type Category Subject
11474   Sat Aug 1 17:04:29 2015 EveUpdateSummary PagesStates and Triggers in SPs

I've added states to the summary pages to only show data for times at which one certain channel is above a specified threshold. So far, I've incorporated states for the IOO tab to show when the mode cleaner is locked.

You can see these changes implemented in the IOO tab of my personal summary pages for June 30: https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/ioo/.

I've written a description of how to add states to summary pages here: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#How_to_Define_and_Implement_States.

4472   Wed Mar 30 21:46:10 2011 Aidan, KiwamuUpdateGreen LockingStates of the Green beat note

The attached table shows the amplitude of the green beat note when the end laser was in various states. We can increase the beat note amplitude dramatically by switching to a different states.

State 1
C1:GCX-GRN_REFL_DC:             638 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    950 avg counts (zero = -794 counts)
amplitude of beat note:            -23dBm (after PD + amps) (f ~ 30 MHz)?
C1:GCX-SLOW_SERVO2_OUT:            318 counts

State 2
C1:GCX-GRN_REFL_DC:             180 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1270 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1700 avg counts (zero = -794 counts)
amplitude of beat note:            -7dBm (after PD + amps) f = 60MHz
amplitude of beat note:            0dBm (after PD + amps) f = 30MHz
C1:GCX-SLOW_SERVO2_OUT:            290 counts

State 3
C1:GCX-GRN_REFL_DC:             220 counts
C1:GCV-XARM_BEAT_DC: (PSL blocked)    1120 avg counts (zero = -794 counts)
C1:GCV-XARM_BEAT_DC: (PSL unblocked)    1520 avg counts (zero = -794 counts)
amplitude of beat note:            0dBm (after PD + amps) f = 15MHz
C1:GCX-SLOW_SERVO2_OUT:            305 counts

PSL temp = ??
C1:PSL-FSS_SLOWM = -3.524

13893   Fri May 25 14:55:33 2018 Jon RichardsonUpdateCamerasStatus of GigE Camera Software Fixes

There is an effort to switch to an all-digital system for the GigE camera feeds similar to the one running at LLO, which uses Joe Betzwieser's custom SnapPy package to interface with the cameras in Python and aggregate their feeds into a fancy GUI. Joe's code is a SWIG-wrapping of the commercial camera-driver API, Pylon, from Basler. The wrapping allows the low-level camera driver methods to be called from within Python, and their feeds are forwarded to a gstreamer stream also initiated from within Python. The problem is that his wrapping (and the underlying Pylon software itself) is only runnable on an older version of Ubuntu. Efforts to run his software on newer distributions at the 40m have failed.

I'm working on a fix to essentially rewrite his high-level SnapPy code (generators of GUIs, etc.) to use the newest version of Pylon (pylon5) to interface at a low level with the cameras. I discovered that since the last attempt to digitize the camera system, Basler has released their own official version of a Python wrapping for Pylon on github (PyPylon).

Progress so far:

• I've installed from source the newest version of Pylon, pylon5.0.12 on the SL7 machine (rossa). I chose that machine because LIGO is migrating to Scientific Linux, but I think this will also work for any distribution.
• I've installed from source the the newest, official Python wrapping of the Basler Pylon software, pypylon.
• I've tested the pypylon package and confirmed it can run our cameras.

The next and final step is to modify Joe's SnapPy package to import pypylon instead of his custom wrapping of an older version of the camera software, and update all of the Pylon calls to use the new methods. I'll hopefully get back to this early next week.

410   Thu Apr 3 18:33:17 2008 AndreySummaryEnvironmentStatus of Weather Station

During the last two days some things related to weather station have been improved.

1) Startup file for the computer (processor) 'c1pem1' was changed so that now 'c1pem1' can be rebooted from "Linux1". Computer 'c1pem1' is responsible for communicating data between 'Weather Monitor' and control UNIX machines. Before April 1st it was impossible to reboot the computer 'c1pem1'. Now 'c1pem1' runs without difficulties.

2) It was determined that some ethernet cables of category "cat 5" were bad. I replaced one short cat 5 cable between 'c1pem1' and 'network-switch board' in the neighboring computer rack, and I still need to replace the internet ending of another long (~20 meters) cat 5 cable after Alex Ivanov will bring the tool for that.

3) 'Weather monitor' and 'WeatherLink' are temporarily moved away from their "nested" positions on the north wall, and they are now in the proximity of processor 'c1pem1'. Thus the signal about "Inside Temperature" goes into 'c1pem1' computer without any additional ethernet cables, and "inside temperature" is correctly displayed on the "Checklist" adl. MEDM screen on the control UNIX machines. The cable with a signal from the roof sensors (which might be dead due their 7-year age) is temporarily disconnected from the 'Weather Monitor'.

Result: 'Weather Monitor' and computer (processsor) 'c1pem1' are alive, they communicate reasonable "Inside Temperature" to the control UNIX-machines.

The fate of the outside sensors is currently unknown, I plan to go to the roof together with Mr. Steve Vass tomorrow and try to determine what should be done with them.

I am also writing (right now) a wiki-40 page which explains what is the "Weather Station" and what is its status.
10119   Wed Jul 2 11:32:44 2014 Jenne, TaraVUpdatePEMStatus of seismometer stations, Yend Guralp moved

[Jenne, TaraV]

We had a look this morning at the status of the seismometer array, so that we can get it all put together. While we were looking at the Guralp at the Yend, we noticed that it was pointing the wrong way.  The North-South nubbins were pointed East-West, so X and Y coming out of the seismometer were backward.

To fix the Yend's Guralp, we powered off the Guralp readout box, rotated the seismometer, re-leveled it, and then turned the power back on.  Now X from the seismometer lines up with the X data channel, and similarly for Y.

The Yend Guralp has all of the cabling needed, and is installed on the granite slab.  This seismometer doesn't need any more work for now.  When we get around to it, we'll need to do some kind of thermal insulation, but other than that, it's good to go.

The Xend will also have a Guralp (Zach still has it in the Gyro lab for now).  We have the long cable that should go from the readout box to the slab that we'll need to put into the cable tray.  The short cable from the slab's plate to the seismometer is already in place.  For this seismometer, we should just need to plop the instrument in place and lay the cable in the overhead cable trays.  We should also remove the now obsolete STS-2 cable while we're doing that.  So, the Xend seismometer station doesn't need too much work.

The corner station will need more work.  Zach made for us the long cable, although he still has it in the Gyro lab, so when we get the seismometer and cable back, we'll need to lay that cable in the overhead trays.  The short cable from the slab's plate to the seismometer does not exist yet.  We want to make sure that we can feed the finished cable and connector through the hole in the slab, and then we'll solder it up out here on the EE bench.  I think this is how Den was doing things.  If not, we'll have to do the soldering in-situ, which we don't want.  So, for the corner station, we need to make the short cable, lay the long cable, get the T-240 back from Zach and put it on the slab, re-install the readout box that Zach has, etc, etc.  We should also make sure that the spaghetti pot fits on the slab, underneath the piece of metal that's sticking out over the slab.  We think that it's the same amount of clearance that the Yend pot has, so it should be okay, but we'll check.  The O-ring seems to be sitting on the MC2 chamber, so we should remember that.

Neither the Xend nor the corner station had the yellow dog clamps, so we'll have to figure out where Den / Steve have hidden them.

EDIT:  We have checked, and the Guralp connector, which is larger than the Trillium connector, fits through the hole in the slab (with some disassembly), so we can solder together the short cable out here on the EE bench, and install it separately.  Eeeeexxxxxcelllent.

2591   Thu Feb 11 18:33:54 2010 josephb, alexUpdateComputersStatus of the IP change over

A few machines have still not been changed over, including a few laptops, mafalda, ottavia, and c0rga.

All the front ends have been changed over.

fb40m died during a reboot and was replaced with a spare Sun blade 1000 that Larry had.  We had to swap in our old hard drive and memory.

All the front ends, belladonna, aldabella, and the control room machines have been switched over. Nodus was changed over after we realized we hosed the elog and svn by switching linux1's IP.

At this point, 90% of the machines seem to be working, although c0daqawg seems to be having some issues with its startup.cmd code.

2593   Thu Feb 11 19:20:44 2010 ranaUpdateComputersStatus of the IP change over

### After Joe left:

1. Turned on op440m and returned him his keyboard and mouse.
2. Damped MC2.
3. Opened PSL shutter - locked PMC, FSS,
4. Started StripTool displays on op540m.
5. op340m doesn't respond to ping from anyone.
6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
7. ASS wouldn't come up - it doesn't know who linux1 is.
8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.

2594   Fri Feb 12 11:44:11 2010 josephbUpdateComputersStatus of the IP change over

Quote:

### After Joe left:

1. Turned on op440m and returned him his keyboard and mouse.
2. Damped MC2.
3. Opened PSL shutter - locked PMC, FSS,
4. Started StripTool displays on op540m.
5. op340m doesn't respond to ping from anyone.
6. started FSS  SLOW and RCPID scripts on op540 - need to kill and restart on op430m.
7. ASS wouldn't come up - it doesn't know who linux1 is.
8. MC autolocker wouldn't run on op540m because of a perl module issue, started it on op440m - it needs to be killed and restarted on op430m.
9. probably mafalda, linux2, and op430m need some attention - they are all in the same rack.

As of 7:18 PM, the MC is locked and the PSL seems normal + all suspensions are damped and the ELOG is back up as well as the SVN.

5) op340m has had its hosts table and other network files updated.  I also removed its outdated hosts.deny file which was causing some issues with ssh.

6) On op340m I started FSSSlowServo, with "nohup ./FSSSlowServo", after killing it on op540m.

I also kill RCthermalPID.pl, and started with "nohup ./RCthermalPID.pl" on op540m.

7) c1ass is fixed now.  There was a typo in the resolv.conf file (namerserver -> nameserver) which has been fixed.  It is now using the DNS server running on linux1 for all its host name needs.

8) I killed the autlockMCmain40m process running on op440m, modified the script to run on op340m, logged into op340m, went to /cvs/cds/caltech/scripts/MC and ran nohup ./autolockMCmain40m

9) Linux2 does not look like it has not been connected for awhile and its wasn't connected when we started the IP change over yesterday.  Is it supposed to still be in use?  If so, I can hook it up fairly easily.  op340m, as noted earlier, has been switched over.  Mafalda has been switched over.

10) c0rga has now been switched over.

11) aldabella, the vacuum laptop has had its starting environment variables tweaked (in the /home/controls/.cshrc file) so that it looks on the 192.168.113 network instead of the 131.215.113.  This should mean Steve will not have any more trouble starting up his vacuum control screen.

12) Ottavia has been switched over.

13) At this time, only the GPIB devices and a few laptops remain to get switched over.

627   Wed Jul 2 19:15:52 2008 AlbertoUpdateGeneralStatus of the alignment of the NPRO beam for the Absolute Length Measurement
Today I've tried to bring the frequency of the NPRO laser close enough to that of the IFO beam so that the beat between the two beams can be at a detectable frequency for the photodiode. The way I've been changing the frequency is by the NPRO's temperature control on its driver.

Looking at the signal from the AS OSA should enable us to monitor the direction in which the frequency is changing. Every time the resonances of the IFO beam and of the NPRO beam overlap, we know that the frequencies of the two beams are some FSR of the OSA away from each other. At the overlapping of the resonances, if the difference of frequency is within the detectable range of the photodiode, we should see a peak in the network/spectrum analyzer.

This way turned out not very easy in practice because from the AS OSA one can hardly distinguish the resonances of the primary beam from those of the secondary beam. The cause is mainly the flashing of the IFO beam at the AS port which produces a pattern of resonances of different amplitude. Also for some reason, triggering the output signal from the OSA at the oscilloscope doesn't work very well.

However, even if we didn't have these problems, I think that the two beams are not very well aligned, at least not anymore. I'm attaching some pictures from the AS port. The bright spot on the left is the NPRO beam and the one in the center which flashes is the IFO beam. We probably need some more work in the alignment of the NRPO beam.
Attachment 1: DSC_0156.JPG
Attachment 2: DSC_0158.JPG
628   Thu Jul 3 11:53:30 2008 KojiUpdateGeneralStatus of the alignment of the NPRO beam for the Absolute Length Measurement
The method itself looked fine.

Use of the one arm configuration will make the work easier as constant power at the AS port is obtained.
How much is the FSR of the OSA?

Apparently the alignment is not good any more as Alberto pointed. Everytime you touch the flipper you'd better to adjust it. Then, if necessary, adjust the injection steerings.

If the PSL beam is blocked, only the injection beam appears at the optical ports. The spot is obtained at the AS port and the SY port (REFL) at the same time. I recommend to confirm the transmittion to the SY port too by the CDD, the card, and whatever. Note that this may be difficult because this will have the beam power of below 1 mW.

 Quote: Alberto> Today I've tried to bring the frequency of the NPRO laser ...
11461   Wed Jul 29 21:40:39 2015 KojiSummaryCDSStatus of the frame data syncing

The trend data hasn't been synced with LDAS since Jul 27 5AM local.

40m:

controls@nodus|minute > pwd /frames/trend/minute controls@nodus|minute > ls -l 11222 | tail total 590432 -rw-r--r-- 1 controls controls 35758781 Jul 29 11:59 C-M-1122228000-3600.gwf -rw-r--r-- 1 controls controls 35501472 Jul 29 12:59 C-M-1122231600-3600.gwf -rw-r--r-- 1 controls controls 35296271 Jul 29 13:59 C-M-1122235200-3600.gwf -rw-r--r-- 1 controls controls 35459901 Jul 29 14:59 C-M-1122238800-3600.gwf -rw-r--r-- 1 controls controls 35550346 Jul 29 15:59 C-M-1122242400-3600.gwf -rw-r--r-- 1 controls controls 35699944 Jul 29 16:59 C-M-1122246000-3600.gwf -rw-r--r-- 1 controls controls 35549480 Jul 29 17:59 C-M-1122249600-3600.gwf -rw-r--r-- 1 controls controls 35481070 Jul 29 18:59 C-M-1122253200-3600.gwf -rw-r--r-- 1 controls controls 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf -rw-r--r-- 1 controls controls 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf

LDAS Minute trend:

[koji.arai@ldas-pcdev3 C-M-11]$pwd /archive/frames/trend/minute-trend/40m/C-M-11 [koji.arai@ldas-pcdev3 C-M-11]$ ls -l | tail -rw-r--r-- 1 1001 1001 35488497 Jul 26 19:59 C-M-1121997600-3600.gwf -rw-r--r-- 1 1001 1001 35477333 Jul 26 21:00 C-M-1122001200-3600.gwf -rw-r--r-- 1 1001 1001 35498259 Jul 26 21:59 C-M-1122004800-3600.gwf -rw-r--r-- 1 1001 1001 35509729 Jul 26 22:59 C-M-1122008400-3600.gwf -rw-r--r-- 1 1001 1001 35472432 Jul 26 23:59 C-M-1122012000-3600.gwf -rw-r--r-- 1 1001 1001 35472230 Jul 27 00:59 C-M-1122015600-3600.gwf -rw-r--r-- 1 1001 1001 35468199 Jul 27 01:59 C-M-1122019200-3600.gwf -rw-r--r-- 1 1001 1001 35461729 Jul 27 02:59 C-M-1122022800-3600.gwf -rw-r--r-- 1 1001 1001 35486755 Jul 27 03:59 C-M-1122026400-3600.gwf -rw-r--r-- 1 1001 1001 35467084 Jul 27 04:59 C-M-1122030000-3600.gwf

11465   Thu Jul 30 11:47:54 2015 KojiSummaryCDSStatus of the frame data syncing

Today it was synced at 5AM but that was all.

40m:

controls@nodus|minute > pwd /frames/trend/minute controls@nodus|minute > ls -l 11222|tail -rw-r--r-- 1 controls controls 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf -rw-r--r-- 1 controls controls 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf -rw-r--r-- 1 controls controls 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf -rw-r--r-- 1 controls controls 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf -rw-r--r-- 1 controls controls 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf -rw-r--r-- 1 controls controls 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf -rw-r--r-- 1 controls controls 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf -rw-r--r-- 1 controls controls 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf -rw-r--r-- 1 controls controls 35643898 Jul 30 05:59 C-M-1122292800-3600.gwf -rw-r--r-- 1 controls controls 35704049 Jul 30 06:59 C-M-1122296400-3600.gwf controls@nodus|minute > ls -l 11223|tail total 139616 -rw-r--r-- 1 controls controls 35696854 Jul 30 08:02 C-M-1122300000-3600.gwf -rw-r--r-- 1 controls controls 35675136 Jul 30 08:59 C-M-1122303600-3600.gwf -rw-r--r-- 1 controls controls 35701754 Jul 30 09:59 C-M-1122307200-3600.gwf -rw-r--r-- 1 controls controls 35718038 Jul 30 10:59 C-M-1122310800-3600.gwf

LDAS Minute trend:

[koji.arai@ldas-pcdev3 C-M-11]$pwd /archive/frames/trend/minute-trend/40m/C-M-11 [koji.arai@ldas-pcdev3 C-M-11]$ ls -l |tail -rw-r--r-- 1 1001 1001 35518238 Jul 29 19:59 C-M-1122256800-3600.gwf -rw-r--r-- 1 1001 1001 35514930 Jul 29 20:59 C-M-1122260400-3600.gwf -rw-r--r-- 1 1001 1001 35521183 Jul 29 21:59 C-M-1122264000-3600.gwf -rw-r--r-- 1 1001 1001 35509281 Jul 29 22:59 C-M-1122267600-3600.gwf -rw-r--r-- 1 1001 1001 35511705 Jul 29 23:59 C-M-1122271200-3600.gwf -rw-r--r-- 1 1001 1001 35809690 Jul 30 00:59 C-M-1122274800-3600.gwf -rw-r--r-- 1 1001 1001 35752082 Jul 30 01:59 C-M-1122278400-3600.gwf -rw-r--r-- 1 1001 1001 35927246 Jul 30 02:59 C-M-1122282000-3600.gwf -rw-r--r-- 1 1001 1001 35775843 Jul 30 03:59 C-M-1122285600-3600.gwf -rw-r--r-- 1 1001 1001 35648583 Jul 30 04:59 C-M-1122289200-3600.gwf

11957   Thu Jan 28 14:54:49 2016 ericqUpdateLSCStatus of the green PDH circuits

Yesterday, I uploaded some EAGLE schematic files and a LISO source file for the green PDH servo electronics to the 40m LISO git repository. In doing so, I realized that the DCC document for the X box (D1400293) was not updated at the end of the electronics work we did in Aug/Sep 2014. This is entirely my fault.

The Y box document (D1400294) is currently accurate.

The missing information is that, as I posted In ELOG 10457, I ended up destroying our original X box, and replaced it with a spare from the ATF. It was restuffed to match the Y end box pretty much exactly. We will update the X circuit DCC page with an accurate schematic and photo.

Gautam tells me that he and Rana were looking at the outdated schematic and thinking about improvements, but at least some of this was already done back in 2014 (specifically, the resistors used to specify the AD8336 preamp gain were changed).

11958   Thu Jan 28 19:10:16 2016 gautamUpdateLSCStatus of the green PDH circuits

 Quote: We will update the X circuit DCC page with an accurate schematic and photo.

I've uploaded reasonably high-resolution photographs of the uPDH box for the X-end and Y-end on their respective wiki pages. I've uploaded two photos for each box, one of the circuit board (I checked that these photos are clear enough that we can zoom in and read off component values if necessary), and one of the box with the peripherals not integrated into the circuit board (i.e. the minicircuits mixer ZAD-8+ and the little Pomona box that is an LP filter for the output from the mixer). Since I pulled the boxes out, I thought it might not be a bad idea to measure the TFs of these Pomona boxes and make sure nothing weird is going on, I'll put up some plots later.

Rana and I discussed some things to look at earlier today:

• Check the voltages at test-points 1,7 and 9, and make sure they are as expected
• Change the gain of the pre-amp from x2 to x4 - as Eric mentioned in the previous elog, these had already been swapped out. Right now a 600 ohm and 200 ohm resistor pair are being used, so the preamp gain is x4, which should be okay as per the datasheet of the AD8336 VGA amplifier (although the "recommended" resistor pairing is 301 ohm and 100 ohm, but I don't think this is critical?
• Track down the reason for the difference in Gain settings at the X and Y ends - typically, the X-end PDH box "Gain" knob is set to 10, while that for the Y-end is set to ~4. The fact that the PZT actuator gain for the Y-end is ~5 times larger than for the X-end doesn't seem to account for all of this. As per the attached plot, the difference in gain between the ends is ~35 dB, which is a factor of 50!

I also did a quick check of the behaviour of the Servo Gain potentiometer by checking the resistance at various positions of the knob - we had suspected that the potentiometer may be logarithmic, but I found that it was in fact linear. I'll put up a plot of the gain as a function of the Servo Gain knob position soon,(plot added) along with results from the other checks.

While disassembling the setup at the X-end to get the PDH box out, I noticed that the signal from the LO is going to the mixer through a Pomona box (no such Pomona box is used at the Y-end). I opened it up and found that it contains just a pair of capacitors in parallel, so it's a phase shifter?. The LO signal also goes through an attenuator. The mixer in both boxes is a ZAD-8+, so why is this part of the setup different?

Both PDH boxes are not hooked up at the moment, I will restore the setups at both ends after running a few more checks on the boxes...

Attachment 1: Servo_gain_calibration.pdf
10697   Tue Nov 11 19:46:35 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

The new nodus machine is being brought to life; until installation is finished and everything is fine, the old nodus will be unharmed. For future reference:

New Nodus hardware:

CPU: 2x Intel Xeon X5650

Total 12 GB

Current software situation and current issues :

1) Ubuntu Server 12.04.5 is installed and updated

2) The usual 'controls' user is present, with UID=1001 and GID=1001

3) Packages installed: nfs-common, rpcbind, ntp, dokuwiki, apache2, php5, openssh-server, elog-2.8.0-2 [from source], make, gcc, libssl-dev [dependencies for elog], subversion

4) Network: interface eth0 is set up (static IP and configuration in /etc/network/interfaces); eth1 is recognized and added, but not configured yet

5) DNS: configuration is in /etc/resolvconf/resolv.conf.d/base (since /etc/resolv.conf is overwritten by the resolvconf program using the 'base' database)

6) ntp is installed and (presumably) configured, but ntpd misbehaves (namely, all the servers are found, but a

tail /var/log/syslog


shows that no actual synchronization is performed, and the daemon keeps

Listening on routing socket on fd #22 for interface updates


7) dokuwiki apache2 php subversion elog are installed but not configured yet (I need info about their current state, configuration and whereabouts)

8) I copied and merged the old nodus' .bashrc and .cshrc into new nodus' .bashrc, need to know if something has to be added

9) backup frames, backup user dirs and 40m public_html are not set yet, as in #7

Is there something missing?

If there is something missing from here (ligo/cds software, smartmontools/hddtemp and similar, or anything else) tell me and I'll set them up.

10772   Wed Dec 10 14:22:37 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

[Diego, Steve]

We ran a Cat 6+ Ethernet cable from the 1X7 rack (where the new nodus is located) to the fast GC switch in the control room rack; now I will learn how to setup the 'outside world' network, iptables, and the like.

I remind that the current hardware/software status is posted in elog 10697 ; if additions or corrections are needed, let me know.

After I check a couple of things, we can use the new nodus (which is currently known in the martian network as rosalba) as a local test to see that everything is working. After that (and, mostly, after I'll have the network working), we will sync the data from the old nodus to the new one and make the switch.

10793   Fri Dec 12 19:38:49 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

 Quote: [Diego, Steve] We ran a Cat 6+ Ethernet cable from the 1X7 rack (where the new nodus is located) to the fast GC switch in the control room rack; now I will learn how to setup the 'outside world' network, iptables, and the like.   I remind that the current hardware/software status is posted in elog 10697 ; if additions or corrections are needed, let me know.   After I check a couple of things, we can use the new nodus (which is currently known in the martian network as rosalba) as a local test to see that everything is working. After that (and, mostly, after I'll have the network working), we will sync the data from the old nodus to the new one and make the switch.

[Diego, EricQ]

Update: work is almost completed; the old nodus is still online, as I don't feel confident to make the switch and leave it on its own for the weekend. However, the new nodus is online with the IP address 131.215.114.87, so everyone can check that everything works. From my tests I can say that:

After everything will be in place, I will save every reasonably important configuration file of nodus into the svn.

I remind that every change made while accessing the 131.215.114.87 machine will be purged during the sync&switch

10797   Mon Dec 15 12:53:13 2014 ericqUpdateComputer Scripts / ProgramsStatus of the new nodus

Nodus (solaris) is dead, long live Nodus (ubuntu).

Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine.

SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

10798   Mon Dec 15 16:27:57 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

 Quote: Nodus (solaris) is dead, long live Nodus (ubuntu). Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine.  SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

[Diego, EricQ]

SSL, https and backups are now working too!

A backup of nodus's configuration (with some explaining) will be done soon.

10805   Tue Dec 16 20:49:25 2014 diegoUpdateComputer Scripts / ProgramsStatus of the new nodus

Quote:

 Quote: Nodus (solaris) is dead, long live Nodus (ubuntu). Diego and I are smoothing out the Kinks as they appear, but the ELOG is running smoothly on our new machine.  SVN is working, but your checkouts may complain because they expect https, and we haven't turned SSL on yet...

[Diego, EricQ]

SSL, https and backups are now working too!

A backup of nodus's configuration (with some explaining) will be done soon.

Nodus should be visible again from outside the Caltech Network; I added some basic configuration for postfix and smartmontools; configuration files and instructions for everything are in the svn in the nodus_config folder

3471   Wed Aug 25 15:55:33 2010 josephbUpdateelogStaying with 2.7.5 until passwords sorted out

Turns out the elog version 2.8.0 uses a different encryption method than 2.7.5.  This mean the encrypted passwords stored in the elogd.cfg don't work with the new code.  elogd includes functionality to generate encrypted passwords, but unfortunately I don't know the administration passwords for some of the logbooks.  So I'm going to leave 2.7.5 running until I can get those added properly to the 2.8.0 cfg file.

2900   Sat May 8 03:09:15 2010 KojiUpdateIOOSteering around MC

After the MZ-removal work:

- I found that the input steering (IM1) was right handed. This was different from the CAD layout. This was the main reason why the MC trans was kicked by the mount.
- Removed the mount from the post and converted it to a keft handed.
- Align IM1 so that we can get TEM00 lock. Align IM1 further.

- After the IM1 was optimized for the TEM00, move the periscope mirrors to have best alignment.

- Checked the beam spot positions. They looks quite good (MC2 is not the matter now).

C1:SUS-MC1_ULPIT_GAIN = 0.998053
C1:SUS-MC1_ULYAW_GAIN = 0.992942
C1:SUS-MC2_ULPIT_GAIN = 1.00856
C1:SUS-MC2_ULYAW_GAIN = 1.04443
C1:SUS-MC3_ULPIT_GAIN = 0.99868
C1:SUS-MC3_ULYAW_GAIN = 1.00041

17505   Mon Mar 13 15:37:13 2023 AlexUpdateIMCStep Response of newly diagonalizing YAW output matrix

From the work that Anchal has completed for diagnolizing the YAW ouput matrix, a step response was taken of this new matrix using our previous methodolgies and the following results:

The step response can be seen plotted in attachment 1. The off diagonal terms of this new matrix sum to 1.24, which is a large decrease from the current matrix and the matrices that were tested from our previous step responses.

Tomohiro and I are now currently working futher to configure the UGF's for YAW given this new output matrix.

UPDATE:

Tomohiro and I have completed testing the YAW Sensor outputs with broadband noise injection and have confirmed that gains currently set on each filter module (which is 1.0 for WFS1, WFS2, and MC Trans) provides us with adequate UGF's. As seen bellow in attachment 2-3, WFS1 and WFS2 have UGF's between 2 and 3 Hz. MC Trans can be seen in attachment 4 and has been confirmed to have a UGF around 0.1 Hz.

Finally, attachment 5 displays the off diagnolized sums and uncertainties for each of our previous step response results and the newest result (labeled "new") for Anchal's OUTPUT YAW matrix. The first graph in blue displays the overall sum and uncertainty related to each step response taken. Then in the following 3 plots, the sum's and uncertaintes for each sensor are displayed individually for each step response test.

For reference:

New: corresponds to Anchal's YAW OUPUT MATRIX

D0: refers to the previously implemented matrix, prior to any testint or updates

D1: refers to the matrix that was computed based off of the first test Tomohiro and I performed

D2: refers to the matrix computed as a secondary result from D1. This matrix was thought to provide a lower off diagonal sum, but did not.

This thoroughly displays our results such that the newly computed matrix from Anchal is much more diagnolized then that of the step response matrices Tomohiro and I have computed.

Attachment 1: step_response_YAW_130323.pdf
Attachment 2: WFS1_YAW_OLTF_NI.pdf
Attachment 3: WFS2_YAW_OLTF_NI.pdf
Attachment 4: MC2_YAW_OLTF_NI.pdf
Attachment 5: Mar13_Dfactor.pdf
17500   Thu Mar 9 10:29:15 2023 AlexUpdateIMCStep response test on MC1, MC2, and MC3 YAW

Tomohiro, Anchal and I completed the following processs for acquiring a new Output Yaw matrix for the "C1IOO_WFS_OUTMATRIX".

To did this by following the same process in 17493 but instead of adding our offsets in the WFS1, WFS2 and MC Trans filter banks, offsets were added at the end of the feedback loop at the optics, MC1, MC2 and MC3 YAW.

Optimal offset values were found such that the offset change did not disrupt the output WFS transmission signal by more than about a one thousand counts. Each limit was set to come close to this limit.

Our final offset values were:

 Optic Offset Value MC1 55 MC2 15 MC3 35

The step response was than observed in Diaggui, but the entire 800 s run was unable to be viewed at once. We then utilized our python script from the previous step response data that we took to develop the following:

The measured response from stepping the optics was:

$\begin{pmatrix} 1.31\pm0.24 & 54.2\pm1.3 & -0.28\pm0.03\\ -2.13\pm0.23 & -20.7\pm1.6 & 1.11\pm0.03\\ 1.82\pm0.27 & -25.8\pm1.5 & 0.16\pm0.03\\ \end{pmatrix} \begin{pmatrix} MC_{1Y}\\ MC_{2Y}\\ MC_{3Y}\\ \end{pmatrix} = \begin{pmatrix} WFS_{1Y}\\ WFS_{2Y}\\ MC_{2Y-TRANS}\\ \end{pmatrix}$

*The values in this matrix represent the number of counts/offset count. Thus all ovalues found from the step response were divided by the number of counts on each offset.

To find the new yaw matrix, we then take the inverse of the step response output matrix to get:

$\begin{pmatrix} MC_{1Y}\\ MC_{2Y}\\ MC_{3Y}\\ \end{pmatrix} = \begin{pmatrix} 0.188 & -0.009 & 0.403 \\ 0.017 & 0.005 & -0.006 \\ 0.689 & 0.987 & 0.656 \end{pmatrix} \begin{pmatrix} WFS_{1Y}\\ WFS_{2Y}\\ MC_{2Y-TRANS}\\ \end{pmatrix}$

The results from the step response may also be seen graphically in attachment 1. The first plot shows all 3 response signals. Then each following plot shows the individual signals and the step responses overlayed for each one.

The plots also include horizontal lines that represent the average for the stepped signals and the average of the signal at rest along with shading for their associated uncertainties.

This was then tested in C1IOO_WFS_BASIS Yaw matrix, and at first did not work well. The WFS1 Yaw output would rail toward the limits. To fix this, the sign of the gain was flipped (from 0.5 to -0.5) which seemed to solve this issue.

This was then transmitted to the matrix to give:

$\begin{pmatrix} MC_{1Y}\\ MC_{2Y}\\ MC_{3Y}\\ \end{pmatrix} = \begin{pmatrix} -0.188 & -0.009 & 0.403 \\ - 0.017 & 0.005 & -0.006 \\ -0.689 & 0.987 & 0.656 \end{pmatrix} \begin{pmatrix} WFS_{1Y}\\ WFS_{2Y}\\ MC_{2Y-TRANS}\\ \end{pmatrix}$

This did not solve all issues, the overall ouput signals from the WFS filters still seemed to have large fluctuations. I then began adjusting the gains of the WFS1, WFS2 and MC Trans yaw output filters and achieved much steadier signals.

The following table describes the current best gain valuse for our Yaw matrix:

 Sensor Gain Value WFS1 YAW 5.94 WFS2 YAW 6.44 MC TRANS YAW 1.9

The results from our found matrix and gain changes can be seen on the left of attachement 2 that displays the ouputs on the Error Signal Monitor. The original output yaw matrix signals can be seen on the right hand side. There is work to still be done on adressing these issues, but overall this may be improved by some additional changes in the gains on each channel.

Attachment 1: step_response_080323.pdf
Attachment 2: Screenshot_2023-03-08_18-17-35.png
17503   Fri Mar 10 16:42:16 2023 TomohiroUpdateIMCStep response test on MC1, MC2, and MC3 YAW

Summary

• We compared the new output matrix with old one by the step response test.
• We focused on the off-diagonal components of the step response result to compare the output matrix.
• We found that the old one is relatively good to WFS1/2 and MC2_TRANS whereas the new one is useful only to WFS1.
• Also we found that the new output matrix made from the sensing matrix was not significantly better than the original one.

Purpose

Alex, Anchal, and I did the experiment to find out the better output matrix. We got the new output matrix from the step response test in 40m/17500, so we checked whether the output matrix is good or not.

Theory

We used the following method to check the output matrix. In the previous step response test, we applied the step offset to ExciteIn'' points, and measure the step response at SensOut'' points. These points are defined in Attatchment 4. From the test, we got the matrix $A$. Thus, we derived the new output matrix $O_1$ from taking the inverse of $A$$O_1 = A^{-1}$. If the new output matrix is well derived, the matrix can diagonalize the product of $A$ and $O_1$$A O_1 = \bf{I}$, where $\bf{I}$ is the identity matrix. $AO_1$ can be measured by the step response test from SensIn'' to SensOut.'' Therefore we checked the output matrix by measuring $AO_1$. We call the measured matrix $S_1 (\equiv A O_1)$ as a sensing matrix.

To evaluate that $S_1$ is diagonalized, we computed the sum of the absolute values of the off-diagonal components in $S_1$

$D_1 \equiv \sum_{j \neq k} \left| S_1 (j, k) \right| .$

Note that each column of the matrix was normalized by its diagonal component.

We tried to find out the better output matrix as the following method. We created new output matrix $O_2$ from $O_2 \equiv O_1 {S_1}^{-1}$, and did the same step response test with $O_2$. Then we got the new sensing matrix $S_2$. We computed the sum of the absolute values of the off-diagonal components in $S_2$$D_2$. We can get the relation $D_1 > D_2$ if $O_2$ is better than $O_1$. Therefore we compared $D_2$ with $D_1$.

Note: If $D_n$ and $D_{n+1}$ have the relation $D_n > D_{n+1} (\geq 0)$, the output matrix $O_n \equiv O_{n-1} {S_{n-1}}^{-1}$ will get better and better.

We also did the step response test with $O_0$, which is defined as the output matrix now used. Then we compare $D_0$ with $D_{1, 2}$.

Method

Before doing each step response test, we did the following processes:

• MC WFS relief for 60 secs with closed loops,
• turn off the WFS servo,
• turn off all the filters (WFS1/2: FM3, 4, 6; MC2-TRANS: FM1, 3, 4, 6),
• change the output matrix,
• set all the gain as unity,

We used the python script, toggleWFSoffsets.py, for testing the step response. The script is stored in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The time appling each step offset is set as 120 secs. $O_i~(i = 0, 1, 2)$ are specifically the following matrix:

$O_0 = \begin{pmatrix} -4.0940 & -3.0383 & 34.0917 \\ -0.1259 & 0.27008 & -16.081 \\ -7.1811 & 0.74271 & 28.9458 \end{pmatrix}$  $O_1 = \begin{pmatrix} 0.342 & 0.117 & 1.967 \\ -0.016 & 0.036 & 2.82 \\ 0.732 & -0.042 & 1.873 \end{pmatrix}$  $O_2 = \begin{pmatrix} 0.812 & -0.819 & -2.289 \\ -0.036 & 0.761 & 2.998 \\ 0.085 & 0.386 & 2.835 \end{pmatrix}$

Note: $O_1$ is different from [-0.188, -0.009, ...] in 40m/17500 because the previous calculation had a mistake.

The step response data is analyzed for making plot and calculating $O_{1, 2}$ and $D_{0, 1, 2}$ by the python script, /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/IOO_WFS_YAW_RESPONSE_TEST_100323.ipynb.

Result

The step response results for $S_{1, 2, 0}$ are represented in Attachment 1, 2, 3, respectively. In each plot, upper left shows all the data for WFS1 (solid green), WFS2 (solid blue), and MC2_TRANS (solid brown). Also upper right, lower left, and lower right shows the result of WFS1, WFS2, and MC2_TRANS, respectively. The plots except for the upper left have the applied step offset drawed by dashed line. The three step offsets were applied in the order of WFS1 (dashed green in the upper right), WFS2 (dashed blue in the lower left), and MC2_TRANS (dashed brown in the lower right). The high-frequency components of all the plots are removed with a second-order Butterworth low-pass filter and then plotted. Dotted line and its surrounding area show the mean value for each step response or existing offset without the step offset, and its standard deviation, respectively.

We summarize each plot:

• $S_1$

The matrix of $S_1$ is written from Attachment 1:

$S_1 = \begin{pmatrix} -140 \pm 10 & 90 \pm 10 & 290 \pm 10 \\ 2 \pm 1 & -32 \pm 1 & 28 \pm 1 \\ -9 \pm 7 & -40 \pm 7 & -234 \pm 7 \end{pmatrix} .$

Focusing on each column in $S_1$ and the plot, only the step response for WFS1 is well diagonalized. The result of $D_1$ is $D_1 = 5.6 \pm 0.8$. Note that all the sign of the step offset in Attachment 1 is negative because we set each gain of the filter as -1.

• $S_2$

The matrix of $S_2$ is written from Attachment 2:

$S_2 = \begin{pmatrix} 140 \pm 10 & 206 \pm 9 & -102 \pm 7 \\ 50 \pm 20 & 360 \pm 10 & -340 \pm 10 \\ -11 \pm 3 & -55 \pm 2 & 84 \pm 2 \end{pmatrix} .$

The output matrix $O_2$ has worse normalization to WFS1 than $O_1$ from comparing $S_2$ with $S_1$$D_2$ also gets worse value than $D_1$$D_2 = 6.4 \pm 0.4$.

• $S_0$

The matrix of $S_0$ is written from Attachment 3:

$S_0 = \begin{pmatrix} -1700 \pm 100 & -130 \pm 120 & 2100 \pm 100 \\ -240 \pm 80 & -1100 \pm 70 & 1440 \pm 60 \\ 110 \pm 160 & 200 \pm 100 & -1400 \pm 100 \end{pmatrix} .$

Although $S_0$ has relatively better normalization to WFS1 and 2 than $S_{1, 2}$, it is characterized by a large overall error. $D_0$ has minimum value with relatively large uncertainty: $D_0 = 3.1 \pm 0.7$.

Discussion

We compare each value $D_{1, 2, 0}$, which is plotted in the left of Attachment 5. From the figure, we can find $D_1$ and $D_2$ agree within the margin of error, and $D_0$ is significantly smaller than $D_1$ and $D_2$. Also we compare $D_{1, 2, 0}$ focusing on WFS1 column shown in the right of Attachment 5. $D_{1, 0}$ have almost the same value, and $D_2$ has slightly larger value than other. This result shows $O_0$ is relatively good to WFS1/2 and MC2_TRANS whereas $O_1$ is useful only to WFS1.

Attachment 1: step_response_YAW_S1_100323.pdf
Attachment 2: step_response_YAW_S2_100323.pdf
Attachment 3: step_response_YAW_S0_100323.pdf
Attachment 4: Mar10_FlowDiagram.pdf
Attachment 5: Mar10_Dfactor.pdf
17493   Mon Mar 6 13:03:37 2023 TomohiroUpdateIMCStep response test on WFS 1, 2 and MC2_TRANS YAW

Summary

• We do the step responce test on WFS 1, 2 and MC2_TRANS YAW for correcting the output matrix.
• We add each offset value to each YAW actuator in IMC, and measure the time-series of the signals.
• From the input offset value and the output values, we get the values in the output matrix.

Purpose

The purpose of the measurement is to correct the values in the output matrix between YAW actuator and YAW signals of WFS and MC2_TRANS.

Method

Alex, Anchal, and I did the following measurement. The method follows to the previous measurement held by Anchal in 40m/17311. Before we did the experiment, we took these actions.

• We reliefed MC SUS ASC Input values to zero
• We made the overall WFS gain to zero in C1IOO_WFS_MASTER window.
• We turned off (0; 0.8) FM3 filter of servo section in WFS1, 2_YAW and MC2_TRANS_YAW.
• We checked the ramp time is set as 2 s.

We set every offset value by monitoring the change in WFS and MC2 YAW signals due to the offset. The monitoring points are WFS1_IY_DQ, WFS2_IY_DQ, and MC_TRANS_Y_DQ. We got the offset values as listed. We also monitored TRANS_SUMFILT_OUTPUT because we check the transmitted light changes.

 Value Transmitted light WFS1_YAW 10,000 about 10 % reduction WFS2_YAW 7,000 almost nothing MC2_TRANS_YAW 7,000 about 10 % reduction

We used the python script toggleWFSoffsets.py to add the offset separately. The script is in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The averaging time is set as 120 s to reduce the influence of the dominant fluctuation by factor of 1/100. The dominant fluctuation has the frequency around 1 Hz.

For obtaining the time-series datas and caluclating the mean values of the changed WFS and MC2 YAW signals due to every offset, we created new python script named IOO_WFS_YAW_STEP_RESPONSE_TEST.py, which is saved in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The script uses the getdata function in cdsutils to get time-series data referring to GPS time.

We picked out a portion of the datas for step responce results. The selected time is [20 s, 120 s], [260 s, 360 s], and [500 s, 600 s]. Each time datas are averaged. The datas also have background offset, so the datas of time [140 s, 240 s], [380 s, 480 s], and [620 s, 720 s] are used to calculate the average of the background offset. The step responce results are obtained by the differential between the averaged datas in the picked out time and that of the background offset. And the results are normalized by the offset values.

The results make the matrix from injection points to measured points. The injection points are WFS1, 2_YAW and MC2_TRANS_YAW, thus the matrix is not the output matrix from the injection points to MC1, 2, 3_YAW. We get new output matrix by multiplying the inversed result matrix and the current output matrix.

Result

The Attachment 1 plots the time-series datas. For visibility and less file size, the figure is drawn with a reduced number of samples filtered by 2nd order Butterworth filter. We referenced to /measurements/AWS/YARM_WFS_DC_Sensitng_Matrix_New.ipynb to draw the figure.

The new output matrix is written here.

• Current matrix

$\begin{pmatrix} \mathrm{MC}_{1\mathrm{Y}} \\ \mathrm{MC}_{2\mathrm{Y}} \\ \mathrm{MC}_{3\mathrm{Y}} \end{pmatrix} = \begin{pmatrix} -4.4094 & -3.0383 & 34.0917 \\ -0.1259 & -0.27008 & -16.081 \\ -71811 & 0.74271 & 28.9458 \end{pmatrix} \begin{pmatrix} \mathrm{WFS}_1 \\ \mathrm{WFS}_2 \\ \mathrm{MC}_{2-\mathrm{TRANS}} \end{pmatrix}$

• New matrix

$\begin{pmatrix} \mathrm{MC}_{1\mathrm{Y}} \\ \mathrm{MC}_{2\mathrm{Y}} \\ \mathrm{MC}_{3\mathrm{Y}} \end{pmatrix} = \begin{pmatrix} -0.2702 & -0.2540 & -0.4758 \\ 0.2727 & 0.2545 & 0.4728 \\ -0.2645 & -0.2607 & -0.4748 \end{pmatrix} \begin{pmatrix} \mathrm{WFS}_1 \\ \mathrm{WFS}_2 \\ \mathrm{MC}_{2-\mathrm{TRANS}} \end{pmatrix}$

We temporarily replaced the new matrix from the current one. The loop was still stable and the matrix worked well. To know whether the matrix properly works or not, we will test the same step response to the new matrix. We will confirm that the measured matrix is diagonalized.

Attachment 1: step_response_060323.pdf
17496   Tue Mar 7 23:32:54 2023 ranaUpdateIMCStep response test on WFS 1, 2 and MC2_TRANS YAW

this measured Yaw matrix seems very different from the previous one. How can they really both be stable?

14649   Mon Jun 3 21:03:54 2019 MilindUpdateCamerasSteps to interact with GigE

The following steps summarize the steps to setting up and interacting with a GigE camera.

Launching the PylonViewerApp:

1. Open a new terminal using Ctrl + Alt + T on the keyboard.
2. Launch the app using the command pylon.

Using setup python scripts to interact with the GigE (a summary of the steps listed here and here)

1. Connect the GigE camera to the ethernet cable and record its IP address. If the IP address is not printed on the GigE, launch the PylonViewerApp and navigate to the "Tools" dropdown menu and select "pylon IP configurator" to be presented with a list of all connected cameras and their IP addresses.
2. To simply observe the camera feed, open a new terminal and run the following commands:
1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python camera_server.py -c C1-CAM-ETMX.ini  (only one config file is present currently and more will be added as more cameras are set up. The "Camera IP" in the  .ini file must match that determined in step 1). This starts the camera server.
3. Open a new tab (Ctrl + Shift + T on the keyboard) in the terminal. You should still be in the same directory as navigated to in step 2.1. Run the following command.
1. python camera_client.py -c C1-CAM-ETMX.ini
4. This should bring up a feed from the camera. Close at will.
5. To record a video file, repeat steps 1 and 2. Open a new tab as described in step 3. Then run the following command:
1. python camera_client_movie.py -c C1-CAM-ETMX.ini
6. Enter the full path to the file where you wish to save the movie in the prompt that appears. Use ./your_file_name_here.avi to save the the video in the working directory. Press Ctrl + C to stop recording. The recording can be played by navigating to the location where the recording is stored and running vlc your_file_name_here.avi.
7. To adjust the exposure setting of the camera, open a new terminal and run the command sitemap . This should bring up the medm display in Attachment #1. Click on the Video/Lights button highlighted in red and select GigE. Adjust the exposure value in the next window using the slider before starting the server in step 1. Adjusting the slider once the server is started causes the program to freeze. Also set the Snapshot channel C1:CAM-ETMX_SNAP to off as mentioned in elog 14037.

1. Automatic script to run the above steps.
2. Pre-determining the time duration of the recorded video.
3. Obtaining snapshots.

Attachment 1: sitemap.pdf
14654   Tue Jun 4 22:24:45 2019 MilindUpdateCamerasSteps to interact with GigE

Figured out how to get/grab frames by looking at the pypylon documenation as that turned out to be easier than modifying Jon's code. Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog). I will figure that out tomorrow and make a script suitable for Kruthi's usage (obtain a bunch of images with different exposure times). I will also try and integrate the video saving and streaming code into this and have a neat little script set up asap.

 Quote: Upcoming updates: Automatic script to run the above steps. Pre-determining the time duration of the recorded video. Obtaining snapshots.
14655   Tue Jun 4 23:41:13 2019 gautamUpdateCamerasSteps to interact with GigE

caget/caput probably does the job.

 Quote: Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog).
14656   Wed Jun 5 22:30:13 2019 MilindUpdateCamerasSteps to interact with GigE

Thanks! It does indeed do the trick! With that I was able to

1. Obtain current exposure value using the terminal command caget C1:CAM-ETMX_EXP
2. Set exposure value using the terminal command caput C1:CAM-ETMX_EXP <desired_exposure_value>

Further, a quick look at the camera server code in /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py revealed that the script expects the details of "Number of Snapshots" in "Camera Settings" in the configuration file i.e in C1-CAM-ETMX.ini at ( /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) which wasn't present before. Adding this parameter to the config file allows one to take a snapshot using the medm screen. Infact, unlike as described in this elog, I was able to start the server and client as described in elog 14649, and then obtain snapshots using the terminal command  caput C1:CAM-ETMX_SNAP 1.

Quote:

caget/caput probably does the job.

 Quote: Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog).

14657   Thu Jun 6 16:01:52 2019 MilindUpdateCamerasSteps to interact with GigE

[Koji, Milind]

Today I ran into the following errors:

1. Inability to access the EPICS channels using the commands caget and caput and thus the generation of a blank medm screen (error in Attachment #1) when simultaneously running the code in camera_server.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py).
2. Inability to run camera_server.py code with an active medm screen with a "... failed to read <EPICS channel>" error.

Therefore, Koji and I took a look at it and putting our faith in Gautam's hunch from elog 13023, we walked down to rack 1Y1 and keyed it. Following this, all the functionality previously described was restored! Koji then took a look at all the channels handled by this machine and bestowed upon me the permission to key the crate should I lose control of the GigE again.

Quote:

Thanks! It does indeed do the trick! With that I was able to

1. Obtain current exposure value using the terminal command caget C1:CAM-ETMX_EXP
2. Set exposure value using the terminal command caput C1:CAM-ETMX_EXP <desired_exposure_value>

Further, a quick look at the camera server code in /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_server.py revealed that the script expects the details of "Number of Snapshots" in "Camera Settings" in the configuration file i.e in C1-CAM-ETMX.ini at ( /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) which wasn't present before. Adding this parameter to the config file allows one to take a snapshot using the medm screen. Infact, unlike as described in this elog, I was able to start the server and client as described in elog 14649, and then obtain snapshots using the terminal command  caput C1:CAM-ETMX_SNAP 1.

Quote:

caget/caput probably does the job.

 Quote: Still not sure about how to modify the exposure time (other than using the pylon app, the only technique I know so far is to adjust the exposure manually on the medm screen and then run the scripts as described in the previous elog).

Attachment 1: terminal_medm_error.pdf
14661   Mon Jun 10 22:22:19 2019 MilindUpdateCamerasSteps to interact with GigE

Steps to take snapshots using GigE at different exposures [Instructions for Kruthi]:

1. Setup C1-CAM-ETMX.ini (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini) appropriately. The parameter Number of Snapshots determines how many snapshots will be taken at any given exposure. Set Name Overlay, Time Overlay, Calculation Overlay, Calculations (if using very low values of exposure) and Auto Exposure to False. Ensure that that the IP address of the Camera in use and that in the configuration file match.
2. Launch a server using the following commands (as described in elog 14649)
1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python camera_server.py -c C1-CAM-ETMX.ini
3. Open another terminal in the same directory and then run the following command
1. python exposure_variation.py --minval <minval> --maxval <maxval> --step <step> where
1. minval: lower bound of range of exposure values, defaults to 150
2. maxval: upper bound of range of exposure values, defaults to 100000
3. step: step size of variation in the range [minval, maxval], defaults to 2000

The python script takes in the above parameters and then takes snapshots by setting the exposure to values starting at minval and going upto maxval incrementing by step at each turn. This uses a simple for loop and is nothing elaborate.

1. On a sidenote, I installed Sublime Text editor on rossa following the instructions at this site (check install using yum section). Further, I have also installed miniconda but did not set it up fully as I was in a rush and did not want to disturb any previously set up environment variables.
2. I have cloned Gabriele's repository and am trying to get it to work on my system. As Gautam has pointed out that the end goal is to get stuff working on the lab machines, I will sharea .yml file with the necessary environment details upon completion.
3. I will upload details of how I am going to construct the two learning tasks that Rana, Gautam and I discussed in a day or two including details of the use of simulation data for training data in the absence of real data (until Kruthi is done setting up the GigE) which Gautam suggested I do to speed things up.
14671   Thu Jun 13 21:29:52 2019 MilindUpdateCamerasSteps to interact with GigE

As directed by Gautam, I have set up one script- interact.py (at /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/interact.py) to perform the following two tasks:

1. View the GigE feed for a fixed period of time.
2. Record the GigE feed for a fixed amount of time.

Steps to view GigE feed for a fixed amount of time:

1. Run the following commands in the terminal to navigate to the concerned directory and then view the feed
1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python interact.py --path_to_config <path_config> --mode 0 --view_time <viewing_time>, where
1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
2. viewing_time: time in seconds for which the feed is to be displayed. The server is closed  after this time and the window freezes and can be manually closed.
3. Exiting the feed in between: The script terminates automatically after the specified time. To terminate the feed in between, close the window manually using the x icon the top right. This makes sure that the server is correctly closed. If closed using the Ctrl-C command in the terminal, the server is left running and any attempt to unwittingly set up another results in an error (see Attachment #1). In this case, the server and client processes needs to be identified manually and killed. I have used the following steps
1. ps -eaf | grep server, then identify the PID for the python camera_server.py process
2. kill PID
3. similarly for the client file

Steps to record the GigE feed for a fixed amount of time:

I tried to look for elegant solutions that wouldn't require editing the code that Jon wrote and stumbled upon this useful bit of information but ended up deciding that it was just easier to change the camera_client_movie.py (/opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/camera_client_movie.py). It can still be run as previously described, where video recording is terminated by using Ctrl-C. Steps to record for a fixed period of time are

1. cd /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon
2. python interact.py --path_to_config <path_config> --mode 1 --save_time <recording_time> --file_name filename, where\
1. path_config: full path to configuration file, defaults to /opt/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon/C1-CAM-ETMX.ini if --path_to_config is not used
2. recording_time: time in seconds for which the feed is to be saved. No video is displayed during this time.
3. filename: full path to the file where the video is to be saved. Overwrites any existing files.

I'll make aliases for these to make the whole process more user friendly. I'm halting this for now and will discuss what else needs to be done once Gautam gets back.

Regarding the autolocker: I spoke to Aaron today and as he is in tomorrow, I'll ask him about the burt files and the ideal configuration.

I'm also starting with GANs now.

Attachment 1: terminal_error_server.pdf
14662   Tue Jun 11 00:00:15 2019 MilindHowToPSLSteps to lock the PMC

Today, Rana had me key the PSL crate.

1. Locating the rack: the crate is 1X1. This link provides details of the locations and functions of the racks.
2. Keying the crate: the key is located at the bottom of the rack (in this case). Keying it requires one to turn the key through 90 degrees (anti clockwise facing the rack) and back to to the original position.

Locking the PMC:

1. Accessing the medm screen for the PMC: open a new terminal and use the command sitemap. This should open up the sitemap medm screen. Click on the PSL button and then select C1PSL_PMC from the dropdown that is produced. This opens up a medm screen similar to that in Attachment #1.
2. The correct toggling: The keying of the crate sometimes scrambles the settings on the medm screen. Rana and I performed extensive toggling of the buttons and concluded that the combination in Attachment #1 ought to be the correct one.
3. Locking the PMC: The state of the PMC was deduced by observing CH01 on monitor 7. When not locked, there is no observable bright spot. At this point the "Input Offset (V)" slider is set to zero and the "Servo Gain Adjust (dB)" slider is set to minimum. To obtain lock, complete step 2 and then move the "DC Output Adjust (V)"  slider (at the bottom left on the screen) around rapidly while looking for a bright spot. On observing such a spot on the monitor, release the slider and quickly increase the "Servo Gain Adjust (dB)" slider to around 15 dB. Higher gain values produce a bright spot on CH02 as well which vanishes (almost) on decreasing the gain to the aforementioned value.
Attachment 1: pmc_locked_settings.pdf
55   Thu Nov 1 19:58:07 2007 Andrey RodionovBureaucracyPhotosSteve and Tobin's picture
Attachment 1: DSC_0023.JPG
3660   Wed Oct 6 14:49:54 2010 ranaSummaryloreSteve on the sea

10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating.

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2.

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

8651   Tue May 28 19:35:17 2013 ManasaUpdateGreen LockingStill searching for the X green beat note

Procedure

1. Aligned X-arm to IR.
2. Aligned green to the X-arm.
3. PSL green and X-green aligned to the X-green beat PD.
4. Scanned X-green laser temperature (sweep X slow servo offset through the whole range)

I did not succeed in finding the beat note; but noticed something I cannot explain.
With green very stably aligned to the X-arm, GTRX reads 3000 counts. But when the laser temperature is changed and the green unlocks and locks to the X-arm, it locks with GTRX counts over 5000. GTRX stays at 5000 counts as long as the temperature is changing but settles down to 3000 (over a time lapse of tens of seconds) when let to stay at any specific temperature.

1353   Wed Mar 4 03:50:17 2009 YoichiUpdateLockingStill won't go above arm power 10
Yoichi, Kentaro

The IFO still loses lock at around arm power 10.
I attached time series of various error signals when losing lock.
In all of the three cases, both of the arm powers go up rapidly just before losing lock.
(The first attachment was taken before I fixed the QPDX switching, so you can see saturation in TRX.)
But PD1_DC (the DC power in the PRC) did not go up in the third case.

I should also check correlations with laser power, CARM length (OSEM signals), seismic noise etc.
Attachment 1: lockLoss1.png
Attachment 2: lockLoss2.png
Attachment 3: lockLoss3.png
5682   Mon Oct 17 23:28:32 2011 ranaUpdateElectronicsStochMon

To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

5706   Wed Oct 19 18:18:03 2011 SureshUpdateElectronicsStochMon : Filters installed

 Quote: To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC. We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz). Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly: 11 MHz     SBP-10.7+ 55 MHz     SBP-60+ 29.5 MHz   SBP-30+

The Stochmon had a four-way splitter, four hand-made filters and four mini-circuits ZX47-60-S+ Power Detectors.

Using the filters from our stock I have replaced the hand-made filters with the ones mentioned in Rana's elog.   The power supply solders to the ZX47-60-S+ Power Detectors were weak and came off during reassembly. And some of the handmade short SMA cables broke off at the neck.  So I changed the power supply cables and replaced all the short SMA cables with elbows.  I also removed one of the Power Detectors since there were four in the box and we need only three now.

The power supply connector on the box is illegal.  The current lab standard for  {+15, 0 , -15}  uses that connector.  So we are going to change it as soon as possible.  We need to identify a good {0, 5} lab standard and stock them.

The following were removed from the box:

The box now looks like this:

Steps remaining in installation of Stochmon:

1) Install the Newfocus 1811 PD at the IPPOS by diverting some of the power in that path

2) Connect the outputs of the Stochmon to ADC inputs in 1X2 rack.

1093   Mon Oct 27 11:16:23 2008 AlbertoConfigurationIOOStochMon Calibration
I implemented the calibration for the four channels of the StochMon in the ioo EPICS database. Now the output of those channels, as shown in the medm screen, gives the peak-to-peak amplitude in voltage of each frequency from the RFAMPD at the transmission of the MC, normalized by the DC output from the same photodiode.

Basically the calibration takes into account the following factors:
- two in series RF preamplifiers, currently laying on the PSL table near the RFAMPD, with gains of 19 dB and 17 dB, respectively
and, inside the StochMon blue box:
- a resonant band-pass filter with the following gains h_f(f) for each of the frequencies of interest: 33MHz -39.5 dB; 133MHz -40.8 dB; 166MHz -49.0 dB; 199MHz -45.0 dB
- a power detector that provides an output voltage linearly proportional to the input power in dBm, with a factor alpha of proportionality equal to an average value of -0.0271 V/dBm for all the frequencies

The calibration that relates the output voltage from the PD to the output voltage from the StochMon is then obtained as:

V_pd(f) = sqrt(2*R*P0)/h_f(f) * 10^( (Vo-q)/(20*alpha) )

where R=50ohm, P0=1mW and q=0.772 V, the latest being the offset in the calibration of the power detector (that is its output for a 0 dBm input).
2253   Thu Nov 12 12:50:35 2009 AlbertoUpdateComputersStochMon calibrated channels added to the data trend

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

554   Mon Jun 23 19:48:28 2008 rana,albertoSummaryIOOStochMon trends (80 days)
Here's a StochMon plot showing the RFAM after the MC. Remember that in these units, 2V means no RFAM
and 0 V means lots of RFAM. Alberto says "the calibration is in Tiramisu". So there you go.
Attachment 1: e.png
3170   Wed Jul 7 17:18:57 2010 AlbertoConfigurationElectronicsStochmon and LSC AM Stabilizer Decomissioned
Today I disconnected and removed the Stochmon box from the 1Y2 rack.
I also removed the amplifiers that were sitting on the PSL table, next to the RF AM PD, that were connected to the Stochmon. I pulled back the RG cable and the power cables that went from the PSL table to the 1Y1 and 1Y2 racks.
The power cable, all rolled up, is now sitting on the floor, inside the 1Y1 rack and one of its end is still connected to the power of the rack. We'd like to turn off the entire rack in order to safely remove it. But since the laser driver is there too, we should do it the first time we have to turn off the rack for some other reason.

I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.

I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.

5996   Thu Nov 24 05:47:16 2011 KojiSummaryIOOStochmon running

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

6028   Mon Nov 28 18:19:53 2011 kiwamuUpdateIOOStochmon seems working

Here is a 48 hours trend of the RFAM monitor (a.k.a StochMon):

The upper plot is the DC output from the StochMon PD and the lower plot shows the calibrated RIN (Relative Intensity) at each modulation frequency.

I have downloaded minutes trends of StochMon for 48 hours staring from 6:00AM of Nov/24.

I followed Koji's calibration formula (#6009) to get the actual peak value (half of the peak-peak value) of the RF outputs and then divided them by the DC output to make them RIN.

It looks the RINs are hovering at ~ 4 x 10-4 and fluctuate from 1x10-4 to 1x10-3. Those numbers agree with what we saw before (#5616)

So it seems the StochMon is working fine.

 Quote from #6009 New RFAM mon calibration

5941   Fri Nov 18 01:51:37 2011 KojiUpdateIOOStochmon update

Update of the stochmon status

[Attachment 1: Circuit diagram]

- The new stochmon has a low noise amplifier (MAR-6SM) inside.
The RFAM signal from the PD has the power of -60~-50dBm, which is almost at the bottom of the sensitivity for the power detector.

- The band pass filters were doubled.

- I've suffered from some RF coupling from the power line as the power detector is quite sensitive to it.
The situation has been largely improved by the EMI filters in the power supply path, although the problem is still present.
The worst remaining problem is that we can not close the aluminum lid as it cause a huge sprious coupling.

[Attachment 2: Calibration result]

- The outputs were calibarted with Marconi. They showed the signals linear to dBm for the input powers between -70dBm and -10dBm.

- The calibration result was fitted with the empirical fit function. The function and the results are shown in the attachment.

[Attachment 3: Detection limit]

- The attached figure shows the power spectrum of the PD output. This measurement gives us the amount of the RF power given from the PD noise when there is no RF signal.

11MHz out passband noise: −72.7dBm ===> V11 = 2.0483
30MHz out passband noise: −64.6dBm ===> V30 = 1.9333
55MHz out passband noise: −71.2dBm ===> V55 = 2.0272

- Now 11MHz and 55MHz outputs seem indicating the power correctly, but the 29.5MHz output never provides useful information.
It is a constant value independent from the state of the incident beam. Strangely this problem disappears if the marconi is used
for the RF source. Thus this issue is not seen in the calibration measurement.

- So far, 11MHz, 29.5MHz, 55MHz, and DC outputs appear in the channels C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_133MHZ, C1:IOO-RFAMPD_166MHZ, and C1:IOO-RFAMPD_199MHZ.
They will be renamed.

Attachment 1: stochmon.pdf
Attachment 2: stochmon_calib.pdf
Attachment 3: RFAM_PD_noise.pdf
6009   Fri Nov 25 20:03:05 2011 KojiUpdateIOOStochmon update

New RFAM mon calibration

Attachment 1: stochmon_calib.pdf
ELOG V3.1.3-