40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 311 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9216   Mon Oct 7 18:32:01 2013 John ZweizigSummaryComputer Scripts / Programsnds2 installed, restarted

The upgrade of megatron broke the nds2 service. I have fixed things by

  1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)

  2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)

  3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.

 nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.

 

  3718   Thu Oct 14 13:09:01 2010 Leo SingerConfigurationComputersnds2-client-devel installed on rossa

I installed nds2-client-devel on rossa using the following command:

$ sudo yum install nds2-client-devel

  15716   Tue Dec 8 15:07:13 2020 gautamUpdateComputer Scripts / Programsndscope updated

I updated the ndscope on rossa to a bleeding edge version (0.7.9+dev0) which has many of the fixes I've requested in recent times (e.g. direct PDF export, see Attachment #1). As usual if you find issue, report it on the issue tracker. The basic functionality for looking at signals seems to be okay so this shouldn't adversely impact locking efforts.


In hindsight - I decided to roll-back to 0.7.9, and have the bleeding edge as a separate binary. So if you call ndscope from the command line, you should still get 0.7.9 and not the bleeding edge.

Attachment 1: test.pdf
test.pdf
  500   Tue May 27 16:24:54 2008 tobinConfigurationComputer Scripts / Programsndsproxy
The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.

I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.

So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?

The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
that directory.
  3317   Thu Jul 29 12:13:28 2010 kiwamuSummaryCDSnear term plan

 [Joe and Kiwamu]

current_setup_v2.png

  11597   Tue Sep 15 01:14:10 2015 ranaSummaryLSCneed to check LSC Whitening switch logic ... again

Tonight we noticed that the REFL_DC signal has gone bipolar, even though the whitening gain is 0 dB and the whitening filter is requested to be OFF.

We should check out the switch operation of several ofthe LSC channels in the daytime - where is the procedure for this diagnostic posted?

  8608   Tue May 21 18:18:28 2013 JamieUpdateComputer Scripts / ProgramsnetGPIB stuff update/modernized/cleanedup/improved

I did a bunch of cleanup work on the netGPIB stuff:

  • Removed extensions from all executable scripts (executables should not have language extensions)
  • fixed execution permissions on executables and modules
  • committed HP8590.py and HP3563A.py instrument modules, which were there but not included in the svn
  • committed NWAG4395A (was AG4395A_Run.py) to svn, and removed old "custom" copies (bad people!)
  • cleaned up, modernized, and fixed the netgpibdata program
  • removed plotting from netgpibdata, since it was only available for one instrument, there's already a separate program to handle it, and it's just plotting the saved data anyway
  • added a netgpibcmd program for sending basic commands to instruments.
  • added a README

Probably the most noticeable change is removing the extensions from the executables.   There seems to be this bad habit around here of adding extensions to executables.  It doesn't matter to the person running the program what language it was written in, so don't add extensions.  It only matters for libraries.

  13603   Fri Feb 2 23:28:13 2018 KojiUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

I could not understand why 'netgpibdata' scripts are missing in "scripts/general" folder on pianosa... Where did they go???

Also, I found that the PROLOGIX GPIB-LAN controller for crocetta (192.168.113.108) is no longer working. I need to reconfigure it with "telnet"...

  13604   Sat Feb 3 13:03:45 2018 gautamUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

The netgpibdata scripts are now under git version control at /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata. I think the idea was to make this directory a collection of useful utilities that we could then pull at various labs / at the sites.

Quote:

I could not understand why 'netgpibdata' scripts are missing in "scripts/general" folder on pianosa... Where did they go???

  13607   Mon Feb 5 18:04:35 2018 KojiUpdateComputer Scripts / Programsnetgpib data missing / PROLOGIX yellow box (crocetta) not working

crochetta was reconfigured to have 192.168.113.108. It was confirmed that it can be used with netgpibdata.py

Configuration: I have connected my mac with the unit using an Apple USB-Ethernet adapter. The adapter was configured to have a manual IP of 192.168.113.222/255.255.255.0. "netfinder.exe" was run to assign the IP addr to the unit. It seemed that NVRAM of the unit evaporated as it had the IP of 0.0.0.0. Once it was configrued, it could be run with netgpibdata as usual.

  11015   Thu Feb 12 15:21:37 2015 ericqUpdateComputer Scripts / Programsnetgpib updates

I've fixed the gpib scripts for the SR785 and AG4395A to output data in the same format as expected by older scripts when called by them. In addition, there are now some easier modes of operation through the measurement scripts SRmeasure and AGmeasure. These are on the $PATH for the main control room machines, and live in scripts/general/netgpib


Case 1: I manually set up a measurement on the analyzer, and just want to download / plot the data. 

Make sure you have a yellow prologix box plugged in, and can ping the address it is labeled with. (i.e. 'vanna'). Then, in the directory you want to save the data, run:

SRmeasure -i vanna -f mydata --getdata --plot

This saves mydata_(datetime).txt and mydata_(datetime).pdf in the current directory. 

In all cases, AGmeasure has the identical syntax. If the GPIB address is something other than 10, specifiy it with -a, but this is rarely the case.


Case 2: I want to remotely specify a measurement

Rather than a series of command line arguments, which may get lost to the mists of time, I've set the scripts up to use parameter files that serve as arguments to the scripts. 

Get the templates for spectrum and TF measurements in your current directory by running

SRmeasure --template

Set the parameters with your text editor of choice, such as frequency span, filename output, whether to create a plot or not, then run the measurement:

SRmeasure SR785template.yml


Case 3: I want to compare my data with previous measurements

In the template parameter files, there is an option 'plotRefs', that will automatically plot the data from files whose filenames start with the same string as the current measurement.

If, in the "#" commented out header of the data file, there is a line that contains "memo:" or "timestamp:", it will include the text that follows in the plot legend. 


There are also methods to remotely trigger an already configured measurement, or remotely reset an unresponsive instrument. Options can be perused by looking at the help in SRmeasure -h

I've tested, debugged, and used them for a bit, but wrinkles may remain. They've been svn40m committed, and I also set up a separate git repository for them at github.com/e-q/netgpibdata

  9497   Thu Dec 19 21:16:16 2013 KojiConfigurationGeneralnetgpibdata is working again now

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Jenne witnessed and certified that they were working fine.
Now no one can say "it does not work"!


These weeks I was annoyed by the fact that netgpibdata was messed up by dummies.
A terrible situation was found:

1. Someone pushed the factory reset of one of the wifi bridges (LINKSYS WET54G).
2. Someone gave wrong IPs to the bridges (192.168.1.* instead of 192.168.113.*)
3. Someone left a default IP to the bridges. This means the routers had the same IPs.

-------

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

All of the network settings are taped on the bridge now.
The reset switch of each bridge was covered by a tape so that dummies can't randomly push the button.

The command was tested with each device.

  9502   Fri Dec 20 10:08:43 2013 JamieConfigurationGeneralnetgpibdata is working again now

Quote:

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Just wanted to point out that the correct "modern" path to this stuff is:

/opt/rtcds/caltech/c1/scripts/general/netgpibdata

This is, of course, the same directory, but under the correct "/opt/rtcds", instead of the old, incorrect "/cvs/cds".

  9835   Mon Apr 21 22:32:33 2014 ranaConfigurationGeneralnetgpibdata is working again now

Not working again. I tried the commands in Koji's elog as well as the ones from my notes, but the AG 4395 hooked up to the yellow box named crocetta doesn't work. It gets to the stage of opening the data files and hangs. I tried it with many variations on pianosa and rossa. Also tried power cycling the analyzer and the Prologix and the bridge.

While hooked up to the MC error point I set the modulation frequency from 137 to 133 Hz to minimize the 3 MHz peak as usual.

  9851   Thu Apr 24 22:39:14 2014 ranaConfigurationGeneralnetgpibdata is working again now

Quote:

Not working again. I tried the commands in Koji's elog as well as the ones from my notes, but the AG 4395 hooked up to the yellow box named crocetta doesn't work. It gets to the stage of opening the data files and hangs. I tried it with many variations on pianosa and rossa. Also tried power cycling the analyzer and the Prologix and the bridge.

While hooked up to the MC error point I set the modulation frequency from 137 to 133 Hz to minimize the 3 MHz peak as usual.

Started working tonight. Don't know if anyone did anything to the Martian network or not, so its a mystery...

I also modified the script and SVN'd it. It now correctly takes your plot wants and adjust the linear/log of the axes accordingly

./SPAG4395A.py -i crocetta -A -v 4 --att=0 --start=1kHz --end=10MHz --bw=1kHz --plot --semiy

and also saves the plot as out.pdf

In the attached image I show the MC board TP1A output. The two peaks around 3.7 Mhz are the sideband beats we speak of. The lower one is proportional to the MC length/frequency mistmatch.

Attachment 1: out.pdf
out.pdf
  9875   Tue Apr 29 10:01:25 2014 KojiConfigurationGeneralnetgpibdata is working again now

I've moved the WB network analyzer to the OMC lab. The 40m network analyzer is not in service for the MC monitoring.
I setup the configuration so that the same command gives us the same spectrum measurement.

  10445   Wed Sep 3 14:07:18 2014 ranaConfigurationGeneralnetgpibdata is working again now

Quote:

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

 I was going through some old Koji elogs to check them for correctness (as I do weekly). I noticed that back in Dec 2013, he made the above illegal modification of IP numbers. 192.168.113.230 was actually the IP for farfalla. Maybe that's why they were conflicting and farfalla not working and Q observing/imagining wireless GPIB dropouts?

I used the Wiki instructions to update the 2 bind9 files with a new number for farfalla (192.168.113.212) which was previously the number for the long dead op240m. Farfalla is restarted and sort of working. 

  10421   Thu Aug 21 22:10:52 2014 ranaSummaryComputer Scripts / Programsnetwork movements

 To help development of the data visualization project, we've assigned the .101 and .102 IP to DataVis. This is being used by the iMac in the control room via port 8 of the CDS switch near the Blue Plataeu Tournant.

We tried using one of the free ports, but Jamie realized that we had to use one of the already assigned ones due to some 'Smart' switch management software. So for the moment, please leave the iMac alone so that Bill can use it.

  4127   Sat Jan 8 23:18:03 2011 ranaUpdateComputersnetwork table

There's, as usual, a disconnect between the real martian host table and the one displayed on the Wiki. Basically, the point is: DO NOT TRUST THE WIKI, because people who update the actual host table only randomly update the wiki table.

The only thing worth trusting is the file

/var/named/chroot/var/named/martian.zone
on linux 1.

You will need to have 'root' or 'sudo' to get into that directory to read the file.

  2097   Thu Oct 15 09:23:07 2009 steveSummaryLockingnever had it so good

Awesome 5 hrs of locking  Rob!

Attachment 1: 5hlock.jpg
5hlock.jpg
  2100   Thu Oct 15 17:12:00 2009 ranaSummaryLockingnever had it so good

 

  12506   Mon Sep 19 13:57:21 2016 ranaUpdateGeneralnever post EPS files in the ELOG. Ever.

http://tex.stackexchange.com/questions/2092/which-figure-type-to-use-pdf-or-eps

  7791   Wed Dec 5 09:42:46 2012 ranaOmnistructureComputersnew (beta) version of NDS2 installed on control room machines

NDS2 is not designed for non DQ channels - it gets data from the frames, not through NDS1.

For getting the non-DQ stuff, I would just continue using our NDS1 compatible NDS mex files (this is what is used in mDV).

  7793   Wed Dec 5 16:54:29 2012 jamieOmnistructureComputersnew (beta) version of NDS2 installed on control room machines

Quote:

NDS2 is not designed for non DQ channels - it gets data from the frames, not through NDS1.

For getting the non-DQ stuff, I would just continue using our NDS1 compatible NDS mex files (this is what is used in mDV).

The NDS2 protocol is not for non-DQ, but the NDS2 client is capable of talking both the NDS1 and NDS2 protocols.

fb:8088 is an NDS1 server, so the client is talking NDS1 to fb.  It should therefore be capable of getting online data.

It doesn't seem to be seeing the online channels, though, so I'll work with Leo to figure out what's going on there.

The old mex functions, which like I said are now available, aren't capable of getting online data.

  7786   Tue Dec 4 20:38:51 2012 jamieOmnistructureComputersnew (beta) version of nds2 installed on control room machines

I've installed the new nds2 packages on the control room machines.

These new packages include some new and improved interfaces for python, matlab, and octave that were not previously available. See the documentation in:

  /usr/share/doc/nds2-client-doc/html/index.html

for details on how to use them.  They all work something like:

  conn = nds2.connection('fb', 8088)
  chans = conn.findChannels()
  buffers = conn.fetch(t1, t2, {c1,...})
  data = buffers(1).getData()

NOTE: the new interface for python is distinct from the one provided by pynds.  The old pynds interface should continue to work, though.

To use the new matlab interface, you have to first issue the following command:

   javaaddpath('/usr/lib/java')

I'll try to figure out a way to have that included automatically.

The old Matlab mex functions (NDS*_GetData, NDS*_GetChannel, etc.) are now provided by a new and improved package.  Those should now work "out of the box".

  7788   Tue Dec 4 23:08:46 2012 DenOmnistructureComputersnew (beta) version of nds2 installed on control room machines

Quote:

I've installed the new nds2 packages on the control room machines.

 I've tried new nds2 Java interface in Matlab. Using findChannels method of the connection class I see only slow, DQ and trend channels. I could even download data online using iterate method. When it will be possible to do the same with fast non-DQ channels?

>> conn = nds2.connection('fb', 8088);
>> conn.iterate({'C1:LSC-XARM_OUT'})
??? Java exception occurred:
java.lang.RuntimeException: No such channel.
    at nds2.nds2JNI.connection_iterate__SWIG_0(Native Method)
    at nds2.connection.iterate(connection.java:91)

  986   Tue Sep 23 15:28:06 2008 peteConfigurationPSLnew 21.5 MHz FSS reference installed
The new 21.5 MHz FSS reference is now installed in the rack with the 7 Sorensen PS. Both outputs give 18.7 dBm. The MC seems happy.

Bob did the +24 V and +15 V hookups for the amp and the Wenzel oscillator respectively, off of the din strips on the right of the rack.

I have attached two photographs. One shows the front of the box as mounted in the rack, and the other shows the inside of the box. From the second photo the circuit is apparent. Black wire coming in has ground, green has +15, and white has +24. After the switches, ground and +15 go to the Wenzel crystal oscillator, and ground and +24 go to the mini-circuits amp. There is 5 dB attenuation between the Wenzel 21.5 MHz output and the amp input. There is 3 dB attenuation between the amp output and the splitter.

The Wenzel crystal oscillator is their "streamline" model, and puts out 13.2 dBm. The amp is mini-circuits ZHL-2.
Attachment 1: fss_ref_001.jpg
fss_ref_001.jpg
Attachment 2: fss_ref_013.jpg
fss_ref_013.jpg
  13804   Tue May 1 15:23:18 2018 KiraUpdatePEMnew ADC channel setup issue

[Kira, Johannes]

I connected up the channels for the ADC Acromag a while back and we were planning to install it today so that we could set up a new channel for the out of loop sensor. Unfortunately, the Acromag seems to be broken. We connected up a precision 10V voltage to one of the channels, but the Acromag read out ~7V and it kept fluctuating. Even after calibration, we still got the same result. When enabling the legacy support, we got ~11V. But when we measured the voltage at the screw terminals with a multimeter and it showed 10V, so the issue is not with the wiring. All of the channels have this same issue. We will be ordering more Acromags soon, so hopefully we'll be able to set up the channel soon. I've attached a picture of the Acromag along with the front panel with the channels labeled

Attachment 1: IMG_20180501_152014.jpg
IMG_20180501_152014.jpg
  9863   Mon Apr 28 10:34:51 2014 KojiUpdateLSCnew ALS servo design

Based on the evaluation of the error signals, the new servo was designed.

Concept:
- Don't touch the locking filters. (i.e. FM5)
- Sacrifice some phase at 150Hz to increase the gain between 3-20Hz.
- As resonant gains costs the phase without increasing the LF gains, replace them with a poles for the integrators.


FM(:,1) = zero2(f,.5,.7).*pole2(f,0.001,.7)*(0.5/0.001)^2;
FM(:,2) = zero2(f,5,2).*pole2(f,3,3).*pole1(f,1).*zero1(f,5)*5*(5/3)^2;
FM(:,3) = zero2(f,25,.7).*pole2(f,3.2,10)*(25/3.2)^2; % Zero crossing
FM(:,4) = zero2(f,35,2).*pole2(f,3,3).*zero1(f,3000).*pole1(f,1).*pole2(f,3000,1/sqrt(2)).*pole1(f,700).*zero1(f,10).*zero1(f,350).*136e1;
FM(:,5) = zero1(f,1).*pole1(f,4010).*pole2(f,17.3211e3,1.242).*zero2(f,18.865e3,100e3);
FM(:,6) = zero2(f,5,2).*pole2(f,10,2).*pole2(f,16.5,30).*zero2(f,30,2);
FM(:,7) = 1;
FM(:,8) = 1;
FM(:,9) = 1;
FM(:,10) = 1;
dc_gain = 14;

FM1/2/3/5/6 are expected to be used for the control.


FM1: Boost below 0.5Hz. This does not cost the phase margin.
FM2: Increase the gain below 5Hz. This hardly cost the phase margin.
FM3: Boost below 25Hz. This is the main phase cost at UGF. This has a complex pole pair at 3Hz with Q=10 to supress the stack motion.
FM6: zero-pole-pole-zero combination to boost the gain between 5 to 30Hz. This eats the phase margin a little.

Note that the phase tracker gain for the X arm was increased by factor of 2.5.

Attachment 1: ALSX_OLTF_new2.pdf
ALSX_OLTF_new2.pdf
Attachment 2: ALSY_OLTF_new2.pdf
ALSY_OLTF_new2.pdf
  9864   Mon Apr 28 10:48:48 2014 KojiUpdateLSCnew ALS servo design: comparison

Comparison of the new and old servo OLTF
The new servo has the same UGF, slightly less phase margin, and more gain between 1.5 and 25Hz.

Attachment 1: ALSX_OLTF_new.pdf
ALSX_OLTF_new.pdf
Attachment 2: ALSY_OLTF_new.pdf
ALSY_OLTF_new.pdf
  3474   Thu Aug 26 17:10:26 2010 kiwamuUpdateCDSnew CDS test

[Joe, Kiwamu] 

Woooo Yeaaaah

With the new CDS we succeeded in damping of PRM and BS !!

  3480   Fri Aug 27 17:27:41 2010 kiwamuUpdateCDSnew CDS test

 { Joe, Kiwamu }

Yes !

We now are damping all of the vertex suspensions including PRM, BS, ITMs and MCs by the new CDS

( Note that we are not damping SRM because we don't have it in the chamber. )


 (things to be done)

- Make the binary outputs work.

- Make DTT work

  8392   Tue Apr 2 17:23:23 2013 SteveUpdate40m Upgradingnew ETMY optical table & enclosure in place

 Enclosure is at the east end. It has it's bottom o-ring in place. It will be ready for optics tomorrow around 5pm

I have to shim out the enclosure, finish leveling the table and cut surgical tubing O-ring for the top.

 

Attachment 1: EEopt1d.jpg
EEopt1d.jpg
  3014   Sun May 30 13:26:07 2010 rana, kiwamuUpdatePSLnew HIGH-LOW value for PMC_TRANS

We changed the HIGH/LOW values of the PMC_TRANS.

The edited file was updated on the svn.


Since the PMC_TRANSPD was replaced behind the pzt mirror (see the entry), its nominal value were reduced to something like ~1V from the previous value of ~2V.

In the medm screen C1PSL_PMC.adl the PMC_TRAN always indicated red because the value were low compared with the previous one.

We went to /cvs/cds/caltech/target/c1psl, then edited psl.db

- Here are the new parameters we set up in the file.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

  field(LOW,"0.98")
  field(LOLO,"0.93")
  field(HIGH,"1.15")
  field(HIHI,"1.3")

}

- - - -

These values are based on ~4days trend of the PMC_TRAN.

Then we manually updated those numbers by using ezcawrite in order not to reboot C1PSL.

So now it nicely indicates green in the medm screen.

  3028   Tue Jun 1 20:40:03 2010 KojiUpdatePSLnew HIGH-LOW value for PMC_TRANS

The alarm had kept crying. I reduced the LOW to be 0.90 and the LOLO to be 0.85 both in psl.db and with ezcawrite.

Quote:

We changed the HIGH/LOW values of the PMC_TRANS.

The edited file was updated on the svn.


Since the PMC_TRANSPD was replaced behind the pzt mirror (see the entry), its nominal value were reduced to something like ~1V from the previous value of ~2V.

In the medm screen C1PSL_PMC.adl the PMC_TRAN always indicated red because the value were low compared with the previous one.

We went to /cvs/cds/caltech/target/c1psl, then edited psl.db

- Here are the new parameters we set up in the file.

grecord(ai,"C1:PSL-PMC_PMCTRANSPD")
{

  field(LOW,"0.98")
  field(LOLO,"0.93")
  field(HIGH,"1.15")
  field(HIHI,"1.3")

}

- - - -

These values are based on ~4days trend of the PMC_TRAN.

Then we manually updated those numbers by using ezcawrite in order not to reboot C1PSL.

So now it nicely indicates green in the medm screen.

 

  4905   Wed Jun 29 00:35:36 2011 KojiUpdateLSCnew LSC overview screen 80% done

New LSC screen is 80% completed.

It is now accessible from the LSC menu of "sitemap".

Most of the part in the screen is clickable such that it launches another screen depending on the location of the click.

 

The bottom part of the screen still need some work.

RFPD screen is temporary

LSC control screen is also temporary

DAC overflow indicators are still broken.

Channel assignment of the whitening filters are arbitrary so far.

 

Attachment 1: LSC_OVERVIEW.png
LSC_OVERVIEW.png
  3758   Fri Oct 22 00:59:01 2010 yutaUpdateCDSnew MEDM screens, new filter banks(whitening and dewhitening related)

(Joe, Yuta)

Summary:
 No more discrimination for SIDE!
 We had all SIDE filters in SDSEN, so we splitted into SDSEN, SUSSIDE, and SDCOIL just like other DOFs. (Not SIDECOIL. SDCOIL from now on!)
 Also, there was a confusion in output filters, so we fixed the filter bank(dewhitening and 28HzELP).
 More than that, I found that "13HzCheby" in SUSPOS, SUSPIT, SUSYAW was actually doing ~1.6Hz Chebyshev, so I fixed it. (No wonder we had no damping when turing "13HzCheby" on!)
 Our new MEDM screen is Attachment #1.

Input filter design:
 Every optics, every OSEM has same analog whitening filter.
 So;

digital analog
30,100:3 30,100:3
ON OFF
OFF ON

Output filter design:
 For every SIDE coils and MC1, MC3 coils, they have analog 28Hz elliptic LPFs.
 So;
digital analog
28HzELP 28HzELP
ON OFF
OFF ON

 For MC2(and other main optics) UL/UR/LR/LL coils, they have analog dewhitening filters.
 So;
digital analog
InvDW SimDW DW
ON ON OFF
ON OFF ON

 InvDW and SimDW were in FM10 and FM9, but I swapped them to make it more consistent.
 Now, FM10 switches analog/digital output filiters for every optics.

  Let's put 28HzELP in FM9 so that FM9 switches analog/digital for every optics.

Quote:

Schematic:
 - whitening
   MC1 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
   MC2 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
   MC3 5 PD outputs -> SUS PD Whitening Board(D000210) -> ... (digital WF=3,100:3)
      D000210 has switches for bypassing analog WT(3,100:3). HIGH to bypass.
 - dewhitening
  (-) ... -> SOS Dewhitening Board(D000316) -> MC1,3 UL/UR/LR/LL coils
  (-) ... -> SOS Dewhitening Board(D000316) -> MC1,2,3 SIDE coils
  (SimDW)(InvDW) ... -> LSC Anti-imaging Board(D000186) -> Universal Dewhitening Board(D000183) -> MC2 UL/UR/LR/LL coils
     D000316 has switches for bypassing 28Hz elliptic LPF. HIGH to bypass.
     D000186 is 7570Hz elliptic LPFs.
     D000183 has switches for bypassing dewhitening filter. HIGH to bypass.
 See this wiki page for more comprehensive setup.

Next work:
 - Fix Simulink connection and logic so that analog/digital switching go correctly.
 - Check if the switching are correct for all channels by measuring transfer functions.
 - Currently, we are focusing on MCs, but we have to do the same fixing for other optics, too.
 - More than setting the right filter TF, there are switching settings like Zero History, Ramp, Zero Crossing...... We should investigate that.
 - Actually, TF of analog DW in D000183 doesn't look like the same with digital SimDW. Why??

Attachment 1: HappySideMEDM.png
HappySideMEDM.png
  6472   Fri Mar 30 10:24:14 2012 steveUpdateSUSnew OSEM locking plunger

Quote:

Quote:

Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.

Problems:  1, they become magnetized after years being close to the magnets

                     2, they oxidize by time so it is hard to turn them

                    

I looked around to replace them.

Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.

Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50

 In order to get a better price from Vlier's Tom Chen I changed Ti body back to SS304L-siver plated and music wire spring. The price is still ~$120 ea. at quantity 50

I will talk to Mike G about modifying the  McMaster plunger with a hex nut.

 Conclusion: There is no need to silver plate the SS plunger at the torque level we hold the OSEMs

Mike Gerfen will be done with 50 pieces by April 4 and he will give them to Bob for cleaning. They should be cleaned and baked in a jig so the springs would be compressed for better venting.

Attachment 1: new_OSEM_locker_screw.jpg
new_OSEM_locker_screw.jpg
Attachment 2: IMG_0109.JPG
IMG_0109.JPG
Attachment 3: IMG_0111.JPG
IMG_0111.JPG
  1094   Mon Oct 27 11:23:10 2008 steveUpdatePhotosnew Olympus camera with IR vision
The IR blocker was removed from our new Olympus camera
SP 570UZ camera.
It has image stabilization, zoom 26-520 mm (20x optical)
and 10.7 Mpixel
Attachment 1: IRisin.JPG
IRisin.JPG
  1838   Wed Aug 5 16:33:50 2009 steveConfigurationPSLnew PSL output iris

I installed an improvised version of PSL output beam iris at the output periscope last week.

Attachment 1: psliris.png
psliris.png
  13550   Tue Jan 16 16:18:47 2018 SteveUpdatePSLnew PSL shelf in place

[ Johannes, Rana, Mark and Steve ]

On the second trial the shelf was installed. Plastic cover removed. South end door put back on and 2W Inno turned on.

Shelf 10 " below the existing one:   92" x 30" x 3/4" melamine (or MDF) covered with white Formica.  200 lbs it's max load. Working distance to top of the table 18"

Quote:

While moving the RefCav to facilitate the PSL shelf install, I bumped the power cable to the AOM driver. I will re-solder it in the evening after the shelf installation. PMC and IMC have been re-locked. Judging by the PMC refl camera image, I may also have bumped the camera as the REFL spot is now a little shifted. The fact that the IMC re-locked readily suggests that the input pointing can't have changed significantly because of the RefCav move.

 

 

Attachment 1: DSC00020.JPG
DSC00020.JPG
  13795   Thu Apr 26 23:00:42 2018 ranaUpdatePEMnew Seis temp chans

After fixing the spelling of the EX temperature readback, I also added all of the MEDM sliders to the C0EDCU.ini file (making sure to add an even number of channels). Restarted FB (after installing telnet on rossa):

telnet fb 8083

> shutdown


preferred method of posting DataViewer images: print as a SVG image (since its vectorized). Then from the command line do:

inkscape steven.svg --export-pdf=vass.pdf

Attachment 1: chans.pdf
chans.pdf
  13798   Fri Apr 27 18:42:02 2018 ranaUpdatePEMnew Seis temp chans

for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?

  16644   Thu Feb 3 14:47:12 2022 ChubUpdateElectronicsnew UPS in place

Received the new 1100VA APC UPS today and placed it at the bottom of the valve rack.  I'd connected the battery and plugged the unit into the AC outlet, but did not turn it on due to the power outage this weekend.

  1937   Mon Aug 24 16:48:57 2009 steveHowToVACnew UPS installed

Quote:

As Rob noted last Friday, the UPS which powers the Vacuum rack failed. When we were trying to move the plugs around to debug it, it made a sizzling sound and a pop. Bad smells came out of it.

Ben came over this week and measured the quiescent power consumption. The low power draw level was 11.9 A and during the reboot its 12.2 A. He measured this by ??? (Rob inserts method here).

So what we want is a 120 V * 12.2 A  ~ 1.4 kVA UPS with ~30-50% margin. We look for this on the APC-UPS site:

On Monday, we will order the SUA2200 from APC. It should last for ~25 minutes during an outage. Its $1300. The next step down is $200 cheaper and gives 10 minutes less uptime.

The new APC Smart -UPS 2200VA is now running at  the vacuum rack. There are 2 load monitoring leds on out of 5

Maglev, dry pumps and roughing pumps are not using UPS.

The switch over went smoothly with Yoichi's help.

First we closed all vacuum valves and stopped the two small turbos.

Than turned power off to instruments in the vac-rack and VME: c1vac1 & c1vac2

Maglev was left running.

Now we moved the AC plugs from the wall receptacles over to the back of the UPS and powered them up.

Varian turbos were restarted and vacuum valves were restored in order to reach  vacuum normal condition.

See 40m Vacuum System States and Sequences Manual of 10-24-2001

 

Linux 3 desk top computer is out of order at the pump spool. We should replace it.

The vacuum control screen can be pulled up on a lap top: /cvs/cds/caltech/medm/c0/ve/VacControl_BAK.adj

 

  10460   Fri Sep 5 16:13:00 2014 ericqUpdateGreen Lockingnew X Green PDH measurements

 I measured the noise spectra and loop TF of the green PDH with the newly stuffed board. Unfortunately, I never took the noise below 100Hz of the previous box, so we can't see what has happened to the overall RMS, or more specifically, the RMS due to the pendulum resonance. All of these plots are in the boosted state, as that is how we intend to use the box. 

Here is the loop, which does not have quite as much margin as the y-arm, but 10dB of gain peaking is probably ok, since the RMS at 10s of kHz is not so important to ALS. (OL measured, CL inferred)  We see the 1/f shape from 1k to 50k or so, and 1/f^2 under 1k, as desired. 

xGbodes.pdf

Comparing in the in loop error signals, we see the effect from the increased gain from 100Hz to 10kHz. (Here is where I regret not looking at the low frequency spectrum two weeks ago)

pdhComparison.pdf

Finally, here is the noise breakdown. 

xGspectra.pdf

The error signal RMS is now dominated by the 1Hz peak. We have talked about using digital feedback for this, since we have the PDH error signal coming into an ADC, and can sum in a DAC signal into the servo output. This also lets us intelligently trigger a sub-10Hz boost once the PDH box locks itself. With a good boost, we maybe could bring the in-loop RMS of the error signal to under 1kHz. 


Something odd that Rana brought to my attention, however, is that my measurement and calibration indicates an RMS of ~5kHz, but the cavity pole should be something like 18kHz. If this is true, how can we be seeing stable power? This maybe means that my calibration is too many Hz per Volt.

I performed the calibration by creating a MIST model of the arm, and generating the PDH error signal on a demodulated PD, I then find the slope of Hz per arbitrary error signal unit. Then, looking at a scope trace, I match up the horn-to-horn voltage to the horn-to-horn arbitrary error signal units, which lets me finally find Hz per error signal volt. 

However, there is some qualitative difference in the shape between the simulated and observed error signals, namely, that the outer horns are larger than the inner horns in the real signal. 

sigSim.pdfscopeSweep.jpg

 

Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration? 

Data, plots, code, attached. 

Attachment 6: xG_Sep5.zip
  10463   Sat Sep 6 01:48:54 2014 ranaUpdateGreen Lockingnew X Green PDH measurements

Quote:

Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration? 

Data, plots, code, attached. 

 What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.

I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says  "80 * sqrt(1) = 80".

Take a look at:

http://www.mathwords.com/r/root_mean_square.htm

and

http://www.ligo.caltech.edu/~rana/mat/utilities/rms.m

  10464   Sat Sep 6 14:49:12 2014 ericqUpdateGreen Lockingnew X Green PDH measurements

I used a modulation depth of 0.3, which, if I recall correctly, is what we aimed for on the Y-arm when we adjusted the LO signal there. However, this is probably not the case for the X arm. 

In any case, I found the bug in my RMS calculation. (I had forgotten to flip the x array in addition to the y array for the right-to-left integration, and had uneven bin spacing, so the integration bandwidths weren't correct...)

Here are the updated plots. The properly evaluated RMS is ~600Hz, which seems to mostly come in around 10k, so we may want to turn down the gain for less gain peaking in that region. 

xGComparison.pdf xGspectra.pdf

  10465   Sun Sep 7 17:06:38 2014 ranaUpdateGreen Lockingnew X Green PDH measurements

600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m. 

600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.

However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.

  10471   Mon Sep 8 14:14:13 2014 JenneUpdateGreen Lockingnew Y Green PDH measurements

These are plots and notes from last week's PDH adventures. 


For the PDH servo box re-design, we wanted to think a little bit about what we actually wanted out of the box.

* We want the zero of the main transfer function to be at the same frequency as the cavity pole for green, which is about 18kHz.

* We want the boost to suppress noise at a few hundred Hz.  We don't need super-duper low-frequency boost, nor do we want it.  We'd like to leave the boost on all the time.

* Wanted to get rid of 10dB attenuator on PD input, so needed to lower the overall gain.

* We acknowledge that the gain of the raw error signal times the PZT response is very high, so no matter what, we will have to have a low-gain servo, even perhaps have the servo shape be less than unity gain.

---> We reduced the gain of the first amplification stage from a gain of 20 to a gain of 3.

---> Made the boost stage have a DC gain of 1.  Pole at 75 Hz and Zero at 1.6kHz to give suppression at a few hundred Hz.  Boost is *not* a pure integrator, so that we can leave it on.  (If we required triggering anyway, we would have made it a pure integrator).

---> In transfer function stage, put zero at 17.7kHz to match cavity pole.  Pole of servo was going to be at 20 Hz, but we wanted a little more gain, so we lowered it to 2 Hz.

Here is the final measured servo box transfer function for the Yend box (with an arbitrary gain knob setting):

PDHboxTF.png


Once installed, I set the gain knob for the Yend at 4.0, which gave an overall UGF of about 10kHz.  Then I measured the loop:

LoopGain.png

I also measured the error point and the control point, and compared them to Q's measurements in elog 10430.

ErrSpecCompare.png

ControlSpectrumCompare.png


In order to see what we might expect for a contribution to ALS noise, I looked at the error point spectra and lowpassed it with a pole at 200Hz.  I do this because the PDH error is like sensor noise for the ALS, but the ALS UGF is around 200 Hz, so noise at frequencies higher than that will be suppressed like 1/f.  So, I lowpass the error signal, then look at the RMS, and see that we should be pretty happy with our result. I include also the Xend error spectrum, as measured and reported by Q in elog 10460.

XvsY_ALScontribution.png

Attachment 6: Yend_4Sept2014.zip
ELOG V3.1.3-