I am Aakash Patil. I will be working at the 40m lab as a SURF student with Gautam Venugopalan on enclosures for seismometers to shield them from thermal and magnetic fluctuations. This week I will be working on the development of hardware for four probe measurement along with a constant current source. It will effectively help us in accurate temperature measurement throughout the development of enclosure.
Hello, I am Varun Kelkar. I will be working at the 40m lab as a SURF student this summer with Eric Quintero on Audio processing for real time control system signals. This week I will mostly be working on implementing basic DSP C-code offline. Currently I am trying to write a code for noise whitening.
Varun has received 40m specific basic safety training today.
Aakash Patil received 40m specific basic safety training.
Praful Vasiceddy received 40m specific basic safety training.
Here's what I accomplished since my last elog:
I continued working on the beatbox calibration. Instead of using the function generator for an input signal,
I used the network analyzer because it can generate higher frequencies that are of more interest to us. I ran
the network analyzer output into the RF in port, and took voltage measurements from the Q port using the
oscilloscope. The frequency range I focused on was 100 - 200 MHz, and I also took more closely spaced measurements
from 180 - 200 MHz. The data is recorded on the computer now, and I will analyze it more fully in the future.
I also edited the Calibration page on the LIGO 40 m wiki. Rana showed me the page on calibration, but there was
limited information there, so he recommended that I post my work there as well. Right now I haven't posted much,
but I will likely add some information on the Simulink model I'm working on and results of measurements to be
taken as the project progresses.
The majority of my work has been on developing a Simulink model in Matlab of the differential arm length sensing
and control loop. I am using Figure 6-1 from Rana's thesis as a guide on important components to include in the
model. Some of the details on the transfer functions of components need to be worked out, but a basic framework has
been established. Right now the transfer function of the arm cavity is being approximated as a single pole, but
we may integrate the calibration model I'm working on with Sasha's work on the arm cavity. I have also begun to
implement the length response function in the model. I believe it is giving correct results at frequencies up to
100 Hz, but is off at higher frequencies. This might be fixed after I continue to fill in the transfer functions
of the digital components; they are currently set to 1 until I find more information on them.
Most of my work has been on continuing to develop the Simulink model of the differential arm length control loop.
I have filled in transfer functions for the digital components after looking up the configuration of filters and
gains on the control screens. Filters that were active at the time included 1:50 and 1000:10 on C1LSC_YARM and
C1LSC_POY11 with a gain of 0.1. Jamie also introduced me to foton so that I could obtain the transfer functions
for the necessary filters. I have also continued to work on obtaining the open loop gain and length response
function from the model. The majority of the work now is to refine what I've accomplished so far. Adding details
to the arm cavity and the optics is one potential area for improvement.
I have also spent some time looking at real-time calibration methods from GEO and a proposal for a similar system
on LIGO in P040057-x0 from the DCC. While the work for this project may follow a different path for a real-time
calibration, having a sense for what's been accomplished so far should be helpful in working on a new system.
I am continuing work on simulating the DARM control loop. There is now a block for the length response
function that allows one to recover the h(t) GW input to the model. However, in order to add this
block I had to add some artificial poles to the length response function beacuse Simulink gave me errors
when the transfer function had more zeros than poles. The artificial poles are at 10^6 Hz and higher, so
that they should not affect the response function at the lower frequencies of interest. This approach
appears a bit computationally unstable though because without changing any parameters and re-running
the simulation, a different magnitude for h(t) would be calculated sometimes. A different method may be
necessary to get this working more accurately.
By looking through the C1LSC Simulink model and the C1LSC control screens, Jenne helped me determine
which digital filters are active while the interferometer is locked. To do this, open the C1LSC control
screen, then open the trigger matrix. Inside the trigger matrix window there is a button titled Filter
Module Triggers which opens another window that indicates which filters are triggered for a given channel,
and what values trigger them. For the y arm servo filters FM2, 3, 6, 7, 8 are triggered while in lock and
FM4 and 5 are controlled manually; I am including all of these in the model now.
I have changed the way I manipulate the output from the model for analysis, using Rana's advice. I also
improved the plotting code, now using a custom Bode plot instead.
Attached is a screenshot of the Simulink model as it currently stands, and an older implementation of the
open loop gain. I am in the process of updating the servo filters now, and what is shown in the plot does
not include all the filter modules for the servo filter.
Since my last update I have modified the DARM control loop model to the extent that it resembles the
measured open loop transfer function much more closely. The phase especially is much more accurate, with
a phase margin of about 35 degrees at the unity gain frequency of 156 Hz. Right now I'm normalizing to
the unity gain frequency still to adjust the gain properly. Using the length response function from the
model, I can calibrate the error signal as well to find the simulated h(t) output. There were a number of
computational problems in calculating the length response function, but I eventually found a work-around.
Attached is an updated plot of the open loop transfer function and the length response function of the model.
This week Jamie showed me around the real-time Simulink models as well. The one specific to my project
is c1cal.mdl. It takes the output in the form of the error and control signals from c1lsc.mdl as its
input and produces the calibrated signal as output. In order to produce the calibrated signal we need the actuation
function and the inverse of the sensing function for the model as it stands now. We also built, installed,
and restarted the c1cal model because no data was showing up in data viewer, but the problem remained
after this attempt.
Jamie and I also started on calibrating the interferometer in the traditional way. Jamie aligned the beam
splitter and the input test masses so we could take free-swinging Michelson measurements. However, taking
the data with the nds system appears to be giving different results than what is showing up in data viewer.
The goal of this measurement is to get a value for the peak to peak amplitude of the Michelson error signal.
This week I spent most of my time learning about how the interferometer is calibrated and working on the calibration itself. I also looked more into the Pound-Drever-Hall technique.
Continuing work on the free-swinging Michelson measurements, I changed the signal that I was using to C1:LSC-ASDC_OUT_DQ. This is a proper power signal so that the peak-to-peak amplitude of this error signal can be directly read off the graph. The motivation to measure this amplitude is that it must be known in order to calibrate the actuation of the input and end test masses.
Next I looked into using DTT to make some measurements. I ran the Michelson restore script in the IFO Configure screen to adjust the optics to be near alignment. Then I tweaked the precise settings in the IFO Align screen of pitch and yaw for the ITMX, ITMY, and BS. The goal with this was to minimize the magnitude of the C1:LSC-ASDC_OUT_DQ signal. After it was well-aligned, back in DTT I sent in a sine wave excitation and used a Triggered Time Response measurement to see the output. As a first test I put the excitation signal in the ASDC channel and I was able to plot the resulting OUT signal in DTT. The amplitude was different than I input due to gains between the excitation and the point of measurement, but this can easily be accounted for by adjusting the amplitude in DTT accordingly.
The next step is to work on measurements of a single arm cavity, introducing excitations there and measuring the response.
This week I took more data for the calibration of YARM. The summary of measurements taken is:
1. Peak-to-peak on Michelson
2. Michelson open loop
3. Excite ITMY and measure on AS55_Q_ERR
4. Excite ITMY and measure on POY11_I_ERR
5. Excite ETMY and measure on POY11_I_ERR
6. YARM open loop
Then I worked on comparing these measurements to the Simulink model of the interferometer control loop. The measured open loop transfer function of the YARM matched well with the model above about 20 Hz, after the gain was scaled properly to fit the data. Next is to fit the length response function of the model and the measurements, and then use DTT to calibrate the arm cavity's power spectrum.
I started work familiarizing myself with the ELOG and some of the control systems at the 40m. I spent a fair bit of time gaining some general knowledge of the interferometer, control systems, calibration, null instruments, etc. On Friday, June 22 Yaakov and I spent the afternoon pulling cables for the beatbox that Jamie had finished up. We were able to get the cables from the rack containing the beatbox routed to the control room.
Then I started work on calibrating the beatbox. I set up the function generator to send a sine wave into the beatbox, then sent the signal from the beatbox to the oscilloscope. I compared both the input sine wave and the output from the beatbox at many frequencies, taking peak to peak measurements. I'm working on using the data to calibrate the beatbox now.
This week, I've been reading some literature concerning PLL and familiarizing myself with LINUX, MATLAB, and high-pass filter circuits. In MATLAB, I started constructing matrices to be used for a beam path analysis from the laser output to the ccd camera. I also built a simple high-pass filter on a bread-board that Joe and I are currently testing with the spectrum analyzer.
40m SURFs Razib Obaid, Nancy Aggarwal, Unknown Bearded SMURF, Megan Daily, Gopal Nataraj, Katharine Larson and Sharmila Dhevi received 40m specific safety training on June 23, 2010.
Masha, Eric, Yaakov, Liz and Sasha received 40m specific basic safety training.
I have updated the sus_single_control model, adjusting/cleaning up/simplifying the LSC/POS input signals, and routing new signals to the lockins. Notably one of POS inputs to the part ("lockin_in") was eliminated (see below).
The 6 inputs to the TO_COIL output matrix are now:
LSCPOS + OFFSET + ALT_POS_IN
ASCPIT + OFFSET + SUSPIT + OLPIT
ASCYAW +OFFSET + SUSYAW + OLYAW
The ALT_POS input is used only by the ETMs for the green locking. Just outside of the sus_single_control library part in the ETM models are the green locking controls, consisting of the ETM?_ALS filter bank and the ETM?_GLOCKIN lockin, the outputs from which are summed and fed into the aforementioned ALT_POS input.
As for the SUS lockins (LOCKIN1 and LOCKIN2 in the library model), their input matrix now gets the direct inputs from the OSEMS (before filtering) and the outputs to the coils, after all filtering. These will aid in doing binary output switching tests.
All suspension models (c1sus, c1scx, c1scy) have been rebuild and restarted so that they reflect these changes.
It was in vain to restart mx_stream yesterday as C1SUS did not see FB
controls@c1sus ~ 0$ /opt/open-mx/bin/omx_info
Open-MX version 1.3.901
build: root@fb:/root/open-mx-1.3.901 Wed Feb 23 11:13:17 PST 2011
Found 1 boards (32 max) supporting 32 endpoints each:
c1sus:0 (board #0 name eth1 addr 00:25:90:06:59:f3)
managed by driver 'igb'
Peer table is ready, mapper is 00:60:dd:46:ea:ec
0) 00:25:90:06:59:f3 c1sus:0
1) 00:60:dd:46:ea:ec fb:0 // this line was missing
2) 00:14:4f:40:64:25 c1ioo:0
3) 00:30:48:be:11:5d c1iscex:0
4) 00:30:48:bf:69:4f c1lsc:0
5) 00:30:48:d6:11:17 c1iscey:0
controls@fb ~ 0$ /opt/mx/bin/mx_info
MX Version: 1.2.12
MX Build: root@fb:/root/mx-1.2.12 Mon Nov 1 13:34:38 PDT 2010
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
Instance #0: 299.8 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
Status: Running, P0: Link Up
Network: Ethernet 10G
MAC Address: 00:60:dd:46:ea:ec
Product code: 10G-PCIE-8AL-S
Part number: 09-03916
Serial number: 352143
Mapper: 00:60:dd:46:ea:ec, version = 0x00000000, configured
Mapped hosts: 6
INDEX MAC ADDRESS HOST NAME P0
----- ----------- --------- ---
0) 00:60:dd:46:ea:ec fb:0 1,0
1) 00:30:48:d6:11:17 c1iscey:0 1,0
2) 00:30:48:be:11:5d c1iscex:0 1,0
3) 00:30:48:bf:69:4f c1lsc:0 1,0
4) 00:25:90:06:59:f3 c1sus:0 1,0
5) 00:14:4f:40:64:25 c1ioo:0 1,0
controls@fb ~ 0$ sudo /sbin/init q
controls@fb ~ 0$ sudo /etc/init.d/mx restart
ETMX YAW stopped drifting Jan 8, 2015
I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen.
The SUS Drift Monitor screen has been updated:
The MEDM screen has been updated: the new buttons, one for each optic, call the scripts/general/SUS_DRIFTMON_update_reference.py script, which measures (and averages) for 30s the current values of the POS/PIT/YAW drifts, and then sets the average as the new reference value.
- setsval.m uses mDV to get the minute trend from some specified start time
and duration in the past. It then writes that 'good' value to the
.SVAL field of the SUSPOS, SUSPIT, and SUSYAW records for all the
- setHILO.m reads the .SVAL field and then sets the alarm levels and severity
for the same records given a "sigma" as an argument. i.e. 1 sigma = HIGH,
2 sigma = HIHI.
function varargout = setsvals(varargin)
% sets the SVAL records for the SUS
debug = 0;
if nargin < 2
error('Needs 2 arguments.')
elseif nargin > 2
% Ex. setHILO(1000);
% this sets the SUS alarm levels to be 1000 counts
% from the nominal
% 1 for debugging
debug_flag = 0;
if nargin == 1
I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen.
I spent this morning populating the SUS IO Chassis and getting it ready for installation into the 1Y4 rack. I discovered I'm lacking the internal cables to connect the ADC/DAC boards to the AdL adapter boards that also go in the chassis (D0902006 and D0902496). I'm not sure where Alex got the cables he used for the end IO chassis he had put in. I'll be going to Downs after the meeting today either to get cables or parts for cables, and get the SUS chassis wired up fully.
I'd also like to confirm with Alex that the OSS-MAX-EXP-ELB-C board that goes in the IO chassis matches the host interface board that goes in the computer (OSS-HIB2-PE1x4-1x4 Re-driver HIB, since we spent half a day the last time we installed an IO chassis determining that one of the pair was bad or didn't match.
The SUS chassis has been populated in the following way:
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 2 DAC PMC66-16AO16-16-F0-OF
Slot 3-6 BO Contec DIO-1616L-PE Isolated Digital IO board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 8-9 DAC PMC66-16AO16-16-F0-OF
Slot 1 ADC adapter D0902006
Slot 2 DAC adapter D0902496-v1
Slot 7 ADC adapter D0902006
Slot 8-9 DAC adapter D0902496-v1
I've often gotten confused by the labeling on the SUS MEDM screens about the coil "Vmon" fields - they're labelled as "30 Hz HPF", and indeed this is one of the many readbacks available on the coil driver board. But the actual EPICS channel that is being displayed in this field is from the "EPICS VMON" monitor point on the coil driver board. It has a gain of 1/2, so the actual voltage going to the coil is twice the channel value. Today, I fixed the SUS master screen to avoid this confusion - new labeling is shown in Attachment #1.
I started poking around at what we want for new SUS MEDM screens. Rana and I decided we'd start with the ASC TIPTILT screens:
It's missing some things (like SIDE OSEMS) but it should provide a good starting point.
I copied the entire <userapps>/asc/common/medm/asctt directory to a new directory in our sus area:
controls@rossa:/opt/rtcds/userapps/release 0$ cp -a asc/common/medm/asctt sus/c1/medm/new
I then removed all the useless file name prefixes. We still need to go through and sed out all the ASC stuff in the MEDM files themselves.
It makes heavy use of macro substitution, which is good (it's what we're using now). So once we clean up all the channel names, we should just be able to swap out the pointers in our overview screens to the new screens (or rename things). In the mean time, during development, you can run:
controls@rossa:/opt/rtcds/userapps/release 0$ medm -x -macro "IFO=C1,ifo=c1,OPTIC=ITMX" sus/c1/medm/new/OVERVIEW.adl
As a part of the preparation for the replacement of c1susaux with Acromag, I made inspection of the coil-osem transfer function measurements for the vertex SUSs.
The TFs showed typical f^-2 with the whitening on except for ITMY UL (Attachment 1). Gautam told me that this is a known issue for ~5 years.
We made a thorough inspection/replacement of the components and identified the mechanism of the problem.
It turned out that the inputs to MAX333s are as listed below.
The switching voltage for UL is obviously incorrect. We thought this comes from the broken BIO board and thus swapped the corresponding board. But the issue remained. There are 4 BIO boards in total on c1sus, so maybe we have replaced a wrong board?
Initially, we thought that the BIO can't drive the pull-up resistor of 5KOhm from 15V to 0V (=3mA of current). So I have replaced the pull-up resistor to be 30KOhm. But this did not help. These 30Ks are left on the board.
[Ian, Tega, Raj]
This is the rough plan for the testing of the new suspension models with the created plant model. We will test the suspensions on the plant model before we implement them into the full
MEDM file location
For ITMX display, use:
hsss_tega_gautam>medm -x -macro "site=caltech,ifo=c1,IFO=C1,OPTIC=ITMX,SUSTYPE=IM,DCU_ID=21,FEC=45" SUS_CUST_HSSS_OVERVIEW.adl
For ITMX display, use:
hsss_tega_gautam>medm -x -macro "site=caltech,ifo=c1,IFO=C1,OPTIC=ITMX,SUSTYPE=IM,DCU_ID=21,FEC=45" SUS_CUST_HSSS_OVERVIEW.adl
After talking with Rana we have an updated plan. We will be working on this plan step by step in this order.
We have moved c1sim computer from the test stand to the server rack in the office area. (see picture)
It is connected to the general campus network. Through the network switch at the top of the rack. This switch seeds the entire Martian network.
Test to show that I am not lying:
c1sim is now as connected to the 40m network as my mom's 10-year-old laptop.
unfortunately, I have not been able to get the x2go client to connect to it. I will have to investigate further. It is nice to have access to the GUI of c1sim occasionally.
Now that the computer is in its new rack I have copied over the filter two files that I will use in the plant and the controller from pianosa:/opt/rtcds/caltech/c1/chans to the docker system in c1sim:/home/controls/docker-cymac/chans. That is to say, C1SUP.txt -> X1SUP.txt and C1SUS.txt -> X1SUS_CP.txt, where we have updated the names of the plant and controller inside the txt files to match our testing system, e.g. ITMX -> OPT_PLANT in plant model and ITMX -> OPT_CTRL in the controller and the remaining optics (BS, ITMY, PRM, SRM) are stripped out of C1SUS.txt in order to make X1SUS_CP.txt.
Once the filter files were copied over need to add them to the filters that are in my models to do this I run the commands:
$ cd docker-cymac
$ eval $(./env_cymac)
# cd /opt/rtcds/tst/x1/medm/x1sus_cp
# medm -x X1SUS_OPT_PLANT_TM_RESP.adl
see this post for more detail
Unfortunately, the graphics forwarding from the docker is not working and is giving the errors:
canAccess('X1SUS_OPT_PLANT_TM_RESP.adl', 4) = 0
can directly access 'X1SUS_OPT_PLANT_TM_RESP.adl'
locateResource(X1SUS_OPT_PLANT_TM_RESP.adl...) returning 1
Error: Can't open display:
This means that the easiest way to add the filters to the model is through the GUI that can be opened through X2go client. It is probably easiest to get that working. graphics forwarding from inside the docker is most likely very hard.
unfortunately again x2go client won't connect even with updated IP and routing. It gives me the error: unable to execute: startkde. Going into the files on c1sim:/usr/bin and trying to start startkde by myself also did not work, telling me that there was no such thing even though it was right in front of me.
unable to execute: startkde.
We are working on three fronts for the suspension plant model:
Here are the State-space matrices:
A few notes: If you want the values for these parameters see the .yml file or the State-space model file. I also haven't been able to find what exactly this s is in the matrices.
UPDATE [11/16/21 4:26pm]: I updated the matrices to make them more general and eliminate the "s" that I couldn't identify.
The input vector will take the form:
where x is the position, theta is the pitch, phi is the yaw, and y is the y-direction displacement
Updated A, B, C, D matrices for the state-space model to remove bugs in the previous estimate of the system dynamics. Updated the last post to represent the current matrixes.
We used MatLab to get the correct time-series filter coefficients in ZPK format and added them to the filters running in the TM_RESP filter matrix.
Get the pos-pos transfer function from the CDS model. Strangely, this seems to take a lot longer than anticipated to generate the transfer function, even though we are mainly probing the low-frequency behavior of the system.
For example, a test that should be taking approximately 6 minutes is taking well over an hour to complete. This swept sine (results below) was on the low settings to get a fast answer and it looks bad. This is a VERY basic system it shouldn't be taking this long to complete a Swept sine TF.
Noticed that we need to run eval $(./env_cymac) every time we open a new terminal otherwise CDS doesn't work as expected. Since this has been the source of quite a few errors already, we have decided to put it in the startup .bashrc script.
[Ian, Raj, Tega]
Here is the comparison between the results of Raj's python model and the transfer function measurement done on the plant model by Tega and me.
As You can see in the graphs there are a few small spots of disagreement but it doesn't look too serious. Next we will measure the signals flowing through the entire plant and controller.
For a nicer (and printable) version of these plots look in the zipped folder under Plots/Plant_TF_Individuals.pdf
1. Investigate cross-coupling btw the various degrees of freedom (dof) - turn on noise for each dof in the plant model and measure the transfer function of the other dofs.
2. Get a closed-loop transfer function using noise injection and give a detailed outline of the procedure in elog - IN1/IN2 for each TM_RESP filter while the others are turned off.
3. Derive analytic model of the closed-loop transfer functions for comparison.
4. Adapt control filters to fit optimized analytical solutions.
Connected the New SUS screens to the controller for the simplant model. Because of hard-coded links in the medm screen links, it was necessary to create the following path in the c1sim computer, where the new medm screen files are located:
We noticed a few problems:
1. Some of the medm files still had C1 hard coded, so we need to replace them with $IFO instead, in order for the custom damping filter screen to be useful.
2. The "Load coefficient" button was initially blank on the new sus screen, but we were able to figure out that the problem came from setting the top-level DCU_ID to 63.
medm -x -macro "IFO=X1,OPTIC=OPT_CTRL,DCU_ID=63" SUS_SINGLE_OVERVIEW.adl
Get the data showing the controller damping the pendulum. This will involve tweaking some gains and such to fine-tune the settings in the controller medm screen. Then we will be able to post some data of the working controller.
We should have a single place with all the instructions that are currently spread over multiple elogs so that we can better navigate the simplant computer.
[Ian, Paco, Tega]
Last night we set up the four main matrices that handle the conversion between the degrees of freedom bases and the sensor bases. We also wrote a bash script to automatically set up the system. The script sets the four change of bases matrices and activates the filters that control the plant. this script should fully set up the plant to its most basic form. The script also turns off all of the built-in noise generators.
After this, we tried damping the optic. The easiest part of the system to damp is the side or y motion of the optic because it is separate from the other degrees of freedom in both of the bases. We were able to damp that easily. in attachment 1 you can see that the last graph in the ndscope screen the side motion of the optic is damped. Today we decided to revisit the problem.
Anyways, looking at the problem with fresh eyes today, I noticed the in pit2pit coupling has the largest swing of all the plant filters and thought this might be the reason why the inputs (UL,UR,LR,LL) to the controller was hitting the rails for pit DoF. I reduce the gain of the pit2pit filter then slowly increased it back to one. I also reduced the gain in the OSEM input filter from 1 to 1/100. The attached image (Attachment2) is the output from this trial. This did not solve the problem. The output when all OSEM input filter gain set to one is shown in Attachment2.
We will try to continue to tweak the coefficients. We are probably going to ask Anchal and Paco to sit down with us and really hone in on the right coefficients. They have more experience and should be able to really get the right values.
Finally got the SIMPLANT damping to work following Rana's suggestion to try damping one DoF at a time, woo-hoo!
At first, things didn't look good even when we only focus on the POS DoF. I then noticed that the input value (X1:SUS-OPT_PLANT_TM_RESP_1_1_IN1) to the plant was always zero. This was odd bcos it meant the control signal was not making its way to the plant. So I decided to look at the sensor data
(X1:SUS-OPT_PLANT_COIL_IN_UL_OUTPUT, X1:SUS-OPT_PLANT_COIL_IN_UR_OUTPUT, X1:SUS-OPT_PLANT_COIL_IN_LR_OUTPUT, X1:SUS-OPT_PLANT_COIL_IN_LL_OUTPUT)
that adds up via the C2DOF matrix to give the POS DoF and I noticed that these interior nodes can take on large values but always sum up to zero because the pair (UL, LL) was always the negative of (UR,LR). These things should have the same sign, at least in our case where only the POS DoF is excited, so I tracked the issue back to the alternating (-,+,-,+,-) convention for the gains
(X1:SUS-OPT_CTRL_ULCOIL_GAIN, X1:SUS-OPT_CTRL_URCOIL_GAIN, X1:SUS-OPT_CTRL_LRCOIL_GAIN, X1:SUS-OPT_CTRL_LLCOIL_GAIN, X1:SUS-OPT_CTRL_SDCOIL_GAIN)
of the Coil Output filters used in the real system, which we adopted in the hopes that all was well. Anyways, I changed them all back to +1. This also means that we need to change the sign of the gain for the SIDE filter, which I have done also (and check that it damps OK). I decided to reduce the magnitude of the SIDE damping from 1 to 0.1 so that we can see the residuals since the value of -1 quickly sends the error to zero. I also increased the gain magnitude for the other DoF to 4.
When looking at the plot remember that the values actually represent counts with a scaling of 2^15 (or 32768) from the ADC. I switched back to the original filters on FM1 (e.g. pit_pit ) without damping coefficients present in the FM2 filter (e.g. pit_pit_damp).
FYI, Rana used the ETMY suspension MEDM screen to illustrate the working of the single suspension to me and changed maybe POS and PITCH gains while doing so.
Also, the Medify purifier 'replace filter' indicator issue occurred bcos the moonlight button should have been pressed for 3 seconds to reset the 'replace filter' indicator after filter replacement.
Restarted the C1sim machine at about 12:30 to help diagnose a network problem. Everything is back up and running
From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.
Why are these different from the SUS screens I get from the sitemap?
I tried to fix the alarms for sensors on the SUS summary screen. I checked earlier elogs and found the setSensors.py script.
I received errors while running the script and pianosa was refused connection to nds. Yuta suspects problems with the lib directory.
Jamie! Can you fix this?
I asked John Z to talk with Jamie and then install a new NDS2 server software for us. Jamie may know if this happened or was foiled by the linux1 RAID failure.
In any case, our pyNDS stuff ought to be able to talk to NDS2 or our old NDS1 stuff, I hope.
I edited the C1SUS_SUMMARY.adl file and set the channels in alarm mode to show the values in green, yellow and red according to the values of the thresholds (LOLO, LOW, HIGH, HIHI)
I wrote a script in python, which call the command ezcawrite and ezcaread, to change the thresholds one by one.
You can call this program with a button named "Change Thresholds one by one" in the menu come down when you click the ! button.
I'm going to write another program to change the thresholds all together.
I wanted to know what this Vmon exactly is. D010001 is telling us that the Vmon channels are HPFed with fc=30Hz (Attachment 1). Is this true?
I checked the quiscent noise spectrum of the ITMX UL coil output (C1:SUS-ITMX_ULCOIL_OUT) and the corresponding VMON (C1:SUS-ITMX_ULVmon). (Attachment 2 Ref curves). I did not find any good coherence. So the nominal quiscent Vmon output is carrying no useful information.
Question: How much do we need to excite the coil output in order to see any meaningful signal?
As I excite the ITMX UL coil (C1:SUS-ITMX_ULCOIL_EXC) with uniform noise of 100-300 counts below 0.3Hz, I eventually could see the increase of the power spectrum and the coherence (Attachment 2). Below 0.1 Hz the coherence was ~1 and the transfer function was measured to be -75dB and flat. But wait, why is the transfer function flat?
In fact, if I inject broadband noise to the coil, I could increase the coil output and Vmon at the same time without gaining the coherence. (Attachment 3). After some more investigation, I suspect that this HPF is diabled (= bypassed) and aliasing of the high freq signal is causing the noise in Vmon.
In order to check this hypothesis, we need to visit the board.
Based on Koji's observation of a flat TF, it seems more likely the Vmon channels are looking at the path I've highlighted in green (named "EPICS V Mon"), rather than the path in red (named "DAQ Mon") that Koji initially suspected. This path still lacks any AA for the 16Hz EPICS sampling.
Ah, thanks. That makes sense. In that case, we should remove the texts "30Hz HPF" from the suspension screens.
Now we just need AA LPFs for these channels, or hook them up to the RT system.
While preping 1X4 for installation of c1lsc, we removed some old VME crates that were no longer in use. This freed up lots of space in 1X4. We then moved the SUS binary IO chassis 2 and 3, which plug into the 1X4 cross-connect, from 1X5 into the newly freed space in 1X4. This makes the cable run from these modules to the cross connect much cleaner.
Are we keeping these?
[John / Kiwamu]
We found that some of the suspensions channels (for example C1:SUS-BS_POS_IN1 and etc) were not accessible from dataviewer for some reasons.
So far it seems none of the channels associated with c1sus are accessible from dataviewer.
A new library part was made for the single suspension controller (it was originally made from the c1scx controller), using the following procedure:
Once the new sus_single_control library part was made and the library was committed to the cds_user_apps repo, I replaced all sus controller subsystems with this new part, in:
All models were rebuild, installed, and tested, and everything seems to be working fine.