40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 39 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  10754   Thu Dec 4 02:59:05 2014 ericqUpdateLSCBump in Darm Plant

[J,Q]

After some housekeeping (ASS is wonky, alignment of X green beat was bad, tuning of demod angles, fm gains for REFL165), we were able to bring the PRFPMI up to arm powers of 8 very stably. 

We were keeping an eye on the DARM OLG, to make sure the gain was correct. We then saw a bump around 120Hz. Here is the bump. 

Dec4_darmbump.pdf

Changing CARM offset changes its amplitude. Maybe it's a DARM optical spring. It didn't occur to me until after we lost lock that we could have tweaked the DARM offset to move it around if this was the case. 

Unfortunately, due to some unexplained locklosses, we weren't able to get back into a state to measure this more... which is annoying. During that stable lock, Jenne stated that PRCL and DARM noises were looking particularly good. 

We may want to tweak the way we handle the transmission PD handoff; maybe we want to force the switch at a certain place in the carm_up script, so that we're not flipping back and forth during an IR handoff; I think this may have been responsible for a lock loss or two. 

  10755   Thu Dec 4 03:09:06 2014 JenneUpdateLSCBump in Darm Plant: Lockloss after measurement

We were sitting around arm powers of 6, and that loop measurement had finished.  I was about to go down to arm powers of 5ish, but we lost lock.  I'm not sure why.  There's some slow stuff going on in some of the servos, but nothing jumps out at me as a loop oscillation.  It does however kind of look like the PRMI lost lock just before the arm powers went down?  Perhaps this somehow triggered a lockloss?

The time is 1101721675.

Wide view plots:

Arms6_3Dec2014_powers.png

Arms6_3Dec2014_errctrl.png

Arms6_3Dec2014_auxerr.png

Arms6_3Dec2014_angles.png

Zooms:

Arms6_3Dec2014_powers_Zoom.png

Arms6_3Dec2014_errctrl_Zoom.png

Arms6_3Dec2014_auxerr_Zoom.png

Arms6_3Dec2014_angles_Zoom.png


We're stopping for tonight because ETMX is back to its lame-o jumping around.  I went in and squished the cables, but it's still happening.

Also, the FSS PC drive has been high the last few minutes (only starting after we quit for the night).  When the MC re-locks, it sounds like an ocean wave dying out as the noise goes down a little bit.  But, after a few minutes, it'll get mad again and unlock the MC.

Also, also, I noticed this on Monday with Diego, but the LSC-ALS[x,y] filter module gains sometimes mysteriously get set to zero.  WTF?  Eric and I have both independently checked, and we cannot find a single script in the scripts directory with the string "LSC-ALS", so we aren't deliberately changing those.  Does anyone know what might be going on here?

  4528   Fri Apr 15 02:18:50 2011 KojiUpdateLSCBunch of RF cables removed

While Kiwamu was working on the RF cabling at the LSC rack, I removed 80% of SMA cables which were not connected anywhere.
The rack is cleaner now, but not perfect yet. We need patch panels/strain relieving for heliaxes, cleaning up of the RF/LO cables, etc.

  13899   Wed May 30 23:57:08 2018 gautamUpdatePEMBurning smell in office area / control room

[koji, gautam]

We noticed quite a strong burning smell in the office area and control room ~20mins ago. We did a round of the bake lab, 40m VEA and the perimeter of the CES building, and saw nothing burning. But the smell persists inside the office area/control room (although it may be getting less noticeable). There is a whining noise coming from the fan belt on top of the office area. Anyways, since nothing seems to be burning down, we are not investigating further.

Steve [ 10am 5-31 ] we should always check partical count in IFO room

Service requested 

 

  6634   Wed May 9 14:32:31 2012 JenneUpdateCDSBurt restored

Den and Alex left things not-burt restored, and Den mentioned to me that it might need doing.

I burt restored all of our epics.snaps to the 1am today snapshot.  We lost a few hours of striptool trends on the projector, but now they're back (things like the BLRMS don't work if the filters aren't engaged on the PEM model, so it makes sense).

  10026   Wed Jun 11 14:41:11 2014 JenneUpdateSUSBurt restored c1scxepics

ETMX had default 1's for gains, 0's for matrix elements, etc., so I did a burt restore to May 25th, 2pm, which was a few days before the Crash.  It looks fine now.

  4046   Mon Dec 13 17:18:47 2010 josephbUpdateCDSBurt updates

Problem:

Autoburt wouldn't restore settings for front ends on reboot

What was done:

First I moved the burt directory over to the new directory structure.

This involved moving /cvs/cds/caltech/burt/ to /opt/rtcds/caltech/c1/burt.

Then I updated the burt.cron file in the new location, /opt/rtcds/caltech/c1/burt/autoburt/.  This pointed to the new autoburt.pl script.

I created an autoburt directory in the /opt/rtcds/caltech/c1/scripts directory and placed the autoburt.pl script there.

I modified the autoburt.pl script so that it pointed to the new snapshot location.  I also modified it so it updates a directory called "latest" located in the /opt/rtcds/caltech/c1/burt/autoburt directory.  In there is a set of soft links to the latest autoburt backup.

Lastly, I edited the crontab on op340m (using crontab -e) to point to the new burt.cron file in the new location.

This was the easiest solution since the start script is just a simple bash script and I couldn't think of a quick and easy way to have it navigate the snapshots directory reliably.

I then modified the Makefile located in /opt/rtcds/caltech/c1/core/advLigoRTS/ which actually generates the start scripts, to point at the "latest" directory when doing restores.  Previously it had been pointing to /tmp/ which didn't really have anything in it.

So in the future, when building code, it should point to the correct snapshots now.  Using sed I modified all the existing start scripts to point to the latest directory when grabbing snapshots.

Future:

According to Keith directory documentation (see T1000248) , the burt restores should live in the individual target system directory i.e. /target/c1sus/burt, /target/c1lsc/burt, etc.  This is a distinctly different paradigm from what we've been using in the autoburt script, and would require a fairly extensive rewrite of that script to handle this properly.  For the moment I'm keeping the old style, everything in one directory by date.  It would probably be worth discussing if and how to move over to the new system.

  2459   Mon Dec 28 15:19:19 2009 AlbertoUpdateComputersBurtrestored to Dec 26 at 20:00

Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.

Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.

  3555   Thu Sep 9 18:53:56 2010 AlbertoConfigurationElectronicsBusby Box, Rai's Box, SR554 in the RF cabinet

I stored the Busby Box, the Rai's Box and the SR554 preamp in the RF cabinet down the Y arm.

  2286   Tue Nov 17 21:10:35 2009 ranaSummaryElectronicsBusby Low Noise Box: Photos and Upgrades

IMG_0217.JPG

It looked like the Busby Low Noise Box had too much low frequency noise and so I upgraded it. Here is a photo of the inside - I have changed out the 0.8 uF AC coupling cap with a big, white, 20 uF one I found on Rob's desk.

The Busby Box is still working well. The 9V batteries have only run down to 7.8V. The original designer also put a spare AD743 (ultra low current FET amp) and a OP27 (best for ~kOhm source impedances) in there.

Here's the noise after the fix. There's no change in the DC noise, but the AC noise is much lower than before:

busby-noise.png

I think that the AC coupled noise is higher because we are seeing the current noise of the opamp. In the DC coupled case, the impedance to ground from the input pins of the opamp is very low and so the current noise is irrelevant.

The change I implemented, puts in a corner frequency of fc = 1/2/pi/R/C = 1/2/pi/10e3/20e-6 = 0.8 Hz.

Overall, the box is pretty good. Not great in terms of current noise and so it misses getting an A+. But its easily a solid A-.

  11293   Sat May 16 20:37:09 2015 ranaHowToCDSBypassing the CDSUTILS prefix issue

The CDSUTILS package has a feature where it substitutes in a C1 or H1 or L1 prefix depending upon what site you are at. The idea is that this should make code portable between LLO and LHO.

Here at the 40m, we have no need to do that, so its better for us to be able to copy and paste channel names directly from MEDM or whatever without having to remove the "C1:" from all over the place.

the way to do this on the command line is (in bash) to type:

export IFO=''


To make this easier on us, I have implemented this in our shared .bashrc so that its always the case. This might break some scripts which have been adapted to use the weird CDSUTILS convention, so beware and fix appropriately.

  11302   Mon May 18 16:56:12 2015 ericqHowToCDSBypassing the CDSUTILS prefix issue
Quote:

export IFO=''

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

  11304   Mon May 18 17:44:30 2015 ranaHowToCDSBypassing the CDSUTILS prefix issue

Too weird. I undid me changes. We'll have to make the C1: stuff work inside each python script.

Quote:
Quote:

export IFO=''

This makes things act weird:

controls@pianosa|MC 1> z avg 1 "C1:LSC-TRY_OUT"
IFO environment variable not specified.

 

  8672   Tue Jun 4 17:28:09 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

 [Annalisa, Gautam, Rana]

I made the anti-whitening filter for the C1:ALS-TRY_OUT channel.

zpk [[150],[15],1] Hz

Now we can look at the picks of this signal to align the green into the cavity.

We already had some 00 flash, but a better alignment has to be done.

TO DO:

- put the shutter along the beam path

- check the polarization (we have a new PBS for visible)

 

Attachment 1: green.JPG
green.JPG
Attachment 2: QUAD1_1054358327.mp4
  8674   Tue Jun 4 21:50:23 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

 

 [Annalisa, Gautam]

 The green beam alignment has been improved, so we see much more 00 bright flashing. We checked the polarization and the Ygreen shutter is back in place.

A mirror is already in place to steer the rejected beam from the green Faraday into a PD, tomorrow morning we'll put a lens and the PD to take the signal for PDH locking.

 

  8677   Wed Jun 5 14:01:37 2013 ranaUpdateLSCC1:ALS-TRY_OUT filter and green progress

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

  8680   Wed Jun 5 15:03:42 2013 AnnalisaUpdateLSCC1:ALS-TRY_OUT filter and green progress

Quote:

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

The rejected beam from the Faraday is steered with a mirror into the PDA32A PD  and a 75mm fl lens is used to focus the beam into it.

The main beam is a few millimeters away from the mirror mount (maybe 2mm), and I think it should be fine as long as the main beam is not supposed to move.

 

Attachment 1: faraday_rejected_beam.JPG
faraday_rejected_beam.JPG
  4961   Tue Jul 12 10:18:05 2011 JamieUpdateCDSC1:DAQ-FB0_C1???_STATUS indicators red, restored after controller restarts

Yesterday I found the C1:DAQ-FB0_C1???_STATUS lights to be red for the SUS, MCS, SCX, and SCY controllers.  I know this has something to do with model communication with the framebuilder, but I unfortunately don't remember exactly what it is.  I decided to try restarting the affected models to see if that cleared up the problem.  It did.  After restarting c1scx, c1scy, c1sus, and c1mcs everything came back up green.

We need some better documentation about what all of these status indicators mean.

  5006   Wed Jul 20 20:04:54 2011 JamieUpdateCDSC1:DAQ-FB0_C1XXX_STATUS sometimes unexplainably goes red

I have been noticing this happening occasionally, but I don't understand what is causing:

status-fb-red1.png

The channel in question above is C1:DAQ-FB0_C1SCX_STATUS.  This channel is (I believe) reporting some status of the front end model communication with the frame builder, but I'm not sure exactly what.

Usually this problem goes away when I restart the model or the frame builder, but it didn't work this time.  Tomorrow I will figure out what this channel means, why it's sporadically going red, and how to correct it.

  5901   Tue Nov 15 23:44:44 2011 MirkoUpdateCDSC1:LSC & C1:SUS restarted

Earlier this evening C1:LSC died then I hit the DAQ reload after adding an OAF channel to be recorded. No change to any model. Had to restart C1:SUS too. Reloaded burts from this morning 5am, except for C1:IOO, which I loaded from 16:07.

  4664   Mon May 9 12:33:40 2011 kiwamuUpdateLSCC1:LSC-TRIG_MTRX : wrong matrix size

I found that C1:LSC-TRIG_MTRX has a wrong matrix size. It needs to be fixed.

It is designed to have a 11x8 matrix in the simlink model file, but it's been compiled as a 6x8 matrix.

I recompiled c1lsc but it didn't fix the issue. Here below is the matrix statement in the C file :c1lsc.c. Indeed it is 6x8 matrix ....

// MuxMatrix:  LSC_TRIG_MTRX
for(ii=0;ii<8;ii++)
{
  lsc_trig_mtrx[ii] =
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][0] * lsc_imux_trigger[0] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][1] * lsc_imux_trigger[1] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][2] * lsc_imux_trigger[2] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][3] * lsc_imux_trigger[3] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][4] * lsc_imux_trigger[4] +
          pLocalEpics->lsc.LSC_TRIG_MTRX[ii][5] * lsc_imux_trigger[5];
 }

  4665   Mon May 9 13:14:48 2011 josephbUpdateLSCC1:LSC-TRIG_MTRX : wrong matrix size

[Joe, Kiwamu]

There is a feature/bug of the RCG code that you can only have 1 receiving tag for every sending tag.  There were 5 tags which were being received by two tags each, for two different matrices.  Only the first tag was receiving, the second was apparently ignored.

This has been fixed temporarily by putting in direct lines in place of these 5 tags.

Quote:

I found that C1:LSC-TRIG_MTRX has a wrong matrix size. It needs to be fixed.

It is designed to have a 11x8 matrix in the simlink model file, but it's been compiled as a 6x8 matrix.

 

  1338   Thu Feb 26 00:36:53 2009 YoichiSummaryComputersC1:LSC-TRX_OUT broken (and fixed later).
Today, Kakeru tried to convert C1:LSC-TRX_OUT and C1:LSC-TRY_OUT to DAQ channels.
He edited C1LSC.ini in the chans/daq directory to add the channel but it did not work.
Then he reverted the file back to the original one.
But after we still could not access these channels from dataviewer nor tds tools.
We restarted daqd and tpman on fb40m, but the problem persisted. Even rebooting the whole fb40m did not help.
After inspecting the log file of daqd, it was clear that tpman was failing to create test points for those channels.
I rebooted c1daqawg and then restarted tpman and daqd on fb40m again.
This time, the problem went away.
  1292   Wed Feb 11 10:52:22 2009 YoichiConfigurationDAQC1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP disconnected

During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table.  It seemed like a temperature sensor.

The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.

Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.

  950   Tue Sep 16 13:04:22 2008 YoichiConfigurationPEMC1:PSL-FSS_RMTEMP alarm level changed
At the request of Steve, I modified the HIGH value of C1:PSL-FSS_RMTEMP from 21.27 to 23.0.
The HIHI is set to 23.50.
  735   Thu Jul 24 19:29:26 2008 YoichiConfigurationPSLC1:PSL-STAT_FSS_NOM_C_GAIN is changed from 30 to -0.7
Koji, Yoichi

Since the light power going to the ref. cavity is now significantly increased (see Janne's elog later),
C1:PSL-STAT_FSS_NOM_C_GAIN
is changed from 30 to -0.7.
Otherwise, the MC did not lock.
  5666   Fri Oct 14 16:20:11 2011 ZachUpdateSUSC1:SUS-ETMX_SPDMon fixed

I offered to help Kiwamu with some of the 40m work. The first task was to figure out why the ETMX side OSEM monitor was so low, since we know that the depth is about right. It was showing ~0.13 V to the others' ~0.7 V.

TL,WR: There was a wire disconnected from the breakout panel on the side of the rack

I started by pulling the board out and checking to make sure that it was working properly. I injected a sine wave to the SIDE IN and found that it showed up in the signal coming out of the back (into the crate) just fine (see below). One strange thing I noticed while testing the board is that both inputs for each used channel of the MAX333 switches on the board are shorted to their respective outputs. That is, the switches seem to be open to BOTH 0 and 1 logic states. This seems counterintuitive, but perhaps there's something about how these work that I don't know.

board_works.png

 

Then I went about tracing the signal from the back of the crate to the breakout panel on the side of the rack. I opened it up, verified that the ribbon cable was transmitting correctly, and as I went to plug it back in I noticed that one of the wires---the correct one---had come completely undone.

rut_roh_raggie.png

The screw clamp appeared to be a bit finicky, as I had to loosen and tighten it a few times before it finally seemed to grab hold of the wire. It probably just wasn't tight in the first place and the wire was pulled out. Anyway, things are working now:

Screen_shot_2011-10-14_at_4.09.45_PM.png

  5667   Fri Oct 14 18:38:41 2011 kiwamuUpdateSUSC1:SUS-ETMX_SPDMon fixed

Quote from #5666

 Anyway, things are working now:

 Good job ! Thank you so much

  11699   Mon Oct 19 16:16:01 2015 ericqUpdateCDSC1ALS crashes

Gautam was working on his digital frequency counter stuff when the c1als model crashed. I had trouble bringing it back until I realized that, for reasons unknown to me, the safe.snap file that the model looks for at boot had been deleted. (This file lives in /target/c1als/c1alsepics/burt). I copied over this morning's version from Chiara's local backup. 

At the sites, these files are under version control in the userapps svn repository, presumably symlinked into the target directory. We should definitely do something along these lines. 

  8028   Thu Feb 7 19:25:22 2013 yutaUpdateCDSC1ALS filters reloaded

Filters for C1ALS were all gone. So, I copied /opt/rtcds/caltech/c1/chans/C1GCV.txt and renamed it as C1ALS.txt.

I also fixed links in the medm screens; C1ALS.adl and C1ALS_COMPACT.adl.
I'm not sure what happened to C1SC{X,Y} screens.

Quote:

I decided to rename the c1gcv model to be c1als.  This is in an ongoing effort to rename all the ALS stuff as ALS, and get rid of the various GC{V,X,Y} named stuff.

(...snip...)

The above has been done.  Still todo:

  • FIX SCRIPTS!  There are almost certainly scripts that point to GC{V,X,Y} channels.  Those will have to be fixed as we come across them.
  • Fix the c1sc{x,y}/master/C1SC{X,Y}_GC{X,Y}_SLOW.adl screens.  I need to figure out a more consistent place for those screens.
  • Fix the C1ALS_COMPACT screen
  • ???

 

 

  5518   Thu Sep 22 13:56:56 2011 kiwamuUpdateASCC1ASS : status update

The output matrix in the C1ASS servo were coarsely readjusted and the servos seemed working.

However it is difficult to say the servo is very good or so-so,

because the ETMY suspension moves a lot and hence the cavity eigen axis moves a lot too.

 


(to do)

 + optimization of the ETMY oplevs and OSEM damping.
 + evaluation of the performance of the C1ASS with a good damping.

(Background)

 Since we have installed the new mid-HV amplifier for the PZT1 mirror (#5450) it changed the response of the PZT1 (gains from EPICS to the actual angles).
Therefore the C1ASS output matrix needs be adapted to the new PZT1 response.
 
(What I have done)
  What I was measuring was a coupling from each PZT mirror to both beam angle and beam position by looking at the output from the LOCKINs.
So this measurement eventually gives us a nicely diagonalized output matrix by inverting the coupling.
However the measurement turned out to be difficult because the ETMY moved too much.
In fact the cavity eigen axis also moves and the fluctuation was larger than the intentionally introduced beam angle/translation offsets, which are for the coupling measurement.
 
 Instead of measuring the couplings, I put some numbers into the matrix based on a guess.
Since the PZT1 HV amp became weaker than that of PZT2, the elements in the output matrix should be amplified by some number.
Right now the PZT1 amp can drive the mirror in a range of -5 -30 V with EPICS range of +/-10 counts, and for PZT2 it is about 0 -150V with EPICS range of +/-5 counts.
So the difference of the responses in unit of V/counts is about 8.5.
The PZT1 elements in the matrix were multiplied by this number and I became able to close the servos.

Quote from #5455

  + Modification of C1ASS (Kiwamu)

  5543   Mon Sep 26 12:41:27 2011 kiwamuUpdateASCC1ASS : status update

Quote from #5518
(to do)
 + optimization of the ETMY oplevs and OSEM damping.
 + evaluation of the performance of the C1ASS with a good damping.

The servo for aligning the Y arm is working fine with the coarse gain coefficients.

However then I found the ASS_Xarm servo was not healthy.

So the next step is to refine the X arm servo in C1ASS.

 

(some notes)

  + With the ETMY oplev the Y arm became quieter after we recovered the oplev whitening filter (#5523)

  + The Y arm alignment scripts can be run from the usual C1IFO_CONFIGURE screen.

   It will servo the spot positions on ITMY and ETMY, and align the input beam pointing. It brings the Y arm power to about 1.

 + The X arm servo is doing something funny. It doesn't bring the arm power up to 1.

   I thought the X arm didn't need any modifications because the X arm servo doesn't include PZT1 and PZT2.

   So it maybe a simple bug (for example, some switches are disable and so on)

 

  5578   Fri Sep 30 01:18:39 2011 kiwamuUpdateASCC1ASS : status update

Now the C1ASS servos are working fine.

However at the end of the scripts sometimes it changes the DC force (e.g. C1:SUS-ITMX_PIT_COMM and so on) by a wrong amount.

So for this bug, it misaligns the suspensions a lot. I will take a look at the script tomorrow.

Quote from #5543

However then I found the ASS_Xarm servo was not healthy.

  15285   Thu Mar 26 22:31:34 2020 YehonathanUpdateCDSC1AUXEY wiring + channel list

I have made a wiring + channel list that need to be included in the new C!AUXEY Acromag.

It was mostly copied from C1AUXEX

I ignored the IPANG channels since it is going to be removed from the table.

  15292   Thu Apr 2 16:31:33 2020 JonUpdateCDSC1AUXEY wiring + channel list
Quote:

I have made a wiring + channel list that need to be included in the new C!AUXEY Acromag.

I used Yehonathan's wiring assignments to lay the rest of groundwork for the final slow controls machine upgrade, c1auxey. Actions completed:

  • Created an internal wiring diagram for assembling the Acromag chassis (log in with LIGO.ORG credentials to view/edit)
  • Created a new target directory on the network drive:
/cvs/cds/caltech/target/c1auxey1

The "1" will be dropped after the new system is permanently installed.

  • Populated the target directory with files:
    • modbusIOC.service - wraps the EPICS IOC as a systemd service
    • ETMYaux.env - defines the EPICS environment variables
    • ETMYaux.cmd - command file to set up the EPICS IOC
    • ETMYaux.sh - enables DAC outputs to the suspension (executed lastly)
  • Created the EPICS channel databases:
    • ETMYaux.db - migration of the existing database
    • c1auxey_state.db - contains logic for loopback monitoring of the IOC "alive" state (visible from Sitemap > CDS > Slow Controls Status)

Hardware-wise, this system will require:

  • 2 Acromag XT-1221 units (ADC)
  • 1 Acromag XT-1541 unit (DAC)
  • 1 Acromag XT-1111 unit (sinking BIO)

I know that we do have these quantities left on hand. The next steps are to set up the Supermicro host and begin assembling the Acromag chassis. Both of these activities require an in-person presence, so I think this is as far as we can advance this project for now.

  15293   Thu Apr 2 22:19:18 2020 KojiUpdateCDSC1AUXEY wiring + channel list

We want to migrate the end shutter controls from c1aux to the end acromags. Could you include them to the list if not yet?

This will let us remove c1aux from the rack, I believe.

 

  15294   Fri Apr 3 12:09:53 2020 JonUpdateCDSC1AUXEY wiring + channel list
Quote:

We want to migrate the end shutter controls from c1aux to the end acromags. Could you include them to the list if not yet?

This will let us remove c1aux from the rack, I believe.

Yehonathan's list does include C1:AUX-GREEN_Y_Shutter and I copied its definition from /cvs/cds/caltech/target/c1aux/ShutterInterlock.db into the new ETMYaux.db file.

I noticed ShutterInterlock.db still contains about a dozen channels. Some of them appear to be ghosts (like the C1:AUX-PSL_Shutter[...] set, which has since become C1:PSL-PSL_Shutter[...] hosted on c1psl) but others like C1:AUX-GREEN_X_Shutter appear to still be in active use.

  11641   Thu Sep 24 17:06:14 2015 ericqUpdateCalibration-RepairC1CAL Lockins

Just a quick note for now: I've repopulated C1CAL with a limited set of lockin oscillators/demodulators, informed by the aLIGO common LSC model. Screens are updated too. 

Rather than trying to do the whole magnitude phase decompostion, it just does the demodulation of the RFPD signals online; everything beyond that is up to the user to do offline. 

Briefly testing with PRMI, it seems to work as expected. There is some beating evident from the fact that the MICH and PRCL oscillation frequencies are only 2Hz apart; the demod low pass is currently at an arbitrary 1Hz, so it doesn't filter the beat much. 

Screens, models, etc. all svn'd.

  5687   Tue Oct 18 20:50:19 2011 SureshUpdateIOOC1IOO and WFS associated screens

In keeping with the current protocol,  I have started to move all the user-built medm screens associated with C1IOO into the $screens$/c1ioo/master/ directory. 

I then edited the menu button in the sitemap.adl to point to the screens in the ..c1ioo/master/ directory.  All the screens in $screens$/c1ioo/ directory have been backed up into bak/.  I plan to edit the c1ioo model soon and at that time I will delete all the screens in the $screens$/c1ioo directory and let only the automatically regenerated screens  stay there.   If there are broken links to user-built screens associated with c1ioo, please copy the relevant screen to the master/ directory and edit the path in the menus.

 

  5880   Sat Nov 12 02:27:00 2011 SureshUpdateComputersC1IOO front end suddenly froze. Was restarted remotely

[Koji Suresh]

No one was messing with the c1ioo or any other machine.   The medm screens for WFS and MC alignment froze while I was working on Rossa.

There were number of red lights pertaining to c1ioo machine on the CDS_FR_STATUS screen.  So we logged into c1ioo   from Rossa and restarted it with 'sudo shutdown -r now'.  It came back up but the C1IOO_MC_TRANS_SUM, P and Y signals were not available on the C1IOO LOCKMC screen.

I saw several messages similar to the one here


Sat Nov 12 02:09:14 PST 2011

  medmCAExceptionHandlerCb: Channel Access Exception:
  Channel Name: Unavailable
  Native Type: Unavailable
  Native Count: 0
  Access: Unavailable
  IOC: Unavailable
  Message: Virtual circuit disconnect
  Context: c1ioo.martian:43553
  Requested Type: TYPENOTCONN
  Requested Count: 0
  Source File: ../cac.cpp
  Line number: 1126

 

The MC autolocker script wasnt running.  The heartbeat bit was not blinking on the MC_LOCKMC screen.  So we manually restarted the script.  Hopefully it will return to normal operation.

I restarted the fb at Sat Nov 12 02:12:19 PST 2011  in an attempt to see this resolves the problem.

It didnt.

 

  5881   Sat Nov 12 02:44:18 2011 SureshUpdateComputersC1IOO front end suddenly froze. Was restarted remotely

Quote:

[Koji Suresh]

No one was messing with the c1ioo or any other machine.   The medm screens for WFS and MC alignment froze while I was working on Rossa.

There were number of red lights pertaining to c1ioo machine on the CDS_FR_STATUS screen.  So we logged into c1ioo   from Rossa and restarted it with 'sudo shutdown -r now'.  It came back up but the C1IOO_MC_TRANS_SUM, P and Y signals were not available on the C1IOO LOCKMC screen.

I saw several messages similar to the one here


Sat Nov 12 02:09:14 PST 2011

  medmCAExceptionHandlerCb: Channel Access Exception:
  Channel Name: Unavailable
  Native Type: Unavailable
  Native Count: 0
  Access: Unavailable
  IOC: Unavailable
  Message: Virtual circuit disconnect
  Context: c1ioo.martian:43553
  Requested Type: TYPENOTCONN
  Requested Count: 0
  Source File: ../cac.cpp
  Line number: 1126

 

The MC autolocker script wasnt running.  The heartbeat bit was not blinking on the MC_LOCKMC screen.  So we manually restarted the script.  Hopefully it will return to normal operation.

I restarted the fb at Sat Nov 12 02:12:19 PST 2011  in an attempt to see this resolves the problem.

It didnt.

 

 The problem was resolved after I burtrestored (c1mcs c1ioo and c1rfm) epics snapshots.

 

  5732   Tue Oct 25 01:14:15 2011 SureshUpdateIOOC1IOO model modified to include new WFS lockin structure

A while back we faced the problem that when we use several lockins to excite the MC degrees of freedom, their relative phase was not known.  The solution suggested was to use one oscillator and several demodulators.

I have now modified the C1IOO.mdl so that this can be implemented.  Previously we were using the MC_ASS lockins for WFS work.  I have now separated the WFS and MC_ASS structures. 

Other jobs to be done in this context are:

1) The medm screens associated with WFS lockins need to be updated with new channel names.

2) The scripts associated with both MC_ASS decentering and WFS ouput matrix determination have to be updated with the new channel names.

3) I also deleted all medm screens in the $screens$/c1ioo/ directory after copying them to $screens$/c1ioo/bak/.  After installing the new c1ioo model $screens$/c1ioo directory now contains just the automatically created screens.  All other user made screens should go into $screens$/c1ioo/master/ directory

This is a pic of the new c1ioo model:

 

 c1ioo20111025.png

 

  5735   Tue Oct 25 16:24:58 2011 SureshUpdateIOOC1IOO model modified to include new WFS lockin structure

I forgot to mention another change I made to the C1IOO model.

The location of the WFS global switch and the WFS_GAIN have been shifted. The switch now cuts off signals just before the WFS servo filters.

I have also added some test points just before the switch and the so that we can monitor the WFS error signals which would be unaffected even if the WFS_GAIN is changed..

 

 

Quote:

A while back we faced the problem that when we use several lockins to excite the MC degrees of freedom, their relative phase was not known.  The solution suggested was to use one oscillator and several demodulators.

I have now modified the C1IOO.mdl so that this can be implemented.  Previously we were using the MC_ASS lockins for WFS work.  I have not separated the WFS and MC_ASS structures. 

Other jobs to be done in this context are:

1) The medm screens associated with WFS lockins need to be updated with new channel names.

2) The scripts associated with both MC_ASS decentering and WFS ouput matrix determination have to be updated with the new channel names.

3) I also deleted all mdem screens in the $screens$/c1ioo/ directory after copying them to $screens$/c1ioo/bak/.  After installing the new c1ioo model $screens$/c1ioo model now contains just the automatically created screens.  All other user made screens should to into $screens$/c1ioo/master/ directory

This is a pic of the new c1ioo model:

 

 c1ioo20111025.png

 

 

  5737   Tue Oct 25 18:50:22 2011 SureshUpdateIOOC1IOO model modified to include new WFS lockin structure

Some small fixes to the c1ioo model.

1) I edited the WFS lockin modules to make use of new library part called demod.

2) c1ioo model has been compiled and restarted.

3) fb was restarted at Tue Oct 25 18:43:55 PDT 2011

 

Quote:

I forgot to mention another change I made to the C1IOO model.

The location of the WFS global switch has been shifted. It now cuts off signals just before the WFS servo filters.

I have also added some test points just before the switch so that we can monitor the WFS sensor signals even if the switch is off.

 

 

Quote:

A while back we faced the problem that when we use several lockins to excite the MC degrees of freedom, their relative phase was not known.  The solution suggested was to use one oscillator and several demodulators.

I have now modified the C1IOO.mdl so that this can be implemented.  Previously we were using the MC_ASS lockins for WFS work.  I have not separated the WFS and MC_ASS structures. 

Other jobs to be done in this context are:

1) The medm screens associated with WFS lockins need to be updated with new channel names.

2) The scripts associated with both MC_ASS decentering and WFS ouput matrix determination have to be updated with the new channel names.

3) I also deleted all mdem screens in the $screens$/c1ioo/ directory after copying them to $screens$/c1ioo/bak/.  After installing the new c1ioo model $screens$/c1ioo model now contains just the automatically created screens.  All other user made screens should to into $screens$/c1ioo/master/ directory

This is a pic of the new c1ioo model:

 

 c1ioo20111025.png

 

 

 

  5327   Tue Aug 30 17:31:55 2011 SureshUpdateIOOC1IOO model reverted and fb restarted

I reverted the C1IOO model to the last working version and restarted the fb at this time..Tue Aug 30 17:28:38 PDT 2011

  5579   Fri Sep 30 02:56:56 2011 kiwamuUpdateCDSC1IOO.ini and C1LSC.ini files reverted

[Suresh/Kiwamu]

We found that the C1LSC.ini and C1IOO.ini file had been refreshed and there were a few recorded channels in the files.

So we manually recovered C1LSC.ini file using the daqconfig GUI screen.

For the C1IOO.ini file we simply replaced it by the archived one which had been saved in 22nd of September.

Then we restarted daqd.

  1028   Mon Oct 6 12:45:41 2008 AlbertoDAQLSCC1LSC in coma
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.
  1029   Mon Oct 6 16:41:33 2008 AlbertoDAQLSCC1LSC in coma

Quote:
Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.


Alex, Rob, Alberto,

Alex replaced the Pentek board used by C1LSC with a spare one that they had at the Wilson house. That fixed the DMA failure but since the board had a channel broken, one of the channels (POY) was still not available.

Looking at the wiring diagram of the ASC crate, we found that one of the Pentek boards in it was actually not used by anything and thus available to replace the bad one in LSC. We switched the two boards so that now the one that Alex installed is mounted in the ASC crate and it is connected to the cable labeled 1x2-ASC 6.

C1LSC is up again and all the channels in the C1LSC screen, including POY, now seem to be working properly.
  7279   Sun Aug 26 21:47:50 2012 KojiUpdateCDSC1LSC ooze

I came in to the lab in the evening and found c1lsc had "red" for FB connection.
I restarted c1lsc models and it kept hung the machine everytime.

I decided to kill all of the model during the startup sequence right after the reboot.
Then run only c1x04 and c1lsc. It seems that c1oaf was the cause, but it wasn't clear.

  14187   Tue Aug 28 18:39:41 2018 JonUpdateCDSC1LSC, C1AUX reboots

I found c1lsc unresponsive again today. Following the procedure in elog #13935, I ran the rebootC1LSC.sh script to perform a soft reboot of c1lsc and restart the epics processes on c1lsc, c1sus, and c1ioo. It worked. I also manually restarted one unresponsive slow machine, c1aux.

After the restarts, the CDS overview page shows the first three models on c1lsc are online (image attached). The above elog references c1oaf having to be restarted manually, so I attempted to do that. I connect via ssh to c1lsc and ran the script startc1oaf. This failed as well, however.

In this state I was able to lock the MICH configuration, which is sufficient for my purposes for now, but I was not able to lock either of the arm cavities. Are some of the still-dead models necessary to lock in resonant configurations?

Attachment 1: CDS_FE_STATUS.png
CDS_FE_STATUS.png
ELOG V3.1.3-