40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 49 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  15480   Tue Jul 14 16:52:47 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Koji and I had a discussion last Friday about the suspension electronics. I think there are still a few open questions - see Attachment #1. We should probably make a decision on these soon.

Other useful links:

  1. High-voltage coil driver circuit - D1900163
    • This board is ready to be fabricated and tested on the bench.
    • The way the connectors J2 and J3 are designed currently is meant to interface with the existing coil driver electronics.
    • Depending on the eventual coil driver we choose for the fast path, it may be benificial to change the signals on the connectors J2 and J3, to avoid the need for a custom interface board.
  2. HAM-A coil driver noise analysis.
    • The linked attachment evaluates the noise for the design value of the fast path series resistor, which is 1.2 kohms.
    • Iff we still have ambitions of measuring ponderomotive squeezing, we will need the resistance to be much higher, ~10 kohms (in the linked noise budget, only the Johnson noise of the series resistor is considered, but in reality, the OpAmp voltage and current noises also matter). 
    • This corresponds to a maximum current of 10V/10kohms = 100uA
    • Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).
    • So we may need a version of the fast coil driver that supports a low noise mode (with large series resistance) and a high-range mode (with lower series resistance for lock acquisition).
  3. You can follow the links to DCC entries for other parts from Attachment #1.
Attachment 1: coilDriverSchem.pdf
coilDriverSchem.pdf
  15494   Mon Jul 20 17:23:46 2020 gautamUpdateElectronicsCoil drivers for the test masses

Summary:

Looking at the signals to the test mass coils, it seems borderline to me that we will be able to acquire lock and run in a low noise configuration with the same series resistor in the coil driver circuit. The way I see it, options are:

  1. Use a moderately high series resistance (e.g. 5 kohms) for the time being, and go ahead with the HAM-A coil driver.
    • This will mean a current noise of ~3pA/rtHz, which translates to ~3e-18 m/rtHz @ 100 Hz in DARM displacement noise (assuming the ITMs have much higher series resistance than the ETMs).
    • If the lock acquisiton looks smooth, double the resistance to 10 kohms.
    • With 5 kohm series resistance, there is negligible possibility of measuring ponderomotive squeezing for any of the input powers we consider feasible, but this is under the assumption that we will expose coil driver noise, which is very optimistic imho.
  2. Re-design a new coil driver that allows switchable impedance, so we can have a higher noise acquisition mode for acquiring and holding the ALS lock, then transition to a lower noise, lower range config once the RF / BHD lock has been acquired.
    • On paper, this solves all the problems, but the design of such a circuit is probably pretty non-trivial and time consuming.

Details:

I only looked at the ETMs for this study. The assumption is that we will have no length actuation on the ITMs, only local damping and Oplev loops (and maybe some ASC actuation?), which can be sufficiently low-pass filtered such that even with coil de-whitening, we won't have any range issues.

Attachment #1 shows the time-domain traces of the coil driver signals as we transition from POX/POY lock to the ALS lock. There are some transients, but I think we will be able to hold the lock even with a 5 kohm resistor (~twice what is on ETMX right now). From just these numbers, it would seem we can even go up to 10 kohms right away and still be able to acquire lock, especially if we re-design the digital feedback loop to have better low-pass filtering of the high-frequency ALS noise, see the next attachment.

Attachment #2 shows the f-domain picture, once the arm lengths are fully under ALS control (~25 seconds onwards in Attachment #1). The RMS is dominated by high frequency ALS length loop noise, which we can possibly improve with better design of the digital control loop.

Finally, Attachment #3 shows the situation once DARM control has been transitioned over to AS55_Q. Note that the vertex DoFs are still under 3f control, so there is the possibility that we can make this even lower noise. However, one thing that is not factored in here is that we will have to de-whiten these signals to low-pass filter the DAC noise (unless there is some demonstrated clever technique with noise-mons or something to subtract the DAC noise digitally). Nevertheless, it seems like we can run safely with 5 kohms on each ETM coil and still only use ~2000 cts RMS, which is ~1/10th the DAC range (to allow for dealing with spurious transients etc). 

Quote:

Looking at signals to the ETMs from the current lock acquisition sequence, the RMS current to a single coil is approximately _____ (to be filled in later).

Attachment 1: ALSlock_timeDomain.pdf
ALSlock_timeDomain.pdf
Attachment 2: ALSlock.pdf
ALSlock.pdf
Attachment 3: RFlock.pdf
RFlock.pdf
  13082   Tue Jun 27 16:11:28 2017 gautamUpdateElectronicsCoil whitening

I got back to trying to engage the coil driver whitening today, the idea being to try and lock the DRMI in a lower noise configuration - from the last time we had the DRMI locked, it was determined that A2L coupling from the OL loops and coil driver noise were dominant from ~10-200Hz. All of this work was done on the Y-arm, while the X-arm CDS situation is being resolved.

To re-cap, every time I tried to do this in the last month or so, the optic would get kicked around. I suspected that the main cause was the insufficient low-pass filtering on the Oplev loops, which was causing the DAC rms to rail when the whitening was turned on. 

I had tried some loop-tweaking by hand of the OL loops without much success last week - today I had a little more success. The existing OL loops are comprised of the following:

  • Differentiator at low frequencies (zero at DC, 2 poles at 300Hz)
  • Resonant gain peaked around 0.6 Hz with a Q of ______ (to be filled in)
  • BR notches 
  • A 2nd order elliptic low pass with 2dB passband ripple and 20dB stopband attenutation

THe elliptic low pass was too shallow. For a first pass at loop shaping today, I checked if the resonant gain filter had any effect on the transmitted power RMS profile - turns out it had negligible effect. So I disabled this filter, replaced the elliptic low pass with a 5th order ELP with 2dB passband ripple and 80dB stopband attenuation. I also adjusted the overall loop gain to have an upper UGF for the OL loops around 2Hz. Looking at the spectrum of one coil output in this configuration (ITMY UL), I determined that the DAC rms was no longer in danger of railing.

However, I was still unable to smoothly engage the de-whitening. The optic again kept getting kicked around each time I tried. So I tried engaging the de-whitening on the ITM with just the local damping loop on, but with the arm locked. This transition was successful, but not smooth. Looking at the transmon spot on the camera, every time I engage the whitening, the spot gets a sizeable kick (I will post a video shortly).  In my ~10 trials this afternoon, the arm is able to stay locked when turning the whitening on, but always loses lock when turning the whitening off. 

The issue here is certainly not the DAC rms railing. I had a brief discussion with Gabriele just now about this, and he suggested checking for some electronic voltage offset between the two paths (de-whitening engaged and bypassed). I also wonder if this has something to do with some latency between the actual analog switching of paths (done by a slow machine) and the fast computation by the real time model? To be investigated.

GV 170628 11pm: I guess this isn't a viable explanation as the de-whitening switching is handled by the one of the BIO cards which is also handled by the fast FEs, so there isn't any question of latency.

With the Oplev loops disengaged, the initial kick given to the optic when engaging the whitening settles down in about a second. Once the ITM was stable again, I was able to turn on both Oplev loops without any problems. I did not investigate the new Oplev loop shape in detail, but compared to the original loop shape, there wasn't a significant difference in the TRY spectrum in this configuration (plot to follow). This remains to be done in a systematic manner. 

Plots to support all of this to follow later in the evening.

Attachment #1: Video of ETMY transmission CCD while engaging whitening. I confirmed that this "glitch" happens while engaging the whitening on the UL channel. This is reminiscent of the Satellite Box glitches seen recently. In that case, the problem was resolved by replacing the high-current buffer in the offending channel. Perhaps something similar is the problem here?

Attachment #2: Summary of the ITMY UL coil output spectra under various conditions.

 

Attachment 1: ETMYT_1182669422.mp4
Attachment 2: ITMY_whitening_studies.pdf
ITMY_whitening_studies.pdf
  4900   Tue Jun 28 15:23:21 2011 steveUpdateElectronicsCoilcraft RF-design kits are restocked

Our design kits are full again. They are waiting for a new brilliant PD design.

Attachment 1: P1070917.JPG
P1070917.JPG
Attachment 2: P1070915.JPG
P1070915.JPG
  13862   Fri May 18 09:13:41 2018 PoojaUpdateSUSColored GigE image

To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.

 

Attachment 1: Image__2017-11-14__08-25-13_100k100g1V_colored.png
Image__2017-11-14__08-25-13_100k100g1V_colored.png
Attachment 2: Image__2017-11-14__08-25-13_100k100g1V.tiff
  5676   Mon Oct 17 10:43:14 2011 MirkoUpdateCDSCommited changes to c1rfm

I want to make changes to c1rfm. Found uncommited changes to it from Sept 27. Since we recompiled it since then it should be safe to commit them, so I did. See svn log for details.

  12145   Wed Jun 1 16:28:28 2016 ericqUpdateElectronicsCommon board Op amp input offsets

I used a Eurocard extension board to peek at the inputs and outputs of each of the gain-ladder AD829s on input B of the CM board in the +31dB configuration with the input terminated. (i.e with the following stages active in this order: +16dB, +8dB, +4dB, +2dB, +1dB).

The voltages I observed imply that the +8dB stage has an input voltage offset of -2mV, whereas all the other positive gain stages show around +-0.5mV. This could explain the shift observed at the +15->+16 transition. (However, since both input channels show a jump here, maybe its something more systemic about the board...)

In any case, it should be simple enough to swap out a new AD829 in place of U9B and see if it improves things, before getting too deep into the muck. (In principle, the AD829 has offset nulling pins, but I'm not sure how to do it in a non-hacky way since the board doesn't have any pads for it.)

  12147   Fri Jun 3 12:53:44 2016 ericqUpdateElectronicsCommon board Op amp input offsets

I replaced some of the AD829s with other AD829s, but the offset situation didn't improve.

However, I figured that we don't really need the ~100MHZ bandwidth of the AD829, since the IMC loop limits us to a ~10kHz CARM bandwidth. Also, since we don't routinely use IN2 for anything, I felt free to try something else. 

Specifically, I replaced all of the positive gain AD829s in the input 2 gain ladder with OP27s (U8B->U12B on D1500308), which should have input offset voltages ~30x lower than the AD829s. 

Here is a comparison of the outputs these configurations perform, normalized to the output at the +0dB gain setting - where all of the op amps in the gain ladder are bypassed. 

So, most of the transitions now result in an output offset change of less than 0.5mV, which is nice.

The exception seems to be where the +8dB stage is switched in or out. I may try replacing this one, as these transitions cause a lock loss now when trying to lock the arm with high bandwidth using POY.

  8922   Thu Jul 25 12:53:45 2013 CharlesUpdateISSComparator + Triggering Prototype

 I realized I totally forgot to post this last week, but I prototyped the comparator and boost triggering portion of the ISS, at least in part. Below is a schematic that shows the prototype circuit I made. Note that it includes ports for the oscilloscope channels that appear in the second image included. Essentially, I was able to verify that the output from the LT1016, as it's currently constructed in the ISS schematic, would be sufficient logic to switch the MAX333a.

Comparator_Prototype.png

Below, we can first see that the comparator is switching its output as desired. When the DC level of the input drops below a certain threshold (~1.6 V) the output of the comparator switches on to ~4 V. When the DC level of the input goes back up above the upper threshold (~3.2 V), the comparator switches off to ~0.3 V. The exact values of the threshold voltages can be determined/tuned at a later date, but this is the basic behavior that the comparator circuit will have.

To detect whether or not the MAX333a was switching properly, I connected the common terminal of one of the switches to a +5 V supply, and looked at the voltage coming off both the 'open' and 'closed' terminals of said SPDT switch. We can see that with Logic 0 (comparator output ~0.3 V) Channel 4 exhibits a ~5 V signal, just as we would expect from the above schematic. With Logic 1 (comparator output ~4 V), Channel 3 exhibits the characteristic 5 V signal.

Comp_Triggering_Behavior.jpg

  1172   Wed Dec 3 20:10:09 2008 Jenne, RanaUpdatePEMComparing Wiener subtraction with different seismometers
Attached is a plot of MC_L, and then the residual MC_L after static Wiener filtering, using different combinations of our accelerometers and seismometers.

This is the same type of plot that Rana has included in the past few weeks, using Wiener filters calculated with c1wino.m

This data is from GPS 912312914, duration = 7200 sec, sometime during the night last night.

Unfortunately, it doesn't look like adding the Guralp seismometer to the Accelerometers and the Ranger did much, especially at low frequencies (all sensors = black curve). We'll have to investigate why this is true, and what we can do to get some low-frequency subtraction going on.

In the legend, "Residuals Accels, Guralp, Ranger" implies that the residual has been calculated using all of the sensors listed.
Attachment 1: Dec032008_c1wino_seisCombos.png
Dec032008_c1wino_seisCombos.png
  1173   Wed Dec 3 20:36:07 2008 Jenne, RanaUpdatePEMComparing Wiener subtraction with different seismometers
The Ranger has now been moved over to sit underneath the MC2 tank (it was previously close to the PSL rack). It
is still pointed in the +Y direction (towards ETMY, aka south).

New spectra attached - looks like the coherence is still there between the Guralp and the Ranger which are now
seperated by the MC length (~12 m). At LLO, I have witnessed a coherence of less than 0.3 above 1 Hz for these
distances. Curious.

L960019-00-F describes measurements done at SLAC on seismic coherence. The iLIGO LSC PDD
(http://www.ligo.caltech.edu/docs/T/T970122-00.pdf) discusses in sec 4.2 how this was incorporated into the LSC design.

When we get our next Guralp, it will be interesting to move them around and determine what the cross-spectrum
is between different points in the lab during typical times.

In the second attachment, I have plotted the square of the quantity used in the LSC PDD (S_xy) which I think is
what we now plot in DTT as 'Coherence'.

The third attachment shows the coherences among the TM SUSPOS_INs. I've turned off the oplev servos for this but
the OSEM damping is still on. Its not quite the same as the theory, but we could probably measure/tweak the
seismic velocity and then get better agreement.
Attachment 1: d.pdf
d.pdf
Attachment 2: sco.png
sco.png
Attachment 3: fly.pdf
fly.pdf
  379   Fri Mar 14 14:59:51 2008 josephbConfigurationCamerasComparison between GC650 (CCD) and GC750 (CMOS) looking at ETMX
Attached are images taken of ETMX while locked.

The first two are 300,000 microsecond exposure time, with approximately the same focusing/zoom. (The 750 is slightly more zoomed in than the 650 in these images). The second are 30,000 microsecond exposures. The la

The CMOS appears to be more sensitive to the 1064 nm reflected light (resulting in bright images for the same exposure time). This may make a difference in applications where images are desired to be taken quickly and repeatedly.

Both seem to be resolving individual specks on the optic reasonably well.

Next test is to place both camera on a Gaussian beam (in a couple different modes say 00, 11, and so forth), probably using the PMC.
Attachment 1: ETMX_z2_exp_300000_650.tiff
Attachment 2: ETMX_z2_exp_300000_750.tiff
Attachment 3: ETMX_z2_exp_30000_650.tiff
Attachment 4: ETMX_z2_exp_30000_750.tiff
  4632   Thu May 5 04:38:20 2011 KojiSummaryLSCComparison between S3399 and FFD-100

Comparison between Hamamatsu S3399 and Perkin Elmer FFD-100

These are the candidates for the BB PD for the green beat detection as well as aLIGO BB PD for 532nm/1064nm.

FFD-100 seems the good candidate.

 

Basic difference between S3399 and FFD-100

- S3399 Si PIN diode: 3mm dia., max bias = 30V, Cd=20pF

- FFD-100 Si PIN diode: 2.5mm dia., max bias = 100V, Cd=7pF

 

The circuit at the page 1 was used for the amplifier.

- FFD-100 showed 5dB (= x1.8) larger responsivity for 1064nm compared with S3399. (Plot not shown. Confirmed on the analyzer.)

- -3dB BW: S3399 180MHz, FFD-100 250MHz for 100V_bias. For 30V bias, they are similar.

Attachment 1: PD_response.pdf
PD_response.pdf PD_response.pdf PD_response.pdf
  16923   Thu Jun 16 17:40:15 2022 YehonathanUpdateBHDComparison of MICH OLTF model with measurement

I made some progress in modeling MICH loop.

Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).

There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:

1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.

2. The coil driver gain (found to be 45), which I should measure.

I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.

The coil driver gain I find by making the measurement and model overlap.

However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.

Details

The model can be summarized with these lines of code (I assume that the product of the ADCs(DACs) and and whitening(dewhitening) filters is unity):

BS2AS55 = TFs["AS_f2"]["BS"]

PD_responsivity = 1e3*0.8 #V/W
ADC_TF = 3276.8 #cts/V
demod_gain = 6.77 #According to https://wiki-40m.ligo.caltech.edu/Electronics/LSC_demoddulators
whitening_gain = 10**(24/20) #24 dB
BS2MICH = BS2AS55*PD_responsivity*demod_gain*whitening_gain*ADC_TF

DAC_TF = 6.285e-4 #V/cts, elog 16161

coil_TF = 0.016 #Newton/Ampere per coil, elog 15846 

coil_R = 20e3 #Ohm

actuation_TF = DAC_TF*coil_TF/coil_R


OLTF = (BS2MICH*MICH_ctrl_cmplx*-6*0.5 + OSEM_filters_cmplx*OSEM_TF*2.22)*coil_filters_cmplx*actuation_TF*SUS_cmplx*45

  • BS2AS55 is the optical plant, calculated with Finesse
  • MICH_ctrl_cmplx is the MICH control filter with gain of -6
  • 0.5 factor comes from the LSC output matrix
  • OSEM_TF is the product of the OSEMs input filters and damping loop filters.
  • coil_filters_cmplx are the coil filters
  • SUS_cmplx is the suspension transfer function (w0 = 1Hz, Q=200)
Attachment 1: MICH_Model_Measurement_Comparison.pdf
MICH_Model_Measurement_Comparison.pdf
  16927   Fri Jun 17 12:05:32 2022 YehonathanUpdateBHDComparison of MICH OLTF model with measurement

I should write down what I didn't include for completeness:

1. AA filters

2. AS55 input 60Hz comb filter

3. Violin filters

After discussing with Paco, we agreed that the discrepancy in the MICH calibration might come from the IQ mixing angle which for the IFO is not optimized, while in Finesse is set such that all the amplitude is in one quadrature.

Quote:

I made some progress in modeling MICH loop.

Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).

There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:

1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.

2. The coil driver gain (found to be 45), which I should measure.

I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.

The coil driver gain I find by making the measurement and model overlap.

However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.

  16928   Fri Jun 17 13:07:08 2022 KojiUpdateBHDComparison of MICH OLTF model with measurement

I'm curious why the actual OLTF included the 60Hz comb...? It is undesirable to have such structure in the OLTF around the UGF as it can cause servo instability.
And if you remove them, you don't need to model them :-)

  1999   Thu Sep 24 20:17:05 2009 ranaSummaryLSCComparison of Material Properties for the new RFPD Mounts
  Steel Brass Aluminum Delrin
Density (kg/m^3) 7850 8500 2700 1420
CTE (ppm/C) 12 19 23 100

Young's

Modulus

(GPa)

200 110 69 2
Hardness        
Color grey gold light silver any

 

  3855   Wed Nov 3 17:01:01 2010 josephbSummaryCDSComparison of RFM read times

Problem:

RFM reads are slow.  Rolf has said it should take 2-3 microseconds per read. 

c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.

Hypothesis:

The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card.  Its possible this crowded bus is causing the reads to take even longer.

Test Results:

Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.

c1ioo:

No RFM reads: 8 microseconds

3 RFM reads: 20 microseconds (~4 per read)

6 RFM reads: 32 microseconds (~4 per read)

c1sus:

No RFM read: 25 microseconds (bigger model)

1 RFM read: 33 microseconds (~8 per read)

3 RFM read: 45 microseconds (~7 per read)

6 RFM read: Over 62 microseconds, doesn't run.

Conclusion:

It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.

The c1mcs and c1ioo models have been reverted to their normal operations.

 

  13938   Mon Jun 11 11:45:13 2018 keerthana UpdateelogComparison of the analytical and finesse values of TMS and FSR.
Quantity Analytical Value Finesse Value Percentage Error
Free Spectral range (FSR) 3.893408 MHz 3.8863685 MHz 0.180 %
Transverse Mode Spacing (TMS) 1.195503 MHz 1.1762885 MHz 1.607 %

The values obtained from both analytical and finesse solution is given in the above table along with the corresponding percentage errors.finesse1.pdf

The parameters used for this calculation are listed below.

Parameter Value
length of the cavity (L) 38.5 m
Wavelength of the laser beam (\lambda) 1064 nm
Radius of curvature of ITM (R1) \infty
Radius of curvature of ETM (R2) 58 m

The cavity scan data obtained from Finesse is also attached here.

Attachment 1: finesse1.pdf
finesse1.pdf
  13941   Mon Jun 11 18:10:51 2018 Koji UpdateelogComparison of the analytical and finesse values of TMS and FSR.

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

  13943   Mon Jun 11 19:16:49 2018 keerthanaUpdateelogComparison of the analytical and finesse values of TMS and FSR.

The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

But inorder to find the finesse value, I just used curser to get the central frequency of each peak and by substracting one from the other I found TMS and FSR.

The resolution was 6500 Hz. Thus, it seems that this method is not actually reliable. I am trying to find the central frequency of each mode with the help of lorentzian fits. I am attaching a fit which I did today. I have plotted its residual graph also.

I am uploading 4 python scripts to the github.

1. Analytical Solution

2. Finesse model- cavity scan

3. Finesse model- fitting

4. Finesse model- residual

Quote:

Hmm? What is the definition of the percentage error? I don't obtain these numbers from the given values.
And how was the finesse value obtained from the simulation result? Then what is the frequency resolution used in Finesse simulation?

fitting_1.pdf

Attachment 1: fitting_1.pdf
fitting_1.pdf
  13944   Mon Jun 11 22:05:03 2018 KojiUpdateelogComparison of the analytical and finesse values of TMS and FSR.

> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

Yes, I this does not give us 0.70%

(3.893408 - 3.8863685)/3.893408 *100 = 0.18%

But any way, go for the fitting.

  13945   Mon Jun 11 22:18:18 2018 keerthanaUpdateelogComparison of the analytical and finesse values of TMS and FSR.

Oopss !! I made a mistake while taking the values from my notes. Sorry.

Quote:

> The percentage error which I found out =[(analytical value - finesse value)/analytical value]*100

Yes, I this does not give us 0.70%

(3.893408 - 3.8863685)/3.893408 *100 = 0.18%

But any way, go for the fitting.

 

  3339   Sat Jul 31 04:03:11 2010 GopalSummaryOptic StacksComplete Displacement Translational Transfer Function Matrix

Over the past 36 hours, I've run full-fledged FDAs on KALLO.

The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."

Progress_Report_2.png

Next steps:

1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.

2) Figure out how to do the same types of tests for phase instead of displacement.

  16647   Fri Feb 4 10:21:39 2022 AnchalSummaryGeneralComplete lab shutdown

Please edit this same entry throughout the day for the shutdown elogging.

I took a screenshot of C0VAC_MONITOR.adl to ensure that all pnematic valves are in closed positions:

The status message says "All pnematic valves closed" and the latest error message is about "V7 closed, N2 < 6.50e+01".

I found out that there was no autoburt happening for c1vac channels. I created an autoBurt.req file for the vac.db file and saved one snapshot. I also added the path of this file in autoburt/.requestfilelist . Let's see if autoburting starts by that for this file as well.

With this, I think we can safely shutdown acromag chassis. Hopefully, the relays are configured such that the valves are nominally closed in absence of a control signal. After the chassis is shut down, wwe can shutdown C1VAC by:

sudo shutdown

[Chub, Jordan]

At the 1x8 rack, the following were switched off on their respective front panels:

PTP2 & PTP3 Controller
MKS Gauge controller
PRP Gauge Controller
G2P316a & b Controllers
Sorenson
Serial Device Server
Both UPS's

Powered off from back of unit:

TP1 Controller
Acromag chassis

TP2 and 3 controllers were unplugged from respective power strips (labeled C2 and C3)

C1vac and the laptop at the workstation were shut down

Manual Gate valve was closed

  15204   Mon Feb 10 15:54:47 2020 JordanUpdatePSLCompleted Acromag Wiring

All spare channels on the PSL acromag chassis are connected with ~12in of spare wiring for future use.

  4913   Wed Jun 29 22:35:06 2011 NicoleSummarySUSCompleted Quad photodiode Box Circuit Diagrams

I have finished drawing the circuit diagrams for the quad photodiode boxes. Here are copies of the circuit diagram.

There are three main operation circuits in the quad photdiode box: a summing circuit (summing the contributions from the four inputs),

a Y output circuit (taking the difference between the input sums 3+2 and 1+4), and an X output circuit (taking the difference between the

input sums 3+4 and 1+2). I will complete an mini report on my examination and conclusions of the QPD circuit for the suspension wiki tomorrow.

summingcircuit.jpgQPDYcircuit.jpgQPDX_2circuit.jpg

 

  3180   Thu Jul 8 16:24:30 2010 GopalUpdateOptic StacksCompletion of single stack layer

Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.

  9708   Mon Mar 10 21:12:30 2014 KojiSummaryLSCComposite Error Signal for ARms (1)

The ALS error (i.e. phase tracker output) is linear everywhere, but noisy.
The 1/sqrt(TR) is linear and less noisy but is not linear at around the resonance and has no sign.
The PDH signal is linear and further less noisy but the linear range is limited.

Why don't we combine all of these to produce a composite error signal that is linear everywhere and less-noisy at the redsonance?

This concept was confirmed by a simple mathematica calculation:

The following plot shows the raw signals with arbitorary normalizations

1) ALS: (Blue)
2) 1/SQRT(TR): (Purple)
3) PDH: (Yellow)
4) Transmission (Green)

The following plot shows the preprocessed signals for composition

1) ALS: no preprocess (Blue)
2) 1/SQRT(TR): multiply sign(PDH) (Purple)
3) PDH: linarization with the transmission (If TR<0.1, use 0.1 for the normalization). (Yellow)
4) Transmittion (Green)

The composite error signal

1) Use ALS at TR<0.03. Use 1/SQRT(TR)*sign(PDH)*(1-TR) + PDH*TR at TR>0.03
2) Transmittion (Purple)
 

Attachment 1: composite_linear_signal.nb.zip
  9715   Tue Mar 11 15:14:34 2014 denSummaryLSCComposite Error Signal for ARms (1)

Quote:

The composite error signal


 

 Very nice error signal. Still, I think we need to take into account the frequency shape of the transfer function TR -> CARM. 

  9717   Tue Mar 11 15:21:08 2014 KojiSummaryLSCComposite Error Signal for ARms (1)

True. But we first want to realize this for a single arm, then move onto the two arms case.
At this point we'll need to incorporate frequency dependence.

  9710   Mon Mar 10 21:14:58 2014 ericqSummaryLSCComposite Error Signal for ARms (3)

Using Koji's mathematica notebook, and Nic's python work, I set out to run a time domain simulation of the error signal, with band-limited white noise added in. 

model.png

Basically, I sweep the displacement of the cavity (with no noise), and pass it to the analytical formulae with the coefficients Koji used, with some noise added in. I also included some 1/0 protection for the linearized PDH signal. I ran a sweep, and then compared it to an ALS sweep that Jenne ran on Monday; reconstructing what the CESAR signal would have looked like in the sweep. 

The noise amounts were totally made up. 

They matched up very well, qualitatively! [Since the real sweep was done by a (relatively) noisy ALS, the lower noise of the real pdh signal was obscured.]

simSweep.pdfalsSweep.pdf

Given this good match, we were motivated to start trying to implement it on Monday. 

At this point, since we've gotten it working on the actual IFO, I don't plan on doing much more with this simulation right now, but it may come in handy in the future...

  9751   Wed Mar 26 11:16:59 2014 ericqSummaryLSCComposite Error Signal for ARms (3)

Extending the previous model, I've closed a rudimentary CESAR loop in simulink. Error signals with varying noise levels are combined to bring a "cavity" to lock.  

simlink.pdf

There are many things that are flat out arbitrary at this point, but it qualitatively works. The main components of this model are:

  • The "Plant": A pendulum with f0 = 2Hz, Q = 10
  • Some white force noise, low passed at 1Hz before input to the plant.
  • The Controller: A very rough servo design that is stable...
  • ALS signal: Infinite range Linear signal, with a bunch of noise
  • Transmission and PDH signals are computed with some compiled C code containing analytic functions (which can be a total pain to get working), have less noise than ALS
  • Some logic for computing linearized PDH and SqrtInv signals
  • A C code block for doing the CESAR mixing, and feeding to the servo

And it can lock! 

simulatedCESARLock.pdf

 

Right now, all of the functions and noise levels are similar to the previous simulation, and therefore don't tell us anything about anything real...

However, at this point, I can tune the parameters and noise levels to make it more like our interferometer, and thus maybe actually useful. 

  9711   Mon Mar 10 21:16:13 2014 KojiSummaryLSCComposite Error Signal for ARms (4)

The LSC model was modified for CESAR.

A block called ALSX_COMBINE was made in the LSC block. This block receives the signals for ALS (Phase Tracker output), TRX_SQRTINV, TRX, POX11 (Unnormalized POX11I).
It spits out the composite ALS signal.

Inside of the block we have several components:

1) a group of components for sign(x) function. We use the PDH signal to produce the sign for the transmission signal.

2) Hard triggering between ALS and TR/PDH signals. An epics channel "THRESH" is used to determine how much transmission
we should have to turn on the TR/PDH signals.

3) Blending of the TR and PDH. Currently we are using a confined TR between 0 and 1 using a saturation module. When the TR is 0, we use the 1/SQRT(TR) signal for the control,
    When the TR is 1, we use the PDH signal for the control.

4) Finally the three processed signals are combined into a single signal by an adder.


It is important to make a consideration on the offsets. We want all of ALS, 1/SQRT(TR), and PDH to have zero crossing at the resonance.
ALS tends to have arbitorary offset. So we decided to use two offsets. One is before the CESAR block and in the ALS path.
The other is after the CESAR block.
Right now we are using the XARM servo offset for the latter purpose.

We run the resonance search script to find the first offset. Once this is set, we never touch this offset until the lock is lost.
Then for the further scanning of the arm length, we uused the offset in the XARM servo filter module.

Attachment 1: ss1.png
ss1.png
Attachment 2: ss2.png
ss2.png
Attachment 3: CESAR_OFFSETS.pdf
CESAR_OFFSETS.pdf
  9712   Mon Mar 10 21:16:56 2014 KojiSummaryLSCComposite Error Signal for ARms (5)

After making the CDS modification, CESAR was tested with ALS.

First of all, we run CESAR with threshold of 10. This means that the error signal always used ALS.
The ALS was scanned over the resonance. The plot of the scan can be found in EricQ's elog.
At each point of the scan, the arm stability is limited by the ALS.

Using this scan data, we could adjust the gains for the TR and PDH signals. Once the gains were adjusted
the threshold was lowered to 0.25. This activates dynamic signal blending.

ALS was stabilized with XARM FM1/2/3/5/6/7/9. The resonance was scanned. No glitch was observed.
This is some level of success already.

Next step was to fully hand off the control to PDH. But this was not successfull. Everytime the gain for the TR was
reduced to zero, the lock was lost. When the TR is removed from the control, the raw PDH signal is used fot the control
without normalization. Without turning on FM4, we lose 60dB of DC gain. Therefore the residual motion may have been
too big for the linear range of the PDH signal. This could be mitigated by the normalization of the PDH signal by the TR.

  9718   Tue Mar 11 18:33:21 2014 KojiUpdateLSCComposite Error Signal for ARms (6)

Today we modified the CESAR block.

- Now the sign(X) function is in a block.

- We decided to use the linearization of the PDH.

- By adding the offset to the TR signal used for the switching between TR and PDH, we can force pure 1/sqrt(TR) or pure PDH to control the cavity.

Attachment 1: 14.png
14.png
  9719   Tue Mar 11 18:34:11 2014 JenneUpdateLSCComposite Error Signal for ARms (7)

[Nic, Jenne, EricQ, and Koji]

We have used CESAR successfully to bring the Xarm into resonance.  We start with the ALS signal, then as we approach resonance, the error signal is automatically transitioned to 1/sqrt(TRX), and ramped from there to POX, which we use as the PDH signal.

In the first plot, we have several spectra of the CESAR output signal (which is the error signal for the Xarm), at different arm resonance conditions.  Dark blue is the signal when we are locked with the ALS beatnote, far from IR resonance.  Gold is when we are starting to see IR resonance (arm buildup of about 0.03 or more), and we are using the 1/sqrt(TRX) signal for locking.  Cyan is after we have achieved resonance, and are using only the POX PDH signal.  Purple is the same condition as cyan, except that we have also engaged the low frequency boosts (FM 2, 3, 4) in the locking servo.  FM4 is only usable once you are at IR resonance, and locked using the PDH signal.  We see in the plot that our high frequency noise (and total RMS) decreases with each stage of CESAR (ALS, 1/sqrt(TR) and PDH). 

To actually achieve the gold noise level of 1/sqrt(TR), we first had to increase the analog gain by swapping out a resistor on the whitening board. 

 

spectra-ungarble.pdf

The other plots attached are time series data.  For the python plots (last 2), the error signals are calibrated to nanometers, but the dark blue, which is the transmitted power of the cavity, is left in normalized power units (where 1 is full IR resonance). 

In the scan from off resonance to on resonance, around the 58 second mark, we see a glitch when we engage FM4, the strong low frequency boosts.  Around the 75 second mark we turned off any contribution from 1/sqrt(TR), so the noise decreases once we are on pure PDH signal. 

In the scan through the resonance, we see a little more clearly the glitch that happens when we switch from ALS to IR signals, around the 7 and 12 second marks. 

We want to make some changes, so that the transition from ALS to IR signals is more smooth, and not a discrete switch.

 

Attachment 2: Screenshot-1.png
Screenshot-1.png
Attachment 3: ScanFromOffToOnResonance.pdf
ScanFromOffToOnResonance.pdf
Attachment 4: ScanThroughResonance.pdf
ScanThroughResonance.pdf
  9724   Thu Mar 13 01:18:00 2014 JenneUpdateLSCComposite Error Signal for ARms (8)

[Jenne, EricQ]

As Koji suggested in his email this afternoon, we looked at how much actuator range is required for various forms of arm locking:  (1) "regular" PDH lock aquisition, (2) ALS lock acquisition, (3) CESAR cooling.

To start, I looked at the spectra and time series data of the control signal (XARM_OUT) for several locking situations.  Happily, when the arm is at the half fringe, where we expect the 1/sqrt(TRX) signal to be the most sensitive (versus the same signal at other arm powers), we see that it is in fact more quiet than even the PDH signal.  Of course, we can't ever use this signal once the arm is at resonance, so we haven't discovered anything new here.

XARM_OUT_VariousErrorSignals_ungarb.pdf

EricQ then made some violin plots with the time series data from these situations, and we determined that a limit of ~400 counts encompasses most of the steady-state peak-to-peak output from locking on the PDH signal.

xarmOutViolinPlot.pdfxarmOutViolinSub.pdf

[ericq: What's being plotted here are "kernel density estimates" of the time series data of XARM_OUT when locked on these signals. The extent of the line goes to the furthest outlier, while the dashed and dotted lines indicate the median and quartiles, respectively]

I tried acquiring ALS and transitioning to final PDH signals with different limiters set in the Xarm servo.  I discovered that it's not too hard to do with a limit of 400 counts, but that below ~350 counts, I can't keep the ALS locked for long enough to find the IR resonance.  Here's a plot of acquiring ALS lock, scanning for the resonance, and then using CESAR to transition to PDH, with the limit of 400 counts in place, and then a lockloss at the end.  Even though I'm hitting the rails pretty consistently, until I transition to the more quiet signals, I don't ever lose lock (until, at the end, I started pushing other buttons...).

LimiterAt400cts.pdf

After that, I tried acquiring lock using our "regular" PDH method, and found that it wasn't too hard to capture lock with a limit of 400, but with limits below that I can't hold the lock through the boosts turning on.

noLimitPDHAcq.pdfwithLimitPDHAcq.pdf

Finally, I took spectra of the XARM_OUT control signal while locked using ALS only, but with different limiter values. Interestingly, I see much higher noise between 30-300 Hz with the limiter engaged, but the high frequency noise goes down.  Since the high frequency is dominating the RMS, we see that the RMS value is actually decreasing a bit (although not much).

XARM_OUT_VariousLimits_ungarb.pdf

We have not made any changes to the LSC model, so there is still no smoothing between the ALS and IR signals.  That is still on the to-do list.  I started modifying things to be compatible with CARM rather than a single arm, but that's more of a daytime-y task, so that version of the c1lsc model is saved under a different name, and the model that is currently compiled and running is reverted as the "c1lsc.mdl" file.

  9728   Fri Mar 14 12:18:55 2014 KojiUpdateLSCComposite Error Signal for ARms (9)

Asymptotic cooling of the mirror motion with CESAR was tested.

With ALS and the full control bandwidth (UGF 80-100Hz), the actuator amplitude of 8000cnt_pp is required.

Varying control bandwidth depending on the noise level of the signal, the arm was brought to the final configuration with the actuator amplitude of 800cnt_pp.

Attachment 1: asymptotic_cooling.pdf
asymptotic_cooling.pdf
  477   Wed May 14 14:05:40 2008 AndreyUpdateComputersComputer Linux-2, MEDM screen "Watchdogs"

Computer "Linux-2", MEDM screen "C1SUS_Watchdogs.adl": there is no indication for ETMY watchdogs, everything is white. There is information on that screen "C1SUS_Watchdogs.adl" about all other systems (MC, ETMX,...), but something is wrong with indicators for ETMY on that particular control computer.
  447   Fri Apr 25 11:33:40 2008 AndreyConfigurationComputersComputer controlling vaccum equipment

Old computer (located in the south-end end of the interferometer room) that was almost unable to fulfill his duties of controlling vacuum equipment has been replaced to "Linux-3". MEDM runs on "Linux-3".

We checked later that day together with Steve Vass that vacuum equipment (like vacuum valves) can be really controlled from the MEDM-screen 'VacControl.adl'.

Unused flat LCD monitor, keyboard and mouse (parts of the former LINUX-3 computer) were put on the second shelf of the computer rack in the computer room near the HP printer.
  192   Sun Dec 16 16:52:40 2007 dmassUpdateComputersComputer on the end Fixed
I had Mike Pedraza look at the computer on the end (tag c21256). It was running funny, and turns out it was a bad HD.

I backed up the SURF files as attachments to their wiki entries. Nothing else seemed important so the drive was (presumably) swapped, and a clean copy of xp pro was installed. The username/login is the standard one.

Also - that small corner of desk space is now clean, and it would be lovely if it stayed that way.
  10010   Mon Jun 9 11:42:00 2014 JenneUpdateCDSComputer status

Current computer status:

All fast machines except c1iscey are up and running. I can't ssh to c1iscey, so I'll need to go down to the end station and have a look-see. On the c1lsc machine, neither the c1oaf nor the c1cal models are running (but for the oaf model, we know that this is because we need to revert the blrms block changes to some earlier version, see Jamie's elog 9911).

Daqd process is running on framebuilder.  However, when I try to open dataviewer, I get the popup error saying "Can't connect to rb", as well as an error in the terminal window that said something like "Error getting chan info".

Slow machines c1psl, c1auxex and c1auxey are not running (can't telnet to them, and white boxes on related medm screens for slow channels).  All other slow machines seem to be running, however nothing has been done to them to point them at the new location of the shared hard drive, so their status isn't ready to green-light yet.


Things that we did on Friday for the fast machines:

The shared hard drive is "physically" on Chiara, at /home/cds/.  Links are in place so that it looks like it's at the same place that it used to be:  /opt/rtcds/...... 

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]


The slow front ends that we have tried changing have not worked out. 

First, we tried plugging a keyboard and monitor into c1auxey.  When we key the crate to reboot the machine, we get some error message about a "disk A drive error", but then it goes on to prompt pushing F1 for something, and F2 for entering setup.  No matter what we press, nothing happens.  c1auxey is still not running.

We were able to telnet into c1auxex, c1psl, and c1iool0.  On each of those machines, at the prompt, we used the command "bootChange".  This initially gives us a series of:

$ telnet c1susaux
Trying 192.168.113.55...
Connected to c1susaux.
Escape character is '^]'.

c1susaux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.55:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1susaux
startup script (s)   : /cvs/cds/caltech/target/c1susaux/startup.cmd
other (o)            :

value = 0 = 0x0
c1susaux >

If we go through that again (it comes up line-by-line, and you must press Enter to go to the next line) and put a period a the end of the Host Name line, and the Host Inet (h) line, they will come up blank the next time around.  So, the next time you run bootChange, you can type "chiara" for the host name, and "192.168.113.104" for the "host inet (h)".  If you run bootChange one more time, you'll see that the new things are in there, so that's good.

However, when we then try to reboot the computer, I think the machines weren't coming back after this point.  (Unfortunately, this is one of those things that I should have elogged back on Friday, since I don't remember precisely).  Certainly whatever the effect was, it wasn't what I wanted, and I left with the machines that I had tried rebooting, not running.

  10011   Mon Jun 9 12:19:17 2014 ericqUpdateCDSComputer status

Quote:

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]

In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.

On control room computers, we mount the NFS through /etc/fstab having lines like:

192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0

Then, things like /cvs/cds/foo are locally symlinked to /opt/foo

For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes

master:/diskless/root                   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc     proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt      nfs    async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock  0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock  0 0

("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)

and /diskless/root/etc/resolv.conf becomes:

search martian

nameserver 192.168.113.104 #Chiara

 

 

  10585   Wed Oct 8 15:31:31 2014 JenneUpdateCDSComputer status

After the Great Computer Meltdown of 2014, we forgot about poor c0rga, which is why the RGA hasn't been recording scans for the past several months (as Steve noted in elog 10548).

Q helped me remember how to fix it.  We added 3 lines to its /etc/fstab file, so that it knows to mount from Chiara and not Linux1.  We changed the resolv.conf file, and Q made some simlinks.

Steve and I ran ..../scripts/RGA/RGAset.py on c0rga to setup the RGA's settings after the power outage, and we're checking to make sure that the RGA will run right now, then we'll set it back to the usual daily 4am run via cron.

EDIT, JCD:  Ran ..../scripts/RGA/RGAlogger.py, saw that it works and logs data again.  Also, c0rga had a slightly off time, so I ran sudo ntpdate -b -s -u pool.ntp.org, and that fixed it.

Quote:

 

In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.

On control room computers, we mount the NFS through /etc/fstab having lines like:

192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0

Then, things like /cvs/cds/foo are locally symlinked to /opt/foo

For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes

master:/diskless/root                   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc     proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt      nfs    async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock  0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock  0 0

("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)

and /diskless/root/etc/resolv.conf becomes:

search martian

nameserver 192.168.113.104 #Chiara

 

 

 

  10018   Tue Jun 10 09:25:29 2014 JamieUpdateCDSComputer status: should not be changing names

I really think it's a bad idea to be making all these names changes.  You're making things much much harder for yourselves.

Instead of repointing everything to a new host, you should have just changed the DNS to point the name "linux1" to the IP address of the new server.  That way you wouldn't need to reconfigure all of the clients.  That's the whole point of  name service: use a name so that you don't need to point to a number.

Also, pointing to an IP address for this stuff is not a good idea.  If the IP address of the server changes, everything will break again.

Just point everything to linux1, and make the DNS entries for linux1 point to the IP address of chiara.  You're doing all this work for nothing!

RXA: Of course, I understand what DNS means. I wanted to make the changes to the startup to remove any misconfigurations or spaghetti mount situations (of which we found many). The way the VME162 are designed, changing the name doesn't make the fix - it uses the number instead. And, of course, the main issue was not the DNS, but just that we had to setup RSH on the new machine. This is all detailed in the ELOG entries we've made, but it might be difficult to understand remotely if you are not familiar with the 40m CDS system.

  9662   Mon Feb 24 13:40:13 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

I noticed that the fb lights on all of the models on the c1lsc machine are red, and that even though the MC was locked, there was no light flashing in the IFO. Also, all of the EPICS values on the LSC screen were frozen.

Screenshot-Untitled_Window-1.png

I tried restarting the ntp server on the frame builder, as in elog 9567, but that didn't fix things.  (I realized later that the symptom there was a red light on every machine, while I'm just seeing problems with c1lsc. 

I did an mxstream restart, as a harmless thing that had some small hope of helping (it didn't). 

I logged on to c1lsc, and restarted all of the models (rtcds restart all), which stops all of the models (IOP last), and then restarts them (IOP first).  This did not change the status of the lights on the status screen, but it did change the positioning of some optics (I suspect the tip tilts) significantly, and I was again seeing flashes in the arms.  The LSC master enable switch was off, so I don't think that it was trying to send any signals out to the suspensions.  The ASS model, which sends signals out to the input pointing tip tilts runs on c1lsc, and it was about when the ass model was restarted that the beam came back.  Also, there are no jumps in any of the SOS OSEM sensors in the last few hours, except me misaligning and restoring the optics.  I we don't have sensors on the tip tilts, so I can't show a jump in their positioning, but I suspect them.

I called Jamie, and he suggested restarting the machine, which I did.  (Once again, the beam went somewhere, and I saw it scattering big-time off of something in the BS chamber, as viewed on the PRM-face camera).  This made the oaf and cal models run (I think they were running before I did the restart all, but they didn't come back after that.  Now, they're running again).  Anyhow, that did not fix the problem.  For kicks, I re-ran mxstream restart, and diag reset, to no avail.  I also tried running the sudo /etc/init.d/ntp-client restart command on just the lsc machine, but it doesn't know the command 'ntp-client'. 

Jamie suggested looking at the timing card in the chassis, to ensure all of the link lights are on, etc.  I will do this next.

  9663   Mon Feb 24 15:25:29 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

The LSC machine isn't any better, and now c1sus is showing the same symptoms.  Lame.

The link lights on the c1lsc I/O chassis and on the fiber timing system are the same as all other systems.  On the timing card in the chassis, the light above the fibers was solid-on, and the light below blinks at 1pps. 

Koji and I power-cycled both the lsc I/O chassis, and the computer, including removing the power cables (after softly shutting down) so there was seriously no power.  Upon plugging back in and turning everything on, no change to the timing status.  It was after this reboot that the c1sus machine also started exhibiting symptoms. 

  10717   Fri Nov 14 15:45:34 2014 JenneUpdateCDSComputers back up after reboot

[Jenne, Q]

Everything seems to be back up and running.

The computers weren't such a big problem (or at least didn't seem to be).  I turned off the watchdogs, and remotely rebooted all of the computers (except for c1lsc, which Manasa already had gotten working).  After this, I also ssh-ed to c1lsc and restarted all of the models, since half of them froze or something while the other computers were being power cycled. 

However, this power cycling somehow completely screwed up the vertex suspensions.  The MC suspensions were fine, and SRM was fine, but the ITMs, BS and PRM were not damping.  To get them to kind of damp rather than ring up, we had to flip the signs on the pos and pit gains.  Also, we were a little suspicious of potential channel-hopping, since touching one optic was occasionally time-coincident with another optic ringing up.  So, no hard evidence on the channel hopping, but suspicions.

Anyhow, at some point I was concerned about the suspension slow computer, since the watchdogs weren't tripping even though the osem sensor rmses were well over the thresholds, so I keyed that crate.  After this, the watchdogs tripped as expected when we enabled damping but the RMS was higher than the threshold.

I eventually remotely rebooted c1sus again.  This totally fixed everything.  We put all of the local damping gains back to the values that we found them (in particular, undoing our sign flips), and everything seems good again.  I don't know what happened, but we're back online now. 

Q notes that the bounce mode for at least ITMX (haven't checked the others) is rung up.  We should check if it is starting to go down in a few hours.

Also, the FSS slow servo was not running, we restarted it on op340m.

  695   Fri Jul 18 17:06:20 2008 JenneUpdateComputersComputers down for most of the day, but back up now
[Sharon, Alex, Rob, Alberto, Jenne]

Sharon and I have been having trouble with the C1ASS computer the past couple of days. She has been corresponding with Alex, who has been rebooting the computers for us. At some point this afternoon, as a result of this work, or other stuff (I'm not totally sure which) about half of the computers' status lights on the MEDM screen were red. Alberto and Sharon spoke to Alex, who then fixed all of them except C1ASC. Alberto and I couldn't telnet into C1ASC to follow the restart procedures on the Wiki, so Rob helped us hook up a monitor and keyboard to the computer and restart it the old fashioned way.

It seems like C1ASC has some confusion as to what its IP address is, or some other computer is now using C1ASC's IP address.

As of now, all the computers are back up.
ELOG V3.1.3-