I spent some time trying to figure out how to get a record of the pointing of the input pointing tip-tilt (TT) channels.
Currently the TT pointing is done via the offset in the PIT/YAW filter banks, ie. C1:IOO-TT1_PIT_OFFSET, which is an EPICS record. I added these channels to the C0EDCU.ini, which (I'm pretty sure) specifies which EPICS channels are recorded to frames.
controls@pianosa:~ 0$ grep C1:IOO-TT /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
I then confirmed that the data is being recorded:
controls@pianosa:~ 0$ FrChannels /frames/full/10466/C-R-1046657424-16.gwf | grep TT
The EPICS records for these channels *should* be recorded by autoburt, but Yuta noticed they were not:
controls@pianosa:~ 0$ grep -R C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2013/Mar/6/
The autoburt log seems to indicate some sort of connection problem:
controls@pianosa:! 130$ grep C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1assepics.log
pv >C1:IOO-TT1_PIT_OFFSET< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HIGH< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LOW< nreq=-1
C1:IOO-TT1_PIT_OFFSET ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HIGH ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LOW ... not connected so no ca_array_get_callback()
This is in contrast to successfully recorded channels:
controls@pianosa:~ 0$ grep C1:LSC-DARM_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1lscepics.log
pv >C1:LSC-DARM_OFFSET< nreq=-1
pv >C1:LSC-DARM_OFFSET.HSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.LSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.HIGH< nreq=-1
pv >C1:LSC-DARM_OFFSET.LOW< nreq=-1
C1:LSC-DARM_OFFSET ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_array_get_callback() nreq 1 ... OK
In fact all the records in the c1assepics log are showing the same "not connected so no ca_array_get_callback()" error. I don't know what the issue is. I have no problem reading the values from the command line, with e.g. ezcaread. So I'm perplexed.
If anyone has any idea why the c1ass EPICS records would fail to autoburt, let me know.
5) DTT wasn't working on rossa. Used the Date/Time GUI to reset the system time to match fb and then it stopped giving 'Test Timed Out'. Jamie check rossa ntpd.
ntp is now installed on all the workstations. I also added it to the /users/controls/workstation-setup.sh script
I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT. I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.
To do this:
log in as root
/usr/local/bin/ntpd -c /etc/inet/ntp.conf
I installed the following packages on rossa:
numpy, ipython, matplotlib, python-matplotlib
Adaptive filter outputs some non-zero signal in the OFF position
I turned "ON" one of them and c1lsc suspended, I've rebooted it and restarted models on c1lsc and c1sus.
Now it also outputs something non-zero though the first line of the adaptive code is "if(OFF) output=0.0; return;" May be another version of the code has been compiled.
Edit: Old version (~september) of the code and oaf model is running now. In the 2.1 code there was a link from src/epics/simLink to oaf code for each DOF. It seems that 2.5 version finds models and c codes in standard directories. I need to move working code to the proper directory.
Yes, things have changed. Please wait until I have things cleaned up before working on models. I'll explain what the new setup is.
Here are the issues that I found not quite accurate in the old oaf code:
1. There is no need to calculate the norm of the witness signal every time from zero:
norm += (*pBufAdapt) * (*pBufAdapt); // add to the norm
Every step the witness signal vector is the same except the first and last values
wit[i].norm += histAdpt[nCoeff]*histAdpt[nCoeff] - histAdpt*histAdpt;
This step will reduce the number of multiplications and summations from 3*M/k to 2*M/k, M - filter length, k - downsample ratio.
2. Old code filter corrects filter coefficients with a delay equal to k=downsample ratio (pretty big):
witness o o o o o o o o o o o o o o o o o o o o o
error o o o o o o o o o o o o o o o o o o o o o
We want the filter to work at green points and skip red points computing output and correcting coefficients at this time (downsample ratio in this example is 4). Old code
But LMS algorithm should correct coefficients according to the latest error. As we calculate output and correct coefficients before the latest error signal will be available, we should change the order:
This scheme is completely equivalent to the ordinary LMS algorithm, as now we correct coefficients according to the latest error signal and so do not add any delay.
3. So long soft start is probably not needed for the LMS filter, it makes the filter to converge longer
// modify adaptation gain for soft start
if( state.iWait < state.nFIR )
adaptGain = 0.0;
decayRate = 1.0; // clear FIR coeffs after reset
As far as I understand this is done to prevent the filter from huge coefficients variations in the beginning when norm is not calculated yet. Instead we can just introduce some small
epsilon = 10.0;
to prevent the filter from divergence in the beginning
delta = mu * error / (wit[i].norm + epsilon);
Though some soft start might be needed by not so long - it will take several minutes before the adaptation gain will take it's specified value.
Today I tried to make the lms filter to work online. I played around with the signals (GUR1_X and MC_F) to pre-whiten them and in the end the following configuration worked out:
1. mu = 0.03, tau = 1e-5, downsample=8, nCoeff = 4000, delay = 5 (sample-and-hold delay is not included in the new code, it should be added here!)
2. witness pass: AA32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
3. witness adaptation path: AA32 AND AI32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
4. error path: AA32 AND 0.1:0 AND anti_1Hz. Before I added anti_1Hz filter oaf did nothing. This filter tries to approximate the actuator transfer function. Note, it is not in the witness adaptation path. This is some sort of whitening.
5. correction path: AI32, gain = -1
Convergence time ~ 5 mins. The performance of the filter is far not perfect compared to the offline implementation. But it deals with a stack though.
(Johannes, Koji, Keerthana)
The PLL loop ensures that the frequency difference between the PSL laser and the AUX laser is equal to the frequency we provide to the Local Oscillator (LO) with the help of a Marconi. Only a small pick off part of both the AUX and PSL lasers are going to the PLL loop. The other part of both the lasers are going to the interferometer. Before entering into the optical fibre, the AUX laser passes through an AOM which changes its frequency by an amount of 80MHz. When the PLL is locked, the frequency coming out of the PLL will be equal to the frequency set up in the Marconi (fm). When it passes through AOM, the frequency becomes fdiff = fm ±80 MHz. If this frequency beam and the PSL laser beam is aligned properly, and if this frequency is equal to the product of an integer and the free spectral range of the cavity, this will resonate in the cavity. Then we expect to get a peak in the ETM transmission spectrum corresponding to the frequency we injected through the optical Fibre.
Through out the experiment we need to make sure that the PSL is locked. Thus, the signal detected by the photo detector when only PSL is resonating inside the cavity, act as a DC signal. Then we give a narrow scan to the Marconi. When fdiff = N*FSRy this condition is satisfied, we will observe a peak in the output. Here FSRy is the free spectral range of the cavity which is approximately equal to 3.893 MHz.
Yesterday afternoon, Johannes, Koji and myself tried to observe this peak. We aligned the cavity by observing the output signal from the AS100 photo detector. We made the alignment in such a way that the intensity output getting from this photo detector is maximum. We used a Spectrum analyser to see the output. After that we connected a photo detector to collect the YEND transmission signal from the ETM mirror. We used a lens to focus this directly to the photodetector. Then we connected this photodetector to the spectrum analyser, which was located near the AS table. We took a large cable to meet this purpose. But still the cable was not lengthy enough, so we joined it with another cable and finally connected it with the spectrum analyser. Then we gave a scan to the Marconi from 51 MHZ to 55 MHz. We repeated this experiment with a scan of 55 MHz to 59 MHz also. We repeated this a few times, but we were not able to see the peak.
We assume that this can be because of some issue with the alignment or it can be because of some issue with the photo detector we used. We would like to repeat this experiment and get the signal properly.
I am attaching a flow chart of the setup and also a picture of the mirrors and photo detector we inserted in the Y-End table.
I worked a bit on the PSL table today
It isn't clear to me in the drawing where the Agilent is during this measurement. Over 40m of cabling, the loss of signal can be a few dB, and considering we don't have a whole lot of signal in the first place, it may be better to send the stronger RF signal (i.e. Marconi pickoff) over the long cable rather than the weak beat signal from the Transmission photodiode.
[Jenne, Zach, Kiwamu]
We made some efforts to lock the X arm cavity with the infrared beam.
We eventually obtained the PDH signal from a photo diode at AS port, we are still in the mid way of the lock.
The PDH signal now is going into c1lsc's ADC.
We have to make sure which digital channel corresponds to our PDH signal,
(what we did)
- split the LO signal, which comes from a Marconi, just before the EOM into two path.
One is going to the EOM and the other is going to the AP table for the demodulation, The driving frequency we are using is 11MHz.
- put RF amplifiers to make the RF signal bigger. The raw signal was small, it was about ~-50 dBm in the spectrum analyzer.
So we connected two ZLN amplifiers. Now the RF signal is at about 0 dBm
- connected the LO and RF signals to a mixer. Additionally we put a 9.5-11.5 MHz bandpass filter at the LO path since there was some amounts of 29.5MHz due to the RF reflection at the EOM resonant box.
After a low pass filter by SR560 the signal shows typical PDH behaviors.
- strung a BNC cable which connects the demodulated signal and c1lsc.
In order to connect the signal to the current working ADC, we disconnected AS166_I from a whitening board and plug our cable on it.
- tried checking the digital signal but we somehow couldn't configure DAQ setting, So actually we couldn't make sure which channel corresponds to our signal.
We turned off many excessive violin mode bandstop filters in the LSC.
Due to some feedforward work by Jenne or EQ some years ago, we have had ~10 violin notches on in the LSC between the output matrix and the outputs to the SUS.
They were eating phase, computation time, and making ~3 dB gain peaking in places where we can't afford it. I have turned them off and Gautam SDF safed it.
Offensive BS shown in brown and cooler BS shown in blue.
To rotate the DTT landscape plot to not be sideways, use this command (note that the string is 1east, not least):
pdftk in.pdf cat 1east output out.pdf
The clue was that the loop X arm POX loop looked to have low (<3dB)) gain margin around 600 Hz (and again at 700 Hz). Attachment #1 shows a comparison of the OLTF for this loop (measured using the IN1/IN2 method) before and after our change. We hypothesize that one of the violin filters that were turned off had non-unity DC gain, because I had to lower the loop gain by 20% after these turn-offs to have the same UGF. I updated the snap files called by the arm locking scripts.
I think I caught all the places where the FM settings are saved, but some locking scripts may still try and turn on some of these filters, so let's keep an eye on it.
Friday, we were seeing a 2 Hz harmonic series in all of the PEM channels. Today I found that some bad person had put in a 4V (!) signal into one of the channels with a signal generator. The generator was also sneakily stuck way back inside the DCU rack. NO SECRET SIGNAL INJECTIONS!
Since the ADC has a 2Vpk range, this was saturating and putting in harmonics in all the adjacent channels. I disconnected it and turned off the function generator.
I changed the office area thermostate near Steve's desk from 68F to 73F today. Please do not change it.
If anyone from facilities comes to adjust something, please put the details in the elog on the same day so that we can know to undo that change rather than chase down other drifts in the system.
Not sure what's wrong, but the workstation desk is freezing cold again and the room temp is 18degC (64degF).
I've compared offline Wiener filtering with online static + adaptive filtering for MC_F with GUR1_XYZ and GUR2_XYZ as witness signals
Note: online filter works up to 32 Hz (AI filter at 32 Hz is used). There is no subtraction up from this frequency, just MC_F was measured in different times for online and offline filtering. This difference in MC_F in frequency range 20-100 Hz showed up again as before with microphone testing. One can see it in 1 minute. Smth is noisy.
1. FIR -> IIR conversion produces error. Now I'm using VECTFIT approximation with 16 poles (splitting into 2 filter banks), this not enough. I tried to use 50 and split them into 5 filter banks, but this scheme is not working: zpk -> sos conversion produces error and the result filter works completely wrong.
2. Actuator TF. VECTFIT works very good here - we have only 1 resonance. However, it should be measured precisely.
3. Account for AA and AI filters that rotate the phase at 1-10 Hz by ~ 10 degrees.
[Offsets in MC]
I have introduce an offset in MC2 PIT because the PZT1 again started railing.
Right now the PZT1 EPICS value is within the range happily.
Please keep this MC eigen axis as a nominal configuration.
I have modified the IFO configure scripts such that XARM and YARM are locked with POX11 and POY11 respectively.
A big advantage in use of POX and POY is that we don't need to misalign ITMs when we align each arm.
Those scripts are now available from the C1IFO_CONFIGURE screen as usual.
At 1Y2 rack, I measured offset voltage of the common mode servo (D040180-B) with the gain of it varied.
For now, all signal cables that come into or go out of the common mode servo are not plugged.
I will upload the data I took and report the result later.
I report the results of the measurement to know how offset voltage of common mode servo changes when the gain is changed.
- Motivation: If discontinuous change of the offset happens when we change the gain, it could cause saturation somewhere and so make the length control down. So, we want to estimate effect of such discontinuous change.
- Method: In 1 (or In 2) was terminated with 50 ohm, and the output voltage at Out 2 was measured with a multimeter (D040180-B).
- Results are shown below. Acquired data are attached in .zip.
The upper shows input equiv. offset. The lower shows offset measured at Out 2.
As for both In1 and In2, strange behaviors can be seen between -17 dB and -16 dB.
This is because 5 amplifiers (or attenuators) are simultaneously enabled/disabled here. Similar situation occurs every change of 8 dB gain.
We noticed that PRMI RIN is high when the cavity is locked on RELF33 I&Q signals. We compared the level of power fluctuations when PRMI was locked using REFL11, REFL55 and REFL 33. Attached plot "prmi_rin" shows the spectra.
Then we excited PRM and measured length to RIN coupling when PRMI was locked on REFL33 I&Q. DC offset of PRCL is only 3%. But MICH offset seems to be ~nm. When we gave offset of -15 cnts to the servo, power fluctuations improved by a factor of few.
Then we looked at DRMI. It seems that SRC macroscopic length is off but we still could lock it stably. To account for macroscopic length detuning we had to rotate REFL55 phase from 25 degrees to 50 degrees. Power at AS port increased by factor of ~2 compared to PRMI configuration. SPOP18 is decreased only by 30%. Attached plot "drmi_power" shows POP18, POP90, POPDC and ASDC in PRMI and DRMI configurations.
Plot "src_ol" shows srcl OL transfer function. UGF is 70 Hz. We have also centered SRM OL and copied the servo filters from PRM, gains are set to keep UGF at ~0.1 Hz and 7 Hz
This is a more detailed procedure:
1. Phase: REFL11: 19 degree, REFL55: 50 degrees (25 degrees for PRMI configuration)
2. Input matrix:
3. Servo parameters:
PRCL: gain = -0.02, FM4,5 + trigger FM2,3,6,9
MICH: gain = 0.8, FM4,5 + trigger FM2
SRCL: gain = 0.25, FM4,5 + trigger FM2,3
signal is SPOP22 , levels 40:25
I added lubricating oil to roughing pumps RP1 and RP3 yesterday and this morning. Also, I found a nearly full 5 gallon jug of grade 19 oil in the lab. This should set us up for quite a while. If you need to add oil the the roughing pumps, use the oil in the quart bottle in the flammables cabinet. It is labeled as Leybold HE-175 Vacuum Pump Oil. This bottle is small enough to fill the pumps in close quarters.
KroneCrane Fred inspected and certified the 3 40m cranes for 2014. The vertex crane crane was load tested at fully extended position.
Small oil drops were found during prevent inspection of the vertex crane. They were wiped off. It took 231 days to grow this size.
16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.
The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.
One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.
Rod Luna picked up these computers for Larry Wallace yesterday: Dell Inspiron 530, Dell Dimension 4600 and SunBlade 1000
I've restarted the old daqd on fb until I can figure out what's going on with the symmetricom driver on fb1.
Steve: Jamie with hair.... long time ago
Gautam and Steve,
The "called 225 lbs" steel crane load measured right on 102 kg
The trick to the measurment to maintain 1 mm gap to the central cilynder of the load cell.
The lead plate stabilized the large load.
gautam: some additional notes:
I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.
I'm out, HEPAs are back at 20%.
For a last few days I've been working on oaf and simulink model to simulate it. First I did online subtraction from MC when MC_L path was enabled. Inside my code I've added a sum of squares of filter coefficients so we can monitor convergence of the filter.
To to this I've measured path from OAF output to input without AA and AI filters. Then made a vectfit using 2 poles and zeros. Foton command
zpk( [-2.491928e+03;5.650511e-02], [-4.979872e+01;-3.278776e+00], 6.011323e+00)
My simulink model consists of 3 parts:
Adaptive filter in the model uses online c-code. It is connected to simulink block through an S-function. Sampling frequency of the model is 10 kHz. It works fairly fast - 1 sec of simulation time is computed in 1 sec.
I've tested FxLMS algorithm and MFxLMS algorithm that is faster. I plan to test 2 iir adaptive algorithms that are already coded.
Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect.
Excitation generator created these harmonics. When I applied low-pass butterworth filter, I've got the result of online filtering close to simulations. On the second graph blue is biquad filter output spectrum, red corresponds to DF2. 1 Hz sin wave was filtered with a notch filter of Q=100, depth=300 at 1 Hz.
I tried to filter MC_F from seismic noise measured by GUR1 seismometer. I've used 8000 tap filter, downsample ratio=8, delay=1. In the Figure the output of the filter is presented with MC_F signal.
We can see that output is close to the MC_F, but the phase for some reason is not zero. It should not be at 1 Hz - 10 Hz due to the actuator. But below these frequencies I do not see any reasons for the output phase to differ from MC_F phase. But it is possible, the phase of the actuator is evaluated very rough and the adaptive filter can't match it.
The 2W PSL laser is turned off. The danger laser lights are not illuminated at the entry doors because of malfunctioning electronic circuit!!!
Laser safety glasses are still required! Other lasers are in operation!
I had forgotten to fix the DNS setup on op340m and so our slow, perl, PID loops for the laser were not running well (and that's why the FSS-FAST has been saturating).
I edited /etc/resolv.conf on there and then did /usr/sbin/reboot as super-user.
Fri Jun 20 19:06:37 PDT 2014
The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.
As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.
We had fiddled with the scripts/general/scripto_cron script to try and get the MC auto locker working on ottavia, but in doing so broke op340m's reliance on it to run it's cron jobs, like FSSSlowServo.
I've reverted scripto_cron to its original state, and the FSS slow servo starts up again.
However, scripts like this that we want to always have on seem to be a better fit, to me, for the init system, like we do with daqd and nds on the FB. op340m's inittab looks different than what I'm used to, so I'm not making any changes; this is just a thought.
MC autolocker is still being ran from an Ottavia GUI terminal; I'll try to get it consistently running on megatron, as suggested in ELOG10039, now that caget/caput issues seem to be sorted.
Addendum: I've changed the MC auto locker script to have megatron as its host. Haven't yet gotten it to run automatically; it's running in a detached tmux terminal. I'll finish it up tomorrow.
I modified the perl script which does our hourly autoburt so that it can run on megatron instead of op340m (old Solaris machine). Nothing major, just some path stuff. That was the last function of op340m that I know of, so after a week of watching this we ought to be able to power it off and send it to e-waste.
Seems to work so far. It complains about some models that aren't running but mostly it reports successful snapshot taking based on the .req files.
Unfortunately, it seems that its only doing the new target directory, so its missing all of our old VME machines which still use the /cvs/cds/caltech/target area.
But I think Gautam and Jamie and Aidan have volunteered to start our slow controls upgrade by moving the EX slow controls to Acromag and into the new target area. We ought to modify the CRON to point at the old directory for now, but its a temporary fix hopefully.
I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html
Now we can see the StripTool displays that are usually parked on that screen.
I think op540m has finally bitten the dust. I noticed that both of its screens were black, so I assumed that it had crashed due to known graphics card issues or something. But upon closer inspection, it is way more dead than that. I checked that it does have power (at least the power cable is securely plugged in at both ends, and the power strip its on is successfully powering several other computers), but I can't make any lights or anything come on by pressing the power button on the front of the computer tower.
Immediate consequences of op540 not being operational are the lack of DMT, and the lack of Alarms.
Joe is doing an autopsy right now to see if its really dead, or only 'mostly dead'.
EDIT: Joe says maybe it's the power supply for the computer. But he can't turn it on either.
This is a reminder (mainly for Steve, who somehow doesn't believe these things) that op540m is not to be used for your general pleasure.
No web, no dataviewer, no DTT. Using these things often makes the graphical X-Windows crash. I have had to restart the StripTool, our seismic BLRMS and our Alarms many times because someone uses op540m, makes it crash, and then does not restart the processes.
Stop breaking op540m, Steve!
I turned the StripTool and ALARMS and BLRMS back on on op540m. Looks like it has been rebooted 5 days ago and no one turned these back on. Also, there was a bunch of junk strewn around its keyboard which I restrained myself from throwing in the trash.
The BLRMS trends should be active now.
The squeezing open frame rack was moved from the south side of the PSL enclosure to the north side of the SP table.
AC power breaker is PC-2 #1
I built a Simulink model of the magnetic levitation system and try to explain the dip in the open-loop transfer function that was observed.
One can download the model in the svn. The corresponding block diagram is shown by the figure below.
Here "Magnet" is equal to inverse of the magnet mass. Integrator "1/s" gives the velocity of the magnet. A further integrator gives the displacement of the magnet.
Different from the free-mass response, the response of the magnet is modified due to the existence of the Eddy-current damping and negative spring in the vertical
direction, as indicated by the feedback loops after two integrals respectively. The motion of the magnet will change the magnetic field strength which in turn will pick
up by the Hall-effect sensor. Unlike the usual case, here the Hall sensor also picks up the magnetic field created by the coil as indicated by the loop below the mechanical
part. This is actually the origin of the dip in the open-loop transfer function. In the figure below, we show the open-loop transfer function and its phase contributed by both
the mechanical motion of the magnet and the Hall sensor with the black curve "Total". The contribution from the mechanical motion alone is shown by the magenta curve
"Mech" which is obtained by disconnecting the Hall sensor loop (I rescale the total gain to fit the measurement data due to uncertainties in those gains indicated in the figure).
The contribution from the Hall sensor alone is indicated by the blue curve "Hall" which is obtained by disconnecting the mechanical motion loop. Those two contributions
have the different sign as shown by the phase plot, and they destructively interfere with each other and create the dip in the open-loop transfer function.
In the following figure, we show the close-loop response function of the mechanical motion of the magnet.
As we can see, even though the entire close loop of the circuit is stable, the mechanical motion is unstable around 10 Hz. This simply comes from the fact that
around this frequency, the Hall sensor almost has no response to the mechanical motion due to destructive interference as mentioned.
In the future, we will replace the Hall sensor with an optical one to get rid of this undesired destructive interference.
We've had a devil of a time getting V1 to open, due to the Interlock code.
The short story is that if C1:Vac-PTP1_pressure > 1.0, the interlock code won't let you push the button to open V1 (but it won't close V1).
PTP1 is broken, so the interlock was frustrating us. It's been broken for a while, but this hasn't bitten us till now.
We tried swapping out the controller for PTP1 with one of Bob's from the Bake lab, but it didn't work.
It said "NO COMM" in the C1:Vac-PTP1_status, so I figured it wouldn't update if we just used tdswrite to change C1:Vac-PTP1_pressure to 0.0. This actually worked, and V1 is now open. This is a temporary fix.
The swapped in 307 convectron gauge controller is very likely to have the RS232 connection wired differently from the old one.
PRP gauge has now the same error message as the PTP1: "no comm" I would look at RS232 wiring of the PRP gauge on the broken
controller and adapt the swapped in one to communicate. The PRP was reading 620 Torr before the swap.
Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians. A consequence of this is that all of the XY-plots on the medm screens were too small.
I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1.
I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians.
While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.