40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 42 of 335 Not logged in
ID Date Author Type Category Subject
7993   Mon Feb 4 15:26:10 2013 JamieUpdateComputer Scripts / ProgramsNew "getdata" program to pull NDS channel data, including test points

I've added a new program called getdata (to scripts/general/getdata) that will conveniently pull arbitrary data from an NDS server, either DQ or online (ie. testpoints).

Start times and durations may be specified.  If past data is requested, you must of course be requesting DQ channels.  If no start time is specified, data will be pulled "online", in which case you can specify testpoints.

If an output directory is specified, the retrieved data will be stored in that directory in files named after the channels.  If an output directory is not specified, no output will be

Help usage:

controls@pianosa:~ 0$/opt/rtcds/caltech/c1/scripts/general/getdata --help usage: getdata [-h] [-s START] [-d DURATION] [-o OUTDIR] channel [channel ...] Pull online or DQ data from an NDS server. Use NDSSERVER environment variable to specify host:port. positional arguments: channel Acquisition channel. Multiple channels may be specified acquired at once. optional arguments: -h, --help show this help message and exit -s START, --start START GPS start time. If omitted, online data will be fetched. When specified must also specify duration. -d DURATION, --duration DURATION Length of data to acquire. -o OUTDIR, --outdir OUTDIR Output directory. Data from each channel stored as '.txt'. Any existing data files will be automatically overwritten. controls@pianosa:~ 0$


7995   Mon Feb 4 19:48:32 2013 JamieSummaryGeneralarbcav recalc of PRC with correct ITM transmission

I noticed that Koji used a high reflector for the ITMs for his full PRC arbcav calculation. I just redo it here with the correct ITM transmission and RoC for completeness.

In this case the finesse is 95, instead of 121.

7996   Mon Feb 4 22:46:03 2013 JamieSummaryGeneralarbcav for SRC with curved TTs

I ran Zach's arbcav on our SRC with curved TTs and the situation looks much worse than the PRC.

I used the following parameters

SRM: RoC = 142 m, T = 10%
ITM: RoC = 83.1e3 m, T = 1.4%
SRC length: 5.37 m

In this case, with TT RoC of -600, the combined cavity g-factor = 0.9986, and astigmatism from SR3 makes the cavity patently not stable.  You have to go up to an RoC of -710 before the cavity is just over the edge.

8005   Tue Feb 5 19:16:22 2013 JamieSummaryGeneralarbcav of PRC with +600 RoC PR2/3

This is just a simple rerun of arbcav from #7995 but with the PR2/3 RoCs set to 600, instead of -600.  Overall g-factor = 0.922, and the modes are well separated:

This doesn't take into account the effect of traveling through the substrates (still working on it).  It assumes the PR2/3 have been moved such that the cavity fold lengths remain the same.

This is something that we need to keep in mind: we will need to adjust the position of the PR2/3 to keep the fold lengths the same.

8019   Wed Feb 6 22:39:23 2013 JamieUpdateGeneralPRC/arm mode matching with flipped PR2/PR3: coming soon

I intended to post a long analysis of the PRC/arm mode matching for the various TT situations using Nic's a la mode mode matching program, but I seem to have encountered what I think might be a bug.  I'll talk to Nic about it first thing in the AM.  Once the issue is resolved I should be able to post the full analysis fairly quickly.  Sorry about the delay.

8022   Thu Feb 7 12:56:18 2013 JamieSummaryGeneralPRC/arm mode matching calculations

NOTE: There was a small bug in my initial calculation.  The plots and numbers have been updated with the fixed values.  The conclusion remains the same.

Using Nic's a la mode mode matching program, I've calculated the PRC mode and g-parameter for various PR2/3 scenarios.  I then looked at the overlap of the resultant PRC eigenmodes with the ARM eigenmode.  Here are the results:

NOTE: each optical element below (PR2, ITM, etc.) is represented by a compound M matrix.  The z axis in these plots is actually just the free space propagation between the elements, not the overall optical path length.

## ARM

This is the ARM mode I used for all comparisons:

 tangential sagittal gouy shift, one-way 55.63 55.63 g (from gouy) 0.303 0.303 g (product of individual mirror g) 0.303 0.303

## PRC, nominal design (flat PR2/3)

This is the nominal "as designed" PRC, with flat PR2/3 folding mirrors.

 tangential sagittal gouy shift, one-way 14.05 14.05 g (from gouy) 0.941 0.941 g (product of individual mirror g) 0.942 0.942

## PRC, both PR2/3 flipped

This assumes both PR2 and PR3 have a RoC of -600 when not flipped, and includes the affect of propagation through the substrates.

 tangential sagittal gouy shift, one-way 19.76 18.45 g (from gouy) 0.886 0.900 g (product of individual mirror g) 0.888 0.902

## PRC, only PR2 flipped

In this case we only flip PR2 and leave PR3 with it's bad -600 RoC:

 tangential sagittal gouy shift, one-way 18.37 18.31 g (from gouy) 0.901 0.901 g (product of individual mirror g) 0.903 0.903

# Discussion

I left out the current situation (PR2/3 with -600 RoC) and the case where only PR3 is flipped, since those are both unstable according to a la mode.

### I guess the main take away is that we get slightly better PRC stability and mode matching to the arms by only flipping PR2.

8032   Fri Feb 8 11:01:18 2013 JamieUpdateLockingPRMI work

I completely agree with Koji.  We definitely should have locked the half PRC first.  We were all set up for that.  Why go through all this work to align MICH when we haven't confirmed with the half PRC that the flipping is helping us?  The first rule of debugging is to only make one change at a time.  We have measurements from the half PRC, so we could have made a direct comparison with those to see how things have changed.  If we jump the gun we're going to end up wasting more time when we have to back-track.

Also, we never talked about moving PR2 to adjust optical path length, although I can understand why we would think that should be done.  My calculations were all done assuming the free-space separation between PRM/PR2 and PR2/PR3 were unchanged.  It's possible changing the position is better, but again, it's more work and it changes multiple things at one.  I can redo my calculations for this new scenario, but we need to update our drawings with this new configuration.  Please note precisely where PR2 has moved to.

We should have just flipped PR2 and that's it.  Then we could have run the exact same measurements we had previously.  Only then, once we understood this new simple cavity, should we have done further adjustments.

8033   Fri Feb 8 11:07:07 2013 JamieSummaryGeneralPRC/arm mode matching calculations

 Quote: I would guess that either flipping PR2 or PR3 would give nearly the same effect (g = 0.9) and that flipping both makes it even more stable (smaller g). But what we really need is to see the cavity scan / HOM resonance plot to compare the cases. The difference of 0.5% in mode-matching is not a strong motivation to make a choice, but sensitivity to accidental HOM resonance of either the carrier or f1 or f2 sidebands would be. Should also check for 2*f2 and 2*f1 resonances since our modulation depth may be as high as 0.3. Accidental 2f resonance may disturb the 3f error signals.

You would guess, and I would have guessed too, but the calculations tell the story.   Flipping both does not increase the stability.  The main issue is that flipping PR3 induces considerable astigmatism.  This is why flipping PR3 alone does not make the cavity stable.  I will do some simple calculations today that will demonstrate this effect.

But again, we should only change one thing at a time and understand that before moving on.  Given that the calculations show that flipping only PR2 should alone have a positive affect, we should do just that first, and verify that we understand what's going on, before we move on to making more changes.

I will try to make some more arbcav runs as well, for just the flipped PR2.

8040   Fri Feb 8 18:23:32 2013 JamieSummaryGeneralarbcav of half PRC with flipped PR2

Arbcav with half PRC (flat temporary mirror in front of BS), PR2 RoC = 600m, PR3 RoC = -600m:

NOTE: this does NOT include the affect of the PR2 substrate in the cavity.  Arbcav does not handle that.  It would have to be modified to accept arbitrary ABCD matrices.

NOTE: I added to the mode plot the frequency separation of the first HOMs from the carrier (\omega_{10/01}), in units of carrier FSR.

8059   Mon Feb 11 17:17:30 2013 JamieSummaryGeneralmore analysis of half PRC with flipped PR2

 Quote: We need expected finesse and g-factor to compare with mode-scan measurement. Can you give us the g-factor of the half-PRC and what losses did you assumed to calculate the finesse?

This is exactly why I added the higher order mode spacing, so you could calculate the g parameter.  For TEM order N = n + m with spacing f_N, the overall cavity g parameter should be:

g = (cos( (f_N/f_FSR) * (\pi/N) ))^2

The label on the previous plat should really be f_N/FSR, not \omega_{10,01}

BUT, arbcav does not currently handle arbitrary ABCD matrices for the mirrors, so it's going to be slightly less accurate for our more complex flipped mirrors.  The affect would be bigger for a flipped PR3 than for a flipped PR2, because of the larger incidence angle, so arbcav will be a little more correct for our flipped PR2 only case (see below).

 Quote: Also, flipped PR2 should have RoC of - R_HR * n_sub (minus measured RoC of HR surface multiplied by the substrate refractive index) because of the flipping.

This is not correct.  Multiplying the RoC by -N would be a very large change.  For an arbitrary ABCD matrix:

R_eff = -2 / C


When the incident angle in non-zero:

tangential: R_eff = R_eff / cos(\theta)
sagittal:   R_eff = R_eff * cos(\theta)


For flipped PR2, with small 1.5 degree incident angle and RoC of -706 at HR:

M_t = M_s = [1.0000, 0.0131; -0.0028, 1.0000]
R_eff = 705.9


For flipped PR3, with large 41 degree incident angle and RoC of -700 at HR:

M_t = [1.0000, 0; 0.0038, 1.0000]
M_s = [1.0000, 0; 0.0022, 1.0000]
R_eff = 592.4


The affect of the substrate is negligible for flipped PR2 but significant for flipped PR3.

# The current half-PRC setup

OK, I have now completely reconciled my alamode and arbcav calculations.  I found a small bug in how I was calculating the ABCD matrix for non-flipped TTs that made a small difference.  I now get the exact same g parameter values with both with identical input parameters.

 Quote: According to Jenne dictionary, HR curvature measured from HR side is; PRM: -122.1 m PR2: -706 m PR3: - 700 m TM in front of BS: -581 m

Sooooo, I have redone my alamode and arbcav calculations with these updated values.  Here are the resulting g parameters

 arbcav a la mode measurement g tangential 0.9754 0.9753 0.986 +/- 0.001 g sagital 0.9686 0.9685 0.968 +/- 0.001

So the sagittal values all agree pretty well, but the tangential measurement does not.  Maybe there is an actual astigmatism in one of the optics, not due to angle of incidence?

arbcav HOM plot:

8062   Mon Feb 11 18:44:34 2013 JamieUpdateComputerspasswerdz changed

 Quote: Be Prepared http://xkcd.com/936/

Password for nodus and all control room workstations has been changed.  Look for new one in usual place.

We will try to change the password on all the RTS machines soon.  For the moment, though, they remain with the old passwerd.

8068   Tue Feb 12 18:25:43 2013 JamieSummaryGeneralhalf PRC with astigmatic PR2/3

Quote:
 arbcav a la mode measurement g tangential 0.9754 0.9753 0.986 +/- 0.001 g sagital 0.9686 0.9685 0.968 +/- 0.001

Given that we're measuring different g parameters in the tangential and sagittal planes, I went back to alamode to see what astigmatism I could put into PR2 and/or PR3 to match what we're measuring.  I looked at three cases: only PR2 is astigmatic, only PR3 is, or where we split the difference.  Since the sagittal measurement matches, I left all the sagittal curvatures the same in

### case 1: PR3 only

 PR2 RoC (m) PR3 RoC (m) g (half PRC) tangential 706 -420 0.986 sagittal 706 -700 0.969

### case 2: PR3 only

 PR2 RoC (m) PR3 RoC (m) g (half PRC) tangential 5000 -700 0.986 sagittal 706 -700 0.969

### case 3: PR2 and PR3

 PR2 RoC (m) PR3 RoC (m) g parameter tangential 2000 -600 0.986 sagittal 706 -700 0.969

From Koji's post about the scans of the G&H mirrors, it looks entirely reasonable that we could have these levels of astigmatism in the optics.

## What this means for full PRC

These all make the same full PRC situation:

g (tangential):  0.966

g (sagittal):  0.939

ARM mode matching:  0.988

8069   Tue Feb 12 18:28:46 2013 JamieSummaryOpticsCurvature radii of the G&H/LaserOptik mirrors

 Quote: I, by chance, found  that my windows partition has Vision32 installed. So I run my usual curvature characterization for the TT phasemaps.

Is it possible to calculate astigmatism with your tools?  Can we get curvature in X/Y direction, preferably aligned with some axis that we might align to in the vacuum?

8070   Tue Feb 12 20:42:36 2013 JamieUpdateAlignmentIFO alignment in prep for in-air PRMI

Yuta, Manasa, Jamie, Jenne, Steve, Rana

Starting this morning, we removed the temporary half PRC mirror in front of BS and started to align the IFO in prep for an in-air lock of the PRMI.

This morning, using the new awesome steerable active input TTs, Jenne and I centred the beam on PRM, PR2/3, BS, ITMY and ETMY.

After lunch, Yuta and Manasa aligned the Y ARM, by looking at the multi-pass beam.  The X-end door was still on, so they roughly aligned to the X ARM by centring on ITMX with BS.  They then got fringes at the BS, and tweaked the ITMs and PRM to get full fringes at BS.

We're currently stuck because the REFL beam appears to be clipped coming out of the faraday, even though the retro-reflected beam from PRM is cleanly going through the faraday output aperture.  The best guess at the moment is that the beam is leaving MC at an angle, so the retro-reflected beam is coming out of the faraday at an angle.  We did not center spots on MC mirrors before we started the alignment procedure today.  That was dumb.

We may be ok to do our PRMI characterization with the clipped REFL, though, then we can fix everything right before we close up.  We're going to need to go back to touch up alignment before we close up anyway (we need to get PR2 centered).

Yuta and Manasa are finishing up now by making sure the AS and REFL beams are cleanly existing onto the AS table.

Tomorrow we will set up the PRM oplev, and start to look at the in-air PRMI.  Hopefully we can be ready to close up by the end of the week.

8084   Thu Feb 14 10:42:41 2013 JamieSummaryAlignmentMMT, curved TTs does not explain beam ellipticity at Faraday

After using alamode to calculate the round-trip mode of the beam at the Faraday exit after retro-reflection form the PRM, I'm not able to blame the MMT and TT curvature for the beam ellipticity.

I assume an input waist at the mode cleaner of [0.00159, 0.00151] (in [T, S]).  Propagating this through the MMT to PRM, then retro-reflecting back with flat TTs I get

w_t/w_s = 0.9955,  e = 0.0045

If I give the TTs a -600 m curvature, I get:

w_t/w_s = 1.0419,  e = 0.0402

That's just a 4% ellipticity, which is certainly less than we see.  I would have to crank up the TT curvature to -100m or so to see an ellipticity of 20%.  We're seeing something that looks bigger than 50% to me.

Below are beam size through MMT + PRM retro-reflection, TT RoC = -600m:

8088   Fri Feb 15 15:21:07 2013 JamieUpdateComputersc1iscex IO-chassis dead

I appears that the c1iscex IO-chassis is either dead or in a very bad state.  The PCIe interface card in the IO-chassis is showing four red lights, where it's supposed to be showing a dozen or so green lights.  Obviously this is going to prevent anything from running.

We've had power issues with this chassis before, so possibly that's what we're running into now.  I'll pull the chassis and diagnose asap.

8108   Tue Feb 19 12:02:00 2013 JamieUpdateIOOIMC table levelling.

In order to address the issue of low MC1 OSEM voltages, Yuta and I looked at the IMC table levelling.  Looking with the bubble level, Yuta confirmed that the table was indeed out of level in the direction that would cause MC1 to move closer to it's cage, and therefore lower it's OSEM voltages.  Looking at the trends, it looks like the table was not well levelled after TT1 installation.  We should have been more careful, and we should have looked at the MC1/3 voltages after levelling.

Yuta moved weights around on the table to recover level with the bubble level.  Unfortunately this did not bring us back to good MC1 voltages.  We speculate that the table was maybe not perfectly level to begin with.  We decided to try to recover the MC1 OSEM voltages, rather than go solely with the bubble level, since we believe that the MC suspensions should be a good reference.  Yuta then moved weights around until we got the MC1/3 voltages back into an acceptable range.  The voltages are still not perfect, but I believe that they're acceptable.

The result is that, according to the bubble level, the IMC table is low towards MC2.  We are measuring spot positions now.  If the spot positions look ok, then I think we can live with this amount of skew.  Otherwise, we'll have to physically adjust the MC1 OSEMS.

8109   Tue Feb 19 15:10:02 2013 JamieUpdateCDSc1iscex alive again

c1iscex is back up.  It is communicating with it's IO chassis, and all of it's models (c1x01, c1scx, c1spx) are running again.

The problem was that the IO chassis had no connection to the computer.  The One Stop card in the IO chassis, which is the PCIe bridge from the front-end machine and the IO chassis, was showing four red lights instead of the dozen or so green lights that it usually shows.  Upon closer inspection, the card appeared to be complaining that it had no connection to the host card in the front-end machine.  Un-illuminated lights on the host card seemed to be pointing to the same thing.

There are two connector slots on the expansion card, presumably for a daisy chain situation.  Looking at other IO chassis in the lab I determined that the cable from the front-end machine was plugged into the wrong slot in the One Stop card.  wtf.

Did someone unplug the cable connecting c1iscex to it's IO chassis, and then replug it in in the wrong slot?  A human must have done this.

8128   Thu Feb 21 14:32:02 2013 JamieUpdateCDSc1iscex models restarted

 Quote: c1iscex is dead again.  Red lights, no "breathing" on the FE status screen.

The c1iscex machine itself wasn't dead, the models were just not running.  Here are the last messages in dmesg:

[130432.926002] c1spx: ADC TIMEOUT 0 7060 20 7124
[130432.926002] c1scx: ADC TIMEOUT 0 7060 20 7124
[130433.941008] c1x01: timeout 0 1000000
[130433.941008] c1x01: exiting from fe_code()


I'm guessing maybe the timing signal was lost, so the ADC stopped clocking.   Since the ADC clock is the everything clock, all the "fe" code (ie. models) aborted. Not sure what would have caused it.

I restarted all the models ("rtcds restart all") and everything came up fine. Obviously we should keep our eyes on things, and note if anything strange was happening if this happens again.

8140   Fri Feb 22 20:28:17 2013 JamieUpdateComputerslinux1 dead, then undead

At around 2:30pm today something brought down most of the martian network.  All control room workstations, nodus, etc. were unresponsive.  After poking around for a bit I finally figured it had to be linux1, which serves the NFS filesystem for all the important CDS stuff.  linux1 was indeed completely unresponsive.

Looking closer I noticed that the Fibrenetix FX-606-U4 SCSI hardware RAID device connected to linux1 (see #1901), which holds cds network filesystem, was showing "IDE Channel #4 Error Reading" on it's little LCD display.  I assumed this was the cause of the linux1 crash.

I hard shutdown linux1, and powered off the Fibrenetix device.  I pulled the disk from slot 4 and replaced it with one of the spares we had in the control room cabinets.  I powered the device back up and it beeped for a while.  Unfortunately the device was requiring a password to access it from the front panel, and I could find no manual for the device in the lab, nor does the manufacturer offer the manual on it's web site.

Eventually I was able to get linux1 fully rebooted (after some fscks) and it seemed to mount the hardware RAID (as /dev/sdc1) fine.  The brought the NFS back.  I had to reboot nodus to get it recovered, but all the control room and front-end linux machines seemed to recover on their own (although the front-ends did need an mxstream restart).

The remaining problem is that the linux1 hardware RAID device is still currently unaccessible, and it's not clear to me that it's actually synced the new disk that I put in it.  In other words I have very little confidence that we actually have an operational RAID for /opt/rtcds.  I've contacted the LDAS guys (ie. Dan Kozak) who are managing the 40m backup to confirm that the backup is legit.  In the mean time I'm going to spec out some replacement disks onto which to copy /opt/rtcds, and also so that we can get rid of this old SCSI RAID thing.

Attachment 1: FX-606-U4_1205.pdf
8159   Mon Feb 25 20:04:22 2013 JamieUpdateSUSsuspension controller model modifications in prep for global damping initiative

[Jamie, Brett, Jenne]

We made some small modifications to the sus_single_control suspension controller library part to get in/out the signals that Brett needs for his "global damping" work.  We brought out the POS signal before the SUSPOS DOF filter, and we added a new GLOBPOS input to accommodate the global damping control signals.  We added a new EPIC input to control a switch between local and global damping.  It's all best seen from this detail from the model:

The POSOUT goto goes to an additional output.  As you can see I did a bunch of cleanup to the spaghetti in this part of the model as well.

As the part has a new input and output now we had to modify c1sus, c1scx, c1scy, and c1mcs models as well.  I did a bunch of cleanup in those models as well.  The models have all been compiled and installed, but a restart is still needed.  I'll do this first thing tomorrow morning.

All changes were committed to the userapps SVN, like they should always be.

We still need to update the SUS MEDM screens to display these new signals, and add switches for the local/global switch.  I'll do this tomorrow.

During the cleanup I found multiple broken links to the sus_single_control library part.  This is not good.  I assume that most of them were accidental, but we need to be careful when modifying things.  If we break those links we could think we're updating controller models when in fact we're not.

The one exception I found was that the MC2 controller link was clearly broken on purpose, as the MC2 controller has additional stuff added to it ("STATE_ESTIMATE"):

I can find no elog that mentions the words "STATE" and "ESTIMATE".  This is obviously very problematic.  I'm assuming Den made these modifications, and I found this report: 7497, which mentions something about "state estimation" and MC2.  I can't find any other record of these changes, or that the MC2 controller was broken from the library.  This is complete mickey mouse bullshit.  Shame shame shame.  Don't ever make changes like this and not log it.

I'm going to let this sit for a day, but tomorrow I'm going to remove replace the MC2 controller with a proper link to the sus_single_control library part.  This work was never logged so it didn't happen as far as I'm concerned.

8168   Tue Feb 26 10:17:44 2013 JamieUpdateSUSremoved global/local switch from sus_single_control

[jamie, brett]

Yesterday we added some new control logic to the sus_single_control part to allow for global damping.  Today we decided that a binary switch between local/global damping was probably a bit extreme since we might want to smoothly ramp between them, instead of just hard switching.  So we removed this switch and are now just summing the control inputs from global and local damping right before the output matrix.

Changes were committed to the SVN, and all suspension models were recompiled/installed/restarted.

8169   Tue Feb 26 10:20:31 2013 JamieUpdateSUSMC2 suspension controller reverted to library part

I made good on my threat from yesterday to convert the MC2 suspension controller to the library part.  Whatever changes were in MC2 were thrown out, although they are archived in the SVN.  Again, this kind of undocumented breaking is forbidden.

Change was committed to SVN, and c1mcs was recompiled/installed/restarted.

8209   Fri Mar 1 18:23:28 2013 JamieUpdateComputer Scripts / Programsupdated version of "getdata"

I updated the getdata script so that it can now handle downloading long stretches of data.

  /opt/rtcds/caltech/c1/scripts/general/getdata


It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.

I also added a couple new options:

* --append allows for appending to existing data files

8223   Mon Mar 4 18:11:10 2013 JamieUpdateSUSCleaning up suspension POS inputs

I did a little bit of cleanup of the suspension POS inputs today, both in model and MEDM land.

## model

sus_single_control.mdl was simplified such that now there are just two position inputs:

• POS: with LSC filter
• ALTPOS: unfiltered

The regular LSC inputs go into POS, and any optic-specific extra pos inputs go into ALTPOS after being properly filtered and summed.

So for instance, MC2_MCL and MC2_ALS are filtered and summed then go into MC2 ALTPOS.  The ETM ALS inputs go into ALTPOS.

I modified the GLOBAL DAMPING outputs so that they are filtered in the GLOBAL block before being sent to be summed before going into ALTPOS for {I,E}TM{X,Y}.

All suspension models were rebuilt/installed/restarted.

## MEDM

The SUS_SINGLE.adl template screen was modified such that the POS button now points to optic-specific POS filter screens at:

/opt/rtcds/caltech/c1/medm/master/sus/SUS_$(OPTIC)_POS.adl  For MC1, MC3, PRM, BS, SRM these are links to SUS_SINGLE_POS.adl. The rest of the suspensions (MC2, {I,E}TM{X,Y}) now have custom screens that are variations of SUS_SINGLE_POS but with their extra filter screens added in. For instance, here is the new SUS_ETMX_POS.adl: This gets rid of all the white screen crap that was in here before. All of this has been committed to the SVN. NOTE: symlinks were heavily used when sorting this stuff out, so check for symlinks when modifying in the future. 8243 Wed Mar 6 18:27:24 2013 JamieUpdateGeneralnow recording input TT channels to frames, but why no autoburt? I spent some time trying to figure out how to get a record of the pointing of the input pointing tip-tilt (TT) channels. ## Frames 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
[C1:IOO-TT1_PIT_OFFSET]
[C1:IOO-TT1_YAW_OFFSET]
[C1:IOO-TT2_PIT_OFFSET]
[C1:IOO-TT2_YAW_OFFSET]
controls@pianosa:~ 0$ I then confirmed that the data is being recorded: controls@pianosa:~ 0$ FrChannels /frames/full/10466/C-R-1046657424-16.gwf | grep TT
C1:IOO-TT1_PIT_OFFSET 16
C1:IOO-TT1_YAW_OFFSET 16
C1:IOO-TT2_PIT_OFFSET 16
C1:IOO-TT2_YAW_OFFSET 16
controls@pianosa:~ 0$ ## BURT 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/
controls@pianosa:~ 1$ 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()
controls@pianosa:~ 0$ 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
controls@pianosa:~ 0$ 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. 8245 Wed Mar 6 20:21:34 2013 JamieUpdateGeneralBeatbox pulled from rack I pulled the beatbox from the 1X2 rack so that I could try to hack in some output whitening filters. These are shamefully absent because of my mis-manufacturing of the power on the board. Right now we're just using the MON output. The MON output buffer (U10) is the only chip in the output section that's stuffed: The power problem is that all the AD829s were drawn with their power lines reversed. We fixed this by flipping the +15 and -15 power planes and not stuffing the differential output drivers (AD8672). It's possible to hack in some resistors/capacitors around U10 to get us some filtering there. It's also possible to just stuff U9, which is where the whitening is supposed to be, then just jump it's output over to the MON output jack. That might be the cleanest solution, with the least amount of hacking on the board. In any event, we really need to make a v2 of these boards ASAP. Before we do that, though, we need to figure out what we're going to do with the "disco comparator" stage back near the RF input. (There are also a bunch of other improvements that will be incorporated into v2). 8278 Tue Mar 12 12:06:22 2013 JamieUpdateComputersFB recovered, RAID power supply #1 dead The framebuilder RAID is back online. The disk had been mounted read-only (see below) so daqd couldn't write frames, which was in turn causing it to segfault immediately, so it was constantly restarting. The jetstor RAID unit itself has a dead power supply. This is not fatal, since it has three. It has three so it can continue to function if one fails. I have removed the bad supply and gave it to Steve so he can get a suitable replacement. Some recovery had to be done on fb to get everything back up and running again. I ran into issues trying to do it on the fly, so I eventually just rebooted. It seemed to come back ok, except for something going on with daqd. It was reporting the following error upon restart: [Tue Mar 12 11:43:54 2013] main profiler warning: 0 empty blocks in the buffer  It was spitting out this message about once a second, until eventually the daqd died. When it restarted it seemed to come back up fine. I'm not exactly clear what those messages were about, but I think it has something to do with not being able to dump it's data buffers to disk. I'm guessing that this was a residual problem from the umounted /frames, which somehow cleared on it's own. Everything seems to be ok now.  Quote: Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping. We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly. The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw. That's a lot) had a red light next to it, so I power cycled the box. After the box came back up, it started beeping again, with the same front panel message: H/W monitor power #1 failed. DO NOT DO THIS. This is what caused all the problems. The unit has three redundant power supplies, for just this reason. It was probably continuing to function fine. The beeping was just to tell you that there was something that needed attention. Rebooting the device does nothing to solve the problem. Rebooting in an attempt to silence beeping is not a solution. Shutting of the RAID unit is basically the equivalent of ripping out a mounted external USB drive. You can damage the filesystem that way. The disk was still functioning properly. As far as I understand it the only problem was the beeping, and there were no other issues. After you hard rebooted the device, fb lost it's mounted disk and then went into emergency mode, which was to remount the disk read-only. It didn't understand what was going on, only that the disk seemed to disappear and the reappear. This was then what caused the problems. It was not the beeping, it was the restarting the RAID that was mounted on fb. Computers are not like regular pieces of hardware. You can't just yank the power on them. Worse yet is yanking the power on a device that is connected to a computer. DON"T DO THIS UNLESS YOU KNOW WHAT YOU"RE DOING. If the device is a disk drive, then doing this is a sure-fire way to damage data on disk. 8292 Thu Mar 14 11:51:14 2013 JamieUpdateGeneralBeatbox upgraded with output whitening, reinstalled  Quote: I pulled the beatbox from the 1X2 rack so that I could try to hack in some output whitening filters. These are shamefully absent because of my mis-manufacturing of the power on the board. Right now we're just using the MON output. The MON output buffer (U10) is the only chip in the output section that's stuffed: The power problem is that all the AD829s were drawn with their power lines reversed. We fixed this by flipping the +15 and -15 power planes and not stuffing the differential output drivers (AD8672). It's possible to hack in some resistors/capacitors around U10 to get us some filtering there. It's also possible to just stuff U9, which is where the whitening is supposed to be, then just jump it's output over to the MON output jack. That might be the cleanest solution, with the least amount of hacking on the board. I modified the beatbox according to this plan. I stuffed the whitening filter stage (U9) as indicated in the schematic (I left out the C26 compensation cap which, according to the AD829 datasheet, is not actually needed for our application). I also didn't have any 301 ohm resistors so I stuffed R18 with 332 ohm, which I think should be fine. Instead of messing with the working monitor output that we have in place, I stuffed the J5 SMA connector and wired U9 output to it in a single-ended fashion (ie. I grounded the shield pins of J5 to the board since we're not driving it differentially). I then connected J5 to the I/Q MON outputs on the front panel. If there's a problem we can just rewire those back to the J4 MON outputs and recover exactly where we were last week. It all checks out: 0 dB of gain at DC, 1 Hz zero, 10 Hz pole, with 20 dB of gain at high frequencies. I installed it back in the rack, and reconnected X/Y ARM ALS beatnote inputs and the delay lines. The I/Q outputs are now connected directly to the DAQ without going through any SR560s (so we recover four SR560s). 8316 Wed Mar 20 14:44:47 2013 JamieUpdateOpticsupdated calculations of PRC/SRC g-factors and ARM mode matching Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings. These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates. I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics. An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big. We should considering flipping SR3 instead or SR2 when dealing with the SRC. I'll take responsibility for messing up the calculation for the flipped TTs. ### PRC  PR2 Reff PR3 Reff PRC g-factor (t/s) ARM mode matching Inf Inf .94/.94 .999 -600 -700 .99/.98 .84 413 (flipped) -700 .94/.93 .999 -600 409 (flipped) .92/.94 .999 413 (flipped) 409 (flipped) .87/.89 .97 ### SRC  SR2 Reff SR3 Reff SRC g-factor (t/s) ARM mode matching Inf Inf .96/.96 .999 -600 -700 NA NA 413 (flipped) -700 .96/.95 .998 -600 391 (flipped) .94/.96 .996 413 (flipped) 391 (flipped) .90/.92 .96 RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor. 8328 Thu Mar 21 13:50:08 2013 JamieUpdateLockingincident angles Is there a reason to use non-45 degree incident angles on the steering mirrors between the laser and the PD? I would always use 45 degree incident angles unless there is a really good reason not to. 8335 Mon Mar 25 11:42:45 2013 JamieUpdateComputersc1lsc mx_stream ok I'm not exactly sure what the problem was here, but I think it had to do with a stuck mx_stream process that wasn't being killed properly. I manually killed the process and it seemed to come up fine after that. The regular restart mechanisms should work now. No idea what caused the process to hang in the first place, although I know the newer RCG (2.6) is supposed to address some of these mx_stream issues. 8352 Tue Mar 26 11:33:55 2013 JamieUpdateOpticsHOWTO calculate effective RoC of flipped TT In case anyone is curious how I got the numbers for the effective radius of curvature of the flipped TT mirrors, I include the code below. Now you can calculate at home! Here's the calculation for the effective RoC of a flipped SR2 with nominal un-flipped HR RoC of -600: >> [Mt, Ms] = TTflipped(600, 5); >> M2Reff('t', Mt, 5) ans = 412.9652 >>    Attachment 1: mirror.m function [Mt, Ms] = mirror(R, a1, n) % [Mt, Ms] = mirror(R, a1, n) if length(R) > 1 Rt = R(1); Rs = R(2); else Rt = R; Rs = R; end  ... 9 more lines ... Attachment 2: transmission.m function [Mt, Ms] = transmission(R, a1, n1, n2) % [Mt, Ms] = transmission(R, a1, n1, n2) if length(R) > 1 Rt = R(1); Rs = R(2); else Rt = R; Rs = R; end  ... 19 more lines ... Attachment 3: TTflipped.m function [Mt, Ms] = TTflipped(R, a1) % [Mt, Ms] = TTflipped(R, a1) if length(R) > 1 Rt = R(1); Rs = R(2); else Rt = R; Rs = R; end  ... 32 more lines ... Attachment 4: M2Reff.m function Reff = M2Reff(type, M, a) % Reff = M2Reff('type', M, a) n = 1; R = -2*n/M(2,1); ca = cos(a*pi/180); switch lower(type)  ... 8 more lines ... 8355 Tue Mar 26 16:10:31 2013 JamieUpdate40m UpgradingETMY table leveling Steve's suggestion for how to level the end table using "swivel leveling mounts": 8374 Fri Mar 29 17:24:43 2013 JamieUpdateComputersFB RAID power supply replaced Steve ordered a replacement power supply for the FB JetStor power supply that failed a couple weeks ago. I just installed it and it looks fine. 8383 Mon Apr 1 16:24:09 2013 JamieFrogsLSCPD whitening switching fixed (loose connection at break-out box)  Quote: We discovered that the analog whitening filter of the REFL55_I board is not switching when we operate the button on the user interface. We checked with the Stanford analyzer that the transfer function always correspond to the whitening on. This turned out to just be a loose connection of the ribbon cable from Contec board in the LSC IO chassis at the BIO break-out box. The DSUB connector at the break-out box was not strain relieved! I reseated the connector and strain relieved it and now everything is switching fine. I wonder if we'll ever learn to strain relieve... 8400 Wed Apr 3 14:45:34 2013 JamieUpdateComputersupdated EPICS database (channels selected for saving)  Quote: I modified /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to include the C1:LSC-DegreeOfFreedom_TRIG_MON channels. These are the same channel that cause the LSC screen trigger indicators to light up. I vaguely followed Koji's directions in elog 5991, although I didn't add new grecords, since these channels are already included in the .db file as a result of EpicsOut blocks in the simulink model. So really, I only did Step 2. I still need to restart the framebuilder, but locking (attempt at locking) is happening. The idea here is that we should be able to search through this channel, and when we get a trigger, we can go back and plot useful signals (PDs, error signals, cotrol signals,....), and try to figure out why we're losing lock. Rana tells me that this is similar to an old LockAcq script that would run DTT and get data. EDIT: I restarted the daqd on the fb, and I now see the channel in dataviewer, but I can only get live data, no past data, even though it says that it is (16,float). Here's what Dataviewer is telling me: Connecting to NDS Server fb (TCP port 8088) Connecting.... done read(); errno=0 LONG: DataRead = -1 No data found read(); errno=9 read(); errno=9 T0=13-03-29-08-59-43; Length=432010 (s) No data output.  I seem to be able to retrieve these channels ok from the past: controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ tconvert 1049050000
Apr 03 2013 18:46:24 UTC
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$./general/getdata -s 1049050000 -d 10 --noplot C1:LSC-PRCL_TRIG_MON Connecting to server fb:8088 ... nds_logging_init: Entrynds_logging_init: Exit fetching... 1049050000.0 Hit any key to exit: controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$


Maybe DTT just needed to be reloaded/restarted?

8402   Wed Apr 3 15:00:24 2013 JamieSummaryElectronicsSorensen supplies in LSC rack (1Y2)

I investigated the situation of the two Sorensen supplies in the LSC rack (1Y2).  They are there solely to supply power to the LSC LO RF distribution box.  One is +18 V and the other is +28 V.  All we need to do is make a new longer cable with the appropriate plug on one end (see below), long enough to go from the bottom of the 1Y3 rack to the top of 1Y2, and we could move them over quickly.  Some sort of non-standard circular socket connector is used on the distribution box:

It could probably use thicker conduction wire as well.

If someone else makes the cable I'll move everything over.

8404   Wed Apr 3 17:40:18 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

I started to look into putting together a 110 MHz demod board to be used as POP110 (see #8399).

We have five spare old-skool EuroCard demod boards (LIGO-D990511).  From what I gather (see #4538, #4708) there are two modifications we do to these boards to make them ready for prime time:

• appropriate LP filter at PD RF input (U5 -> MC SCLF-*)
• swap out T1 transformer network with a commercial phase shifting power splitter (MC PQW/PSCQ)

#4538 also describes some other modifications but I'm not sure if those were actually implemented or not:

• removal of the attenuator/DC block/ERA-5 amp sections at the I/Q outputs
• swap ERA-5 amp with "Cougar"(?) amp at LO input.

What we'll need for a 110 demod:

I'll scrounge or order.

8407   Wed Apr 3 18:41:22 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

This SCPQ-150+, which is surface mount, might also work in place of the PSCQ-2-120, which is through-mount.  Would need to be reconciled with the board layout.

8415   Thu Apr 4 14:37:15 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

I'm having Steve order the following:

If you want him to add anything to the order let him know ASAP.

8431   Tue Apr 9 14:55:13 2013 JamieUpdateCDSoverbooked test points cause of DAQ problems

Folks were complaining that they were getting zeros whenever they tried to open fast channels in DTT or Dataviewer.  It turned out that the problem was that all available test points were in use in the c1lsc model:

There is a limit to how many test points can be open to a single model (in point of fact I think the limit is on the data rate from the model to the frame builder, not the actual number of open test points).  In any event, they was all used up.  The grid at the bottom right of the C1LSC GDS screen was all full of non-zeros, and the FE TRATE number was red, indicating that the data rate from this model had surpassed threshold.

The result of this overbooking is that any new test points just get zeros.  This is a pretty dumb failure mode (ideally one would not be able to request the TP at all with an appropriate error message), but it is what it is.  This usually means that there are too many dtt/dataviewers left with open connections.

We tried killing all the open processes that we could find that might be holding open test points, but that didn't seem to clear them up.  Stuck open test points is another known problem.  Referencing the solution in #6968 I opened the diag shell and killed all test points everywhere:

controls@pianosa:~ 0$diag -l -z Set new test FFT NDS version = 12 supported capabilities: testing testpoints awg diag> tp clear * * test point cleared diag> quit EXIT KERNEL controls@pianosa:~ 0$

8466   Fri Apr 19 15:19:25 2013 JamieUpdatePEMTrilliums moved from bench to concrete

I moved the two Trillium seismometers that Den left on the electronics bench out onto the new concrete blocks in the lab that will be their final resting places.  I moved one onto the slab at the vertex and the other to the slab at the Y end.  I left them both locked and just sitting on the concrete.

The pile of readout electronics that were sitting next to them I moved on to the yellow foam box half way down the MC tube, between the MC tube and the X arm tube.  This is obviously not a good place to store them, but I couldn't think of a better place to put them for the moment.

8524   Thu May 2 19:59:34 2013 JamieUpdateComputer Scripts / Programslookback: new program to look at recent past testpoint data

To aid in lock-loss studies, I made a new program called 'lookback', similar to 'getdata', to look at past data.

When called with channel name arguments, it runs continuously, storing all channel data in a ring buffer.  When the user hits Ctrl-C, all the data in the ring buffer is displayed.  There is an option to store the data in the ring buffer to disk as well.

controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$./lookback -h usage: lookback [-h] [-l LENGTH] [-o OUTDIR] channel [channel ...] Lookback on testpoint data. The specified amount of data is stored in a ring buffer. When Ctrl-C is hit, all data in the ring buffer is plotted. Both 'DQ' and 'online' test point data is available. Use NDSSERVER environment variable to specify host:port. positional arguments: channel Acquisition channel. Multiple channels may be specified and acquired at once. optional arguments: -h, --help show this help message and exit -l LENGTH, --lookback LENGTH Lookback time in seconds. This amount of data will be stored in a ring buffer, and plotted on Ctrl-C. Default is 10 seconds -o OUTDIR, --outdir OUTDIR Output directory to write data (will be created if it doesn't exist). Data from each channel stored as '<channel>.txt'. Any existing data files will be overwritten. controls@rosalba:/opt/rtcds/caltech/c1/scripts/general 0$

8530   Mon May 6 19:04:30 2013 JamieUpdateIOOmode cleaner not locking

About 30 minutes ago the mode cleaner fell out of lock and has since not been able to hold lock for more than a couple seconds.

I'm not sure what happened.  I was in the middle of taking measurements of the MC error point spectrum, which included adjusting the FAST gain.  I've put all the gains back to their nominal levels but no luck.  I'm not sure what else could have gone wrong.  Seismic noise looks relatively quiet.

8540   Tue May 7 17:43:51 2013 JamieUpdateComputers40MARS wireless network problems

I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

8541   Tue May 7 18:16:37 2013 JamieUpdateComputers40MARS wireless network problems

Here's an example of the total horribleness of what's happening right now:

controls@rossa:~ 0$ping 192.168.113.222 PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data. From 192.168.113.215 icmp_seq=2 Destination Host Unreachable From 192.168.113.215 icmp_seq=3 Destination Host Unreachable From 192.168.113.215 icmp_seq=4 Destination Host Unreachable From 192.168.113.215 icmp_seq=5 Destination Host Unreachable From 192.168.113.215 icmp_seq=6 Destination Host Unreachable From 192.168.113.215 icmp_seq=7 Destination Host Unreachable From 192.168.113.215 icmp_seq=9 Destination Host Unreachable From 192.168.113.215 icmp_seq=10 Destination Host Unreachable From 192.168.113.215 icmp_seq=11 Destination Host Unreachable 64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms 64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms ^C --- 192.168.113.222 ping statistics --- 35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11 controls@rossa:~ 0$


Note that 10 SECOND round trip time and 94% packet loss.  That's just beyond stupid.  I have no idea what's going on.

8542   Tue May 7 18:42:20 2013 JamieUpdatePSLPMC not locking

I'm just now realizing that the PMC has also not been locked since noon today, and doesn't seem to be responding to anything right now.

wtf is going on here?

8548   Wed May 8 16:10:09 2013 JamieUpdateCDSUnknown DAQ channels in c1sus c1x02 IOP?

Someone for some reason added full-rate DAQ specification to some ADC3 channels in the c1sus IOP model (c1x02):

#DAQ Channels

TP_CH15 65536
TP_CH16 65536
TP_CH17 65536
TP_CH18 65536
TP_CH19 65536
TP_CH20 65536
TP_CH21 65536


These appear to be associated with c1pem, so I'm guessing it was Den (particularly since he's the worst about making modifications to models and not telling anyone or logging or svn committing).

I'm removing them.

8549   Wed May 8 17:03:35 2013 JamieConfigurationCDSmake direct IPC connections between c1lsc and c1sus/c1mcs

Previously, for some reason, many IPC connections were routed through the c1rfm model, even if a direct IPC connection was possible.  It's unclear why this was done.  I spoke to Joe B. about it and he couldn't remember either.  Best guess is that it was just for book keeping purposes.  Or maybe some old timing issue that has been fixed by DMA fixes in the RTS.  So the point is that it's no longer needed, and we can reduce delays by making direct connections.

I made direct IPC connections from c1lsc to both c1sus and c1mcs, bypassing the c1rfm, through which they had previously been routed.  All models were rebuilt/installed/restarted and everything seems to be working fine.

ELOG V3.1.3-