40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 248 of 337  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  4590   Fri Apr 29 14:36:36 2011 josephb, steveUpdateCDSRemoved hanging D-sub to SCSI in 1X5

Quote:

Problem:

Way back, Jay had D-sub to SCSI adapters made to adapt our existing Sander box AA filters to the new SCSI based IO chassis.  However, these did not fit inside the box.

At the time, we simply left the cards outside hanging, which was a hack and needed to be replaced.

Solution:

Steve modified a black AA filter box so that it could fit the D-sub to SCSI adapter board on it, plus strain relief the SCSI cable, rather than let it hang.  The back of the box was cut, and an extending piece of metal attached to the bottom of the box.  The adapter board was screwed into the box, the SCSI plugged in, then the SCSI cable is clamped to the extending metal as well.

This modification will be propagated to the 3 remaining AA filter boards using the D-sub to SCSI adapter.

 The same modification was carried out at 1X5 for PRM & SRM.

Note:  D68L8EX-850Hz  are removed  and bypassed in 7 channels.

Attachment 1: P1070621.JPG
P1070621.JPG
  2940   Mon May 17 17:17:49 2010 josephb, steve, alberto, kiwamuUpdateCDSNew CDS computers now in racks.

We placed 3 new computers in the racks.  One in 1X4 (machine running SCX) and 2 in 1Y4 (LSC and SUS).  These are 1U chassis, 4 core machines for the CDS upgrade.  I will be bringing over 2 IO chassis and their rails over tomorrow, one to be placed in 1Y4, and 1 in 1X4.

We still need some more 40 pin adapter cables and will send someone over this week to make them.  However, once we have those, we should be able to get two to three machines going, one end computer/chassis and the SUS computer/chassis.

After tomorrow we are still going to be owed 1 computer, another dolphin fiber, a couple of blue boxes, and the LSC, IO, and Y end IO chassis.  We also realized we need further fiber for the timing system.  We're going to need to get and then run fiber to both ends, as well as to 1X3, where the LSC IO chassis will be.

 

  3906   Fri Nov 12 10:49:34 2010 josephb, valeraUpdateCDSTest of ADC noise

Test:

Look at the effects of the ADC voltage range on the ADC noise floor.

ADC input was terminated with 50 ohms.  We then looked at the channel with DTT. This was at +/- 10 V range.  We used C1:SUS-PRM_SDSEN_IN1 as the test channel.

The map.c file (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ ) then had two lines added at line 766.

//JCB temporary 2.5V test, remove me
  adcPtr[devNum]->BCR &= 0x84240;

This hard coded the 2.5 V range (we default to the 10 V range at the moment).

We then rebuilt the c1x02 model and reran the test.

Finally, we reverted the code change to map.c and rebuilt c1x02.

Results:
I've attached the DTT output of the two tests.

It appears the ADC is limited by 1.6 uV/rtHz.  Hence the increase in noise in counts by a factor of 4 when we drop to +/- 2.5 V from +/- 10 V.

Attachment 1: ADC_noise.pdf
ADC_noise.pdf
  4317   Thu Feb 17 22:51:04 2011 josephb, valeraSummary dither alignment model

We made a model for the dither angular stabilization system c1ass.mdl. The attached file shows the diagram.

The idea is to dither a combination of 6 optics (ETMs, ITMs, PZTs) at different frequencies and demodulate three PDs (TRX, TRY, REFL11I). Then form the DOFs from demodulted signals, filter, and send each DOF to a combination of optics.

This is enough to get started with arm cavities alignment (we may need to add the BS for the Y arm). More optics and PD can be added as they become available and/or needed.

The DAC for the fast PZT  are not connected and have to be commissioned.

Attachment 1: ass-model.png
ass-model.png
  4325   Fri Feb 18 17:52:25 2011 josephb, valeraUpdateCDSc1ass updated

We updated the c1ass model to include the BS.  We removed the dither excitation of the PZTs.  PZT control goes to epics. To do this, modified the /cvs/cds/caltech/target/c1iscaux/PZT_AI.db file.  We basically have it sum both the existing epics slider and our new output from c1ass.

More importantly we updated the color scheme.

We compiled and tested the Dolphin and RFM which work.

I should note we can't figure out why testpoints are not working properly with just this model.  Alex and Joe spent well over an hour trying to debug it to no success.  Current workaround is to add what channels you want from c1ass to the DAQ recording.  Other testpoints on other models appear to be working.

Attachment 1: c1ass_updated.png
c1ass_updated.png
  3652   Tue Oct 5 16:30:00 2010 josephb, yutaHowToCDSScreen settings and medm screens for new system

You can find the sitemap medm screen in

/opt/rtcds/caltech/c1/medm/master

The settings for the screens were last saved by burt in the original system on Sept 29, 2010 at 11:07.  So go to the

/cvs/cds/caltech/burt/autoburt/snapshots/2010/Sep/29/11:07

directory.  You can grep for the channels in the files in this directory.

You can also then use the autoBurt.req file in the /opt/rtcds/caltech/c1/target/sysname/sysnameepics (c1sus/c1susepics) to backup the settings entered.  Save to the /opt/rtcds/caltech/c1/target/snapshots directory for now.

 

 

  3653   Tue Oct 5 16:58:41 2010 josephb, yutaUpdateCDSc1sus front end status

We moved the filters for the mode cleaner optics over from the C1SUS.txt file in /opt/rtcds/caltech/c1/chans/ to the C1MCS.txt file, and placed SUS_ on the front of all the filter names.  This has let us load he filters for the mode cleaner optics.

At the moment, we cannot seem to get testpoints for the optics (i.e. dtt is not working, even the specially installed ones on rosalba). I've asked Yuta to enter in the correct matrix elements and turn the correct filters on, then save with a burt backup.

  3658   Wed Oct 6 11:03:51 2010 josephb, yutaHowToCDSHow to start diaggui for right now

I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

 

 

  3662   Wed Oct 6 16:16:48 2010 josephb, yutaUpdateCDSc1sus status

At the moment, c1sus and c1mcs on the c1sus machine seem to be dead in the water.  At this point, it is unclear to me why.

Apparently during the 40m meeting, Alex was able to get test points working for the c1mcs model.  He said he "had to slow down mx_stream startup on c1sus".   When we returned at 2pm, things were running fine. 

We began updating all the matrix values on the medm screens.  Somewhere towards the end of this the c1sus model seemed to have crashed, leaving only c1x02 and c1mcs running.  There were no obvious error messages I saw in dmesg and the target/c1sus/logs/log.txt file (although that seems to empty these days).  We quickly saved to burt snap shots, one of c1sus and one of c1mcs and saved them to /opt/rtcds/catlech/c1/target/snapshots directory temporarily.  We then ran the killc1sus script on c1sus, and then after confirming the code was removed, ran the startup script, startc1sus.  The code seemed to come back partly.  It was syncing up and finding the ADC/DAC boards, but not doing any real computations.  The cycle time was reporting reasonably, but the usr time (representing computation done for the model) was 0.  There were no updating monitor channels on the medm screens and filters would not turn on.

At this point I tried bringing down all 3 models, and restarting c1x02, then c1sus and c1mcs.  At this point, both c1sus and c1mcs came back partly, doing no real calculations.  c1x02 appears to be working normally (or at least the two filter banks in that model are showing changing channels from ADCs properly).  I then tried rebooting the c1sus machine.  It came back in the same state, working c1x02, non-calculating c1sus and c1mcs.

  3666   Thu Oct 7 10:48:41 2010 josephb, yutaUpdateCDSc1sus status

This problem has been resolved.

Apparently during one of Alex's debugging sessions, he had commented out the feCode function call on line 1532 of the controller.c file (located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ directory).

This function is the one that actually calls all the front end specific code and without it, the code just doesn't do any computations.  We had to then rebuild the front end codes with this corrected file.

Quote:

At the moment, c1sus and c1mcs on the c1sus machine seem to be dead in the water.  At this point, it is unclear to me why.

Apparently during the 40m meeting, Alex was able to get test points working for the c1mcs model.  He said he "had to slow down mx_stream startup on c1sus".   When we returned at 2pm, things were running fine. 

We began updating all the matrix values on the medm screens.  Somewhere towards the end of this the c1sus model seemed to have crashed, leaving only c1x02 and c1mcs running.  There were no obvious error messages I saw in dmesg and the target/c1sus/logs/log.txt file (although that seems to empty these days).  We quickly saved to burt snap shots, one of c1sus and one of c1mcs and saved them to /opt/rtcds/catlech/c1/target/snapshots directory temporarily.  We then ran the killc1sus script on c1sus, and then after confirming the code was removed, ran the startup script, startc1sus.  The code seemed to come back partly.  It was syncing up and finding the ADC/DAC boards, but not doing any real computations.  The cycle time was reporting reasonably, but the usr time (representing computation done for the model) was 0.  There were no updating monitor channels on the medm screens and filters would not turn on.

At this point I tried bringing down all 3 models, and restarting c1x02, then c1sus and c1mcs.  At this point, both c1sus and c1mcs came back partly, doing no real calculations.  c1x02 appears to be working normally (or at least the two filter banks in that model are showing changing channels from ADCs properly).  I then tried rebooting the c1sus machine.  It came back in the same state, working c1x02, non-calculating c1sus and c1mcs.

 

  3668   Thu Oct 7 14:57:52 2010 josephb, yutaUpdateCDSc1sus status

Around noon, Yuta and I were trying to figure out why we were getting no signal out to the mode cleaner coils.  It turns out the mode cleaner optic control model was not talking to the IOP model. 

Alex and I were working under the incorrect assumption that you could use the same DAC piece in multiple models, and simply use a subset of the channels.  He finally went and asked Rolf, who said that the same DAC simulink piece in different models doesn't work.  You need to use shared memory locations to move the data to the model with the DAC card.  Rolf says there was a discussion (probably a long while back) where it was asked if we needed to support DAC cards in multiple models and the decision was that it was not needed.

Rolf and Alex have said they'd come over and discuss the issue.

In the meantime, I'm moving forward by adding shared memory locations for all the mode cleaner optics to talk to the DAC in the c1sus model.

 

Note by KA: Important fact that is worth remembering

  3706   Wed Oct 13 17:04:34 2010 josephb, yutaUpdateCDSburt restore now working with filter settings

Previously, burt restoring was not setting filters on and off, which was required us to constantly go through all the filter banks and turn them on.  We figured it out that the autoBurt.req file doesn't seem to be setup to restore those values, so that snapshots made with the default .req file don't restore either.

So I went to each of the suspension directories (/opt/rtcds/caltech/c1/target/c1SYS/c1SYSepics/   where SYS is sus, mcs, or rms) and modified teh autoBurt.req files found there with the following incantation:

sed -i 's/RO \(.*SW[12]R.*\)/\1/' autoBurt.req

This removes the RO at the beginning of the lines which have SW1R or SW2R in them.  These are the channels which correspond to filter bank switches.  As far as I can tell, the RO means to leave it alone.  Unfortunately, I didn't see an obvious autoBurt file specification in the DCC or on google in the 2 minutes I took to look for it.

We need to talk to Alex to figure out how that autoBurt.req file is generated and get it so it doesn't default to not restoring filter bank settings.

  3707   Wed Oct 13 17:12:33 2010 josephb, yutaUpdateCDSFilter name length problem found and fixed

The missing filter files for ULPOS, URPOS, and so forth for the mode cleaner optics was due to the length of the names of the filters. 

This was not a problem for the c1sus model because it was using its own name as the first 3 letters of its designation.  A filter for the sus model would be called something like BS_TO_COIL_MTRX_0_0, while for the mcs it would be called SUS_MC1_TO_COIL_MTRX_0_0, an extra 4 characters.

However, the c1mcs model used the "top_name" feature which uses a subsystem box within the simlink model to rename all the channels.  Apparently in the filter file, this means it has to add the top name to the front of everything, adding an additional 3 characters.  This pushed things over the length limit.

A hard cap of 18 characters has been added to the FiltMuxMatrix.pm file (located in /cvs/cds/caltech/c1/, so that it will prevent this type of problem in the future by stopping at compile time and presenting a helpful error message.

I also fixed a bug with too many spaces in the feCodeGen.pl file when dealing with top_names and the filtMuxMatrix.pm preventing some .adl files from being generated.

Also of interest, MC3 appears to never have had F2A filters.  For the moment we're running without them, but since they're just a fine tuning it shouldn't affect locking tonight.

 

Improbability factor of mode cleaner suspensions working tonight: ~20

 

  3797   Wed Oct 27 15:38:19 2010 josephb, yutaUpdateCDSIO chassis with bad timing was taken back to Downs

Problem:

The front end timing was not working properly for 2 of the IO chassis.  They were not being synced to the 1 PPS signal. 

This prevented the use of RFM for communication between front ends because time stamps on the transmitted data did not match the cycle on the receiving machine.

Action:

We took one of the incorrectly working chassis over to Downs.  Rolf said he would take a look at it tomorrow morning.

Joe will be going over tomorrow morning to talk with Rolf and see what needs to be done to fix it.

 

  3821   Fri Oct 29 11:25:15 2010 josephb, yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Problem:

Missing daqd file, i.e. the framebuilder executable.

Solution:

1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/

2) Look in the Makefile for a likely build suspect.  In this case it was build dc, which stands for data concentrator.

3) So we ran "make dc"

4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory

5) Test it to ensure we're getting channels (Yay!)

Future Safeguards:

Place the new target directory under SVN control.

 

  3845   Tue Nov 2 13:51:40 2010 josephb, yutaUpdateCDSRFM slowdown problem

Problem:

Each RFM memory location which needs to be read by a front end model slows the model significantly.

With no RFM memory locations to be read (replaced with grounds), the c1mcs model runs around 25 microseconds per cycle.

With 1 RFM memory location (MC_L), it runs around 29-33 microseconds.

With 3 RFM memory locations (MC_L, MC1_PIT, MC1_YAW), it runs around 45 microseconds.

With 7 RFM memory locations, the code generally doesn't run at all, going past the 62 microsecond maximum required to be able to keep up with the 16 kHz sample rate.

Last night Yuta somehow got it running with 7 RFM memory locations, but in that case, all the odd numbered RFM channels (1,3,5 as counted by the ipc file) did not work.  It was running at around 55 microseconds in that case.

The c1ioo code which is writing the data to the RFM card is experiencing no such slow down.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
                     ... 
  3861   Thu Nov 4 15:27:33 2010 josephb, yutaUpdateCDSc1ioo test points not working

Problem:

We can't access any of the c1ioo computer testpoints.  Dataviewer and DTT both fail to read any data from them.

According to diag -l (when run on Rosalba in /opt/apps), the testpoints are not being set.  Also at some point during the day when debugging, we also somehow messed up all the front end connections to the framebuilder.

Errors reported by dataviewer:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek
Server error 12: no such net-writer
read(); errno=0
Server error 6532: invalid channel name
Server error 16080: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Error reported by daqd.log:

[Thu Nov  4 13:29:35 2010] About to request `C1:IOO-MC1_PIT_IN1' 10022
on node 34
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10022; tp[1]=32531

[Thu Nov  4 13:29:35 2010] About to request `C1:SUS-MC2_SUSPOS_IN1'
10094 on node 36
[Thu Nov  4 13:29:35 2010] Requesting 1 testpoints; tp[0]=10094; tp[1]=32531

[Thu Nov  4 13:29:38 2010] ETIMEDOUT: test point `C1:IOO-MC1_PIT_IN1'
(tp_num=10022) was not set by the test point manager; request failed
[Thu Nov  4 13:29:38 2010] About to clear `C1:IOO-MC1_PIT_IN1' 10022 on node 34

Attempted Fixes:

Remove all daq related files: /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1ioo.par and /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini.  Rebuilt the front end code.

Double checked ethernet connection between c1ioo and the daq router and fb. 

Confirmed open mx was running on c1ioo. Confirmed awgtpman was running (although at one point I did find duplicate awgtpman running for c1x03, the IOP associated with c1ioo).

Rebooted the c1ioo machine. Confirmed all necessary codes came back.

Restarted the daqd process several times on the fb machine.

Current Status:

Framebuilder is running, and c1sus testpoints are available.  c1ioo test points are not.  Waiting to hear back from Alex on possible ideas.

  3880   Mon Nov 8 14:30:15 2010 josephb, yutaUpdateCDSAdded LIGONDSIP setting to cshrc.40m

We added the following line to the cshrc.40m file in the 64-bit linux and 32-bit linux sections:

setenv LIGONDSIP fb

This allows codes like tdsdmd to work properly on the linux machines (seemed to already work fine on the solaris op440m without this change).

  3946   Thu Nov 18 14:05:06 2010 josephb, yutaUpdateCDSc1sus is alive!

Problem:

We broke c1sus by moving ADC cards around.

Solution:

We pulled all the cards out, examined all contacts (which looked fine), found 1 poorly connected cable internally, going between an ADC and ADC timing interface card  (that probably happened last night), and one of the two RFM fiber cables pulled out of its RFM card.

We then placed all of the cards back in with a new ordering, tightened down everything, and triple checked all connections were on and well fit.

 

Gotcha!

Joe forgot that slot 1 and slot 2 of the timing interface boards have their last channels reserved for duotone signals.  Thus, they shouldn't be used for any ADCs or DACs that need their last channel (such as MC3_LR sensor input).  We saw a perfect timing signal come in through the MC3_LR sensor input, which prevented damping. 

We moved the ADC timing interface card out of the 1st slot  of the timing interface board and into slot 6 of the timing interface board, which resolved the problem.

Final Configuration:

 

 Timing Interface Board

Timing Interface Slot 1 (Duotone) 2 (Duotone) 3 4 5 6 7 8 9 10 11 12 13
Card None DAC interface (can't use last channel) ADC Interface ADC interface ADC interface

ADC

interface

None None None DAC interface DAC interface None None

 PCIe Chassis

Slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
PCIe Number Do Not Use 1 6 5 4 9 8 7 3 2 14 13 12 17 16 15 11 10
Card None ADC DAC ADC ADC ADC BO BO BO BO DAC DAC BIO RFM None None None None

Still having Issues with:

ITM West damps.  ITM South damps, but the coil gains are opposite to the other optics in order to damp properly.

We also need to look into switching the channel names for the watchdogs on ITMX/Y in addition to the front end code changes.

  3659   Wed Oct 6 12:00:23 2010 josephb, yuta, kiwamuUpdateCDSFound and fixed filter sampling rate problem with suspensions

While we looking using dtt and going over the basics of its operation, we discovered that the filter sample rates for the suspensions were still set to 2048 Hz, rather than 16384 Hz which is the new front end.  This caused the filters loaded into the front ends to not behave as expected.

After correcting the sample rate, the transfer functions obtained from dtt are now looking like the bode plots from foton.

We fixed the C1SUS.txt and C1MCS.txt files in the /opt/rtcds/caltech/c1/chans/ directory, by changing the SAMPLING lines to have 16384 rather than 2048.

  3911   Fri Nov 12 20:40:51 2010 josephb, yuta, valeraConfigurationElectronicsAA voltage range

We changed the range of the two SUS AA boards in the corner from +/-2 V to +/-10 V by changing the supply voltage from +/-5 V to +/-15 V. The change was made by switching the AA power feed wires on  the cross connect. The max supply according to the spec of DRV134/INA134 is +/-18 V.

We checked the new range by applying the voltage to the input of AA and measuring the output going to the ADCs. The local damping MC1,2,3 appears to work.

  1574   Mon May 11 12:25:03 2009 josephb,AlexUpdateComputersfb40m down for patching

The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB).  This process is expected to take several hours, during which the frame builder will be unavailable.

  2212   Mon Nov 9 13:22:08 2009 josephb,alexUpdateComputersMegatron update

Alex and I took a look at megatron this morning, and it was in the same state I left it on Friday, with file system errors.  We were able to copy the advLIGO directory Peter had been working in to Linux1, so it should be simple to restore the code.  We then tried just running fsck, and overwritting bad sectors, but after about 5 minutes it was clear it could potentially take a long time (5-10 seconds per unreadable block, with an unknown number of blocks, possibly tens or millions).  The decision was made to simply replace the hard drive.

Alex is of the opinion that the hard drive failure was a coincidence.  Or rather, he can't see how the RFM card could have caused this kind of failure.

Alex went to Bridge to grab a usb to sata adapter for a new hard drive, and was going to copy a duplicate install of the OS onto it, and we'll try replacing the current hard drive with it.

  2967   Fri May 21 14:31:46 2010 josephb,alexUpdateCDSNew computer and IO chassis working in 1X4

Alex brought over a ADC, DAC, and PCIe card which goes into the computer and talk to the IO chassis.  We tried installing the new "small" IO chassis in 1X4, but initially it couldn't find the ADC/DAC boards, just the Contec Binary out board.

We tried several different configurations (different computer, different IO chassis, the megatron chassis, the megatron IO chassis with new cards, a new IO chassis with megatron cards.

The two things were concluded once we got a new IO chassis talking with the new computer. 

1) Its possible one of the slots is in the IO chassis as we didn't see the ADC until we moved it to a different slot in the new chassis

2) The card that Alex had brought over to put in the computer doesn't behave well with these IO chassis.  He went back to downs to try and figure out what it is, and test it with the chassis over there.

Currently, Megatron's IO chassis is sitting on a table behind racks 1Y5 and 1Y6, along with the new "large" IO chassis.  Megatron's PCIe card for talking to the IO chassis was moved to the computer in 1X4.  The computer in 1X4 is currently being called c1iscex with IP 192.168.113.80. 

  3034   Wed Jun 2 11:25:16 2010 josephb,alexUpdateCDSCDS saga (aka the bad code saga)

Alex updated the awg.par file to handle all the testpoints.  Basically its very similar to the testpoint.par, but the prognum lines have to be 1 higher than the corresponding prognum in testpoint.par.  A entry looks like:

[C1-awg0]
hostname=192.168.1.2
prognum=0x31001002

After running "diag -i" and seeing some RPC number conflicts, we went into /cvs/cds/caltech/cds/target/gds/param/diag_C.conf and changed the line from

&chn * *  192.168.1.2 822087685 1

to

&chn * *  192.168.1.2 822087700 1

The number represents an RPC number.  This was conflicting with the RPC number associated with the awgtpman processes.  We then had to update the /etc/rpc file as well.  At the end we changed chnconf 822087685 to chnconf 822087700.  We then run /usr/sbin/xinetd reload

Lastly we edited the /etc/xinetd.d/chnconf file line

server_args             = /cvs/cds/caltech/target/gds/param/tpchn_C4.par /cvs/cds/caltech/target/gds/param/tpchn_C5.par

to

server_args             = /cvs/cds/caltech/target/gds/param/tpchn_C1.par /cvs/cds/caltech/target/gds/param/tpchn_C2.par /cvs/cds/caltech/target/gds/param/tpchn_C3.par /cvs/cds/caltech/target/gds/param/tpchn_C4.par /cvs/cds/caltech/target/gds/param/tpchn_C5.par /cvs/cds/caltech/target/gds/param/tpchn_C6.par /cvs/cds/caltech/target/gds/param/tpchn_C7.par /cvs/cds/caltech/target/gds/param/tpchn_C8.par /cvs/cds/caltech/target/gds/param/tpchn_C9.par

 

Alex also recompiled the frame builder code to be able to handle more than 7 front ends.  This involved tracking down a newer version of libtestpoint.so on c1iscex and moving it over to megatron, then going in and by hand adding the ability to have up to 10 front ends connected.

Alex has said he doesn't like this code and would like it to dynamically allocate properly for any number of servers rather than having a dumb hard coded limit.

Other changes he needs to make:

1) Get rid of set dcu_rate ## = 16384 type lines in the daqrc file.  That information is available from the /caltech/chans/C1LSC.ini type files which are automatically generated when you compile a model.  This means not having to go in by hand to update these in daqrc.

2) Get some awg.par and testpoint.par rules, so that these are automatically updates when you build a model.  Make it so it automatically assigns a prognum when read in rather than having to hard code them in by hand.

3)Slave the awgtpmans to a single clock running from the IO processor x00. This ensures they are all in sync.

 

 

 

  3632   Fri Oct 1 10:56:30 2010 josephb,alexUpdateCDSfb work continued

Alex fixed the time issue with the IRIG-B signal being far off, apparently their IRIG-B signal in downs seems to be different.  He simply corrected for the difference in the two signals in the code.

For debugging purposes we uncommented the following line in the feCodeGen.pl script (in /opt/rtcds/caltech/c1/advLigoRTS/src/epics/util/):

print EPICS "test_points ONE_PPS $dac_testpoint_names $::extraTestPoints\n" 

This is to make every ADC testpoint available from the IOP (such as c1x02).

  2540   Thu Jan 21 17:23:30 2010 josephb,alex,kojiHowToComputersRCG code fixes

In order to see the Contec DO-32L-PE Digital output PCIe card with the new controls, we had to add the CDO32 part to the CDS_PARTS.mdl file in control /cds/advLigo/src/epics/simLink/ directory on megatron, as well as create the actual model mdl file (based on cdsDio.mdl) in the control/cds/advLigo/src/epics/simLink/lib directory. 

The CDO32.pm file (in /home/controls/cds/advLigo/src/epics/util/lib) has existed for some time, it was just missing the associated pieces in simlink.  However, Alex also checked out a newer version Dio.pm in the process.  As we are not using this part at this time, it should be fine.

The code now compiles and sees the digital output card.

You need a special care on this block as it turned out that the code does not compiled if the "constant" block is connected to the input. You must use appropriate block such as bitwise operator, as shown below.

Attachment 1: CDO32.png
CDO32.png
  2695   Mon Mar 22 16:57:45 2010 josephb,daisuke, alexConfigurationComputersMegatron test points working again

We changed the pointer on /cvs/cds/caltech/target/gds/bin/awgtpman from

/opt/gds/awgtpman    to

/cvs/cds/caltech/target/gds/bin/awgtpman.091215.

Then killed the megatron framebuilder and testpoint manager (daqd, awgtpman), restarted, hit the daq reload button from the GDS_TP screen. 

This did not fix everything. However, it did seem to fix the problem where it needed a rtl_epics under the root directory which did not exist.  Alex continued to poke around.  When next he spoke, he claimed to have found a problem in the daqdrc file.  Specifically, the cvs/cds/caltech/target/fb/ daqdrc file.

set gds_server = "megatron" "megatron" 10 "megatron" 11;

He said this need to be:

set gds_server = "megatron" "megatron"  11 "megatron" 12;


However, during this, I had looked file, and found dataviewer working, while still with the 10 and 11.  Doing a diff on a backup of daqdrc, shows that Alex also changed

set controller_dcu=10  to set controller_dcu=12, and commented the previous line. 

He also changed set debug=2 to set debug=0.

In a quick test, we changed the 11 and 12 back to 10 and 11, and everything seemed to work fine.  So I'm not sure what that line actually does.  However, the set controller_dcu line seems to be important, and probably needs  to be set to the dcu id of an actually running module (it probably doesn't matter which one, but at least one that is up).  Anyways, I set the gds_server line back to 11 and 12, just in case there's numerology going on.

I'll add this information to the wiki.

  3237   Fri Jul 16 15:57:19 2010 josephb,kiwamuUpdateComputersNew X end FE and IO chassis work

We finished setting up the new X end front end machine (still temporarily called c1scx), and attached it to its IO chassis.  We're preparing for a test tomorrow, where we redirect the Limo breakout box to the new front end and IO chassis, so Kiwamu can test getting some green locking channels into his controls model.

We strung a pair of blue fibers from the timing master to the new X end (and labeled them), so we have a timing signal for the IO chassis.  I also labeled the orange fiber Alex had repurposed from the RFM to timing for the new Y end when I noticed he had not actually labelled it at the timing master.

  3434   Wed Aug 18 12:24:58 2010 josephb,kiwamuUpdateCDSshmem issue

Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it.  We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.

The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).

  3432   Wed Aug 18 11:40:59 2010 josephb,kiwamu,yoichiUpdateCDSEnd station working with latest RCG code

We were able to get the latest SVN checkout (revision 2009), working with the c1x00 (IOP) and c1vgl models at the new X end on the c1iscex machine.

We were unable to get it working yesterday, and as far as we can tell, the only significant change was a reboot of the c1sus machine.  Before the reboot, it did not look like there were any conflicting models running on the c1sus machine, but apparently something was preventing the models on c1iscex from running properly.

Other simulated plant models still need to have their shared memory location blocks updated to the new type.

Now that we have proved we still can get the end model running, we are moving onto the c1sus machine.

  2517   Fri Jan 15 18:53:05 2010 josephb,peter,kojiUpdateComputersAttempted locking with Megatron replacing ETMY front end

This afternoon we attempted to lock the interferometer using Megatron insteady of the usual ETMY front end.

We attempted it once, found the alignment seemed particularly bad, then realized we had forgotten to add the QPDs.  In the process of adding the QPDs to the tst.mdl file, we realized I (Joe) should have been looking at the iscNetDsc.h file, not the iscNetDs40m.h file for the RFM memory structure.  The only major difference was the memory location of where the qpd information gets passed.

We added QPDs to the tst.mdl file, writing to the RFM network with the QPD pitch, yaw and sum values.

We also added normalization to the oplev, by dividing the OL pitch and yaw values by the OL sum value in the tst.mdl file.

The lscPos, ascPit, ascYaw were working properly, although we did have to poke at the ascPit and ascYaw values once before they started reading properly at Megatron (they started at -1e20).  We think the RFM card may have started in an odd state, and without something causing the ascPit and ascYaw values to change, it never updated.

At the end of the day, the interferometer was locked for a few seconds.  There is are still some issues to be worked on, but its progress.

Koji returned everything back to normal operations after the test.

  2911   Tue May 11 16:38:16 2010 josephb,rana,rolfUpdateCDSCDS questions and thoughts

1) What is c1asc doing?  What is ascaux used for?  What are the cables labeled "C1:ASC_QPD" in the 1X2 rack really going to?

2) Put the 4600 machine (megatron) in the 1Y3 (away from the analog electronics)  This can be used as an OAF/IO machine.  We need a dolphin fiber link from this machine to the IO chassis which will presumably be in 1Y1, 1Y2 (we do not currently have this fiber at the 40m, although I think Rolf said something about having one).

3) Merge the PSL and IOOVME crates in 1Y1/1Y2 to make room for the IO chassis.

4) Put the LSC and SUS machines into 1Y4 and/or 1Y5 along with the SUS IO chassis.  The dolphin switch would also go here.

5) Figure out space in 1X3 for the LSC chassis.  Most likely option is pulling asc or ascaux stuff, assuming its not really being used.

6) Are we going to move the OMC computer out from under the beam tube and into an actual rack?  If so, where?

 

Rolf will likely be back Friday, when we aim to start working on the "New" Y end and possibly the 1X3 rack for the LSC chassis.

 

  303   Fri Feb 8 17:55:53 2008 joshConfigurationPEMPEM-AS_MIC now in PSL enclosure
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.

Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam.
  780   Fri Aug 1 11:51:15 2008 justingOmnistructureComputersadded /cvs/cds/site directory
I added a /cvs/cds/site directory. This is the same as is dicsussed here. Right now it just has the text file 'cit' in it, but eventually the other scripts should be added. I'll probably use it in the next version of mDV.
  298   Tue Feb 5 17:39:05 2008 jweinerConfigurationPEMPEM-AS_MIC taken down from AS table, will put in PSL enclosure soon
I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.
  4772   Tue May 31 14:29:00 2011 jzweizigUpdateCDSframes

There seems to be something strange going on with the 40m frame builder.
Specifically, there is a gap in the frames in /frames/full near the start of
each 100k second subdirectory. For example, frames for the following times are missing:

990200042-990200669
990300045-990300492
990400044-990400800
990500032-990500635
990600044-990600725
990700037-990700704
990800032-990800677
990900037-990900719


To summarize, after writing the first two frames in a data directory, the next ~10 minutes of frames are usually missing. To make matters worse (for
the nds2 frame finder, at least) the first frame after the gap (and all successive frames) start at an arbitrary time, usually not aligned to a 16-second boundary. Is there something about the change of directories that is causing the frame builder to crash? Or is the platform/cache disk too slow to complete the directory switch-over without loss of data?

  4407   Sun Mar 13 00:00:58 2011 jzweizig, ranaConfigurationDAQNDS2 code change and restart

 John has changed the NDS2 code and restarted it on Mafalda. The issue is that it goes off the rails everytime the DAQD is restarted on FB because of filename convention war between GDS and CDS.

Until this is resolved, please make sure to restart the NDS2 process on Mafalda everytime you restart DAQD by doing this:

pkill -KILL nds2

/users/jzweizig/nds2-mafalda/start_nds2

  10711   Thu Nov 13 22:52:48 2014 kateUpdatePEMSeismometers set up for huddle test

Jenne, Diego, Kate

We want to conduct a huddle test with the three 40m seismometers (2 Guralps and 1 Trillium), so we began to get that set up in order. All three are currently sitting on the large granite slab approximately halfway down the length of the MC tube. We had to move all three seismometers: the Trillium had been next to the BS and the Guralps at the end stations. All three are balanced and aligned and we have put the foam box over them. 

The Trillium has not yet been used here, so we had to first wire its power supply. We're now providing its readout box with +/- 20 V. Getting that hooked up required powering down several electronics racks, which involved auxiliary prep work like turning off the suspension watchdogs. We also installed 3 new BNC cables to carry the Trillium x,y,z signals from its box to the CDS AA board. We're using the inputs which had previously been used for recording the STS2 signals. 

We could find only one of the two 'short' Guralp cables, so at the moment just one of the two Guralps is powered and connected to CDS. Jenne made (some time ago) new cables so that we could leave the long cables that run from the corner to each end station in place to preserve the nominal setup. 

Attachment/edit by Jenne: Seismic spectra.  Note that the T240 is connected to the channels that are called STS_1.  I compared the Guralp spectra to our seismic_ref, and they match up pretty well.  The new spectra is maybe a factor of 2 or so above the reference, at a few Hz. Anyhow, the Guralp seems fine.  I am sure that somewhere we have a second short (as in, not 50m long) Guralp cable, I just can't remember right now where it might be.  Also, the T-240 has some seriously crazy noise up around 30Hz.  What's up with that??  I want to ask Zach if he saw this when he had the Trillium, or if it is new.

Seismic_13Nov2014.pdf

Attachment 2: seism_closed.jpg
seism_closed.jpg
Attachment 3: seism_open.jpg
seism_open.jpg
  13866   Fri May 18 19:10:48 2018 keerthanaUpdateGeneralCode for adjusting the oscillator frequency remotly

Target: Phase locking can be acheived by giving a scan to the oscilator frequency. This frequency is now controlled using the knobe on the AM/FM signal generator 2023B. But we need to control it remotely by giving the inputs of start frequency, end frequency and the steps.

The frequency oscilator and the computer is connected with the help of GPIB Ethernet converter. The IP address of the converter I used is '192.168.113.109' and its GPIB address is 10.

I could change the oscilator frequency by changing the input frequency with the help of the code I made (Inorder to check this code, I have changed the oscilator frequency multiple times. I hope it didn't create trouble to anyone). Now I am trying to make this code better by adding certain features like numpy, argument parse etc, which I will be able complete by next week. I am also considering to develop the code to have a sliding system to control the oscillatory frequency.

For record: The maximum limit of frequency which i changed upto is 100MHz.

 

Attachment 1: frequency_set.jpg
frequency_set.jpg
  13875   Mon May 21 18:02:55 2018 keerthanaUpdateGeneralTesting of the new mini-circuits frequency counter

Today, I tested the new mini-circuit frequency counter by connecting it with the beat signal output. The frequency counter works fine. Now I am trying to get a display of the frequency in the computer screen using python programming. I have made the code for remotely changing oscilator frequency and it is saved in the folder 'ksnair'. A picture of the new mini circuits frequency counter is attached below. Part no: UFC-6000, S/N: 11501040012, Run: M075270.

Attachment 1: frequency_counter.jpg
frequency_counter.jpg
  13879   Tue May 22 17:29:27 2018 keerthanaUpdateelogMEDM Diagram for the auxilary laser system control and display.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

Attachment 1: MEDM_aux.png
MEDM_aux.png
  13915   Mon Jun 4 19:41:01 2018 keerthanaUpdate Finesse code for cavity scan

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

Attachment 1: Fig1.png
Fig1.png
Attachment 2: Fig2.png
Fig2.png
  13924   Thu Jun 7 10:26:36 2018 keerthanaUpdatePSLobserving the resonance signal corresponding to the injected frequency.

(Johannes, Koji, Keerthana)

The PLL loop ensures that the frequency difference between the PSL laser and the AUX laser is equal to the frequency we provide to the Local Oscillator (LO) with the help of a Marconi. Only a small pick off part of both the AUX and PSL lasers are going to the PLL loop. The other part of both the lasers are going to the interferometer. Before entering into the optical fibre, the AUX laser passes through an AOM which changes its frequency by an amount of 80MHz. When the PLL is locked, the frequency coming out of the PLL will be equal to the frequency set up in the Marconi (fm). When it passes through AOM, the frequency becomes fdiff = fm ±80 MHz. If this frequency beam and the PSL laser beam is aligned properly, and if this frequency is equal to the product of an integer and the free spectral range of the cavity, this will resonate in the cavity.  Then we expect to get a peak in the ETM transmission spectrum corresponding to the frequency we injected through the optical Fibre.

Through out the experiment we need to make sure that the PSL is locked. Thus, the signal detected by the photo detector when only PSL is resonating inside the cavity, act as a DC signal. Then we give a narrow scan to the Marconi. When fdiff = N*FSRy this condition is satisfied, we will observe a peak in the output. Here FSRy  is the free spectral range of the cavity which is approximately equal to 3.893 MHz.

Yesterday afternoon, Johannes, Koji and myself tried to observe this peak. We aligned the cavity by observing the output signal from the AS100 photo detector. We made the alignment in such a way that the intensity output getting from this photo detector is maximum. We used a Spectrum analyser to see the output. After that we connected a photo detector to collect the YEND transmission signal from the ETM mirror. We used a lens to focus this directly to the photodetector. Then we connected this photodetector to the spectrum analyser, which was located near the AS table. We took a large cable to meet this purpose. But still the cable was not lengthy enough, so we joined it with another cable and finally connected it with the spectrum analyser. Then we gave a scan to the Marconi from 51 MHZ to 55 MHz. We repeated this experiment with a scan of 55 MHz to 59 MHz also. We repeated this a few times, but we were not able to see the peak.

We assume that this can be because of some issue with the alignment or it can be because of some issue with the photo detector we used. We would like to repeat this experiment and get the signal properly.

I am attaching a flow chart of the setup and also a picture of the mirrors and photo detector we inserted in the Y-End table.

 
Attachment 1: photodetector_alignment.jpg
photodetector_alignment.jpg
Attachment 2: design1.PNG
design1.PNG
  13926   Thu Jun 7 14:35:26 2018 keerthanaUpdateelogTable- useful for doing the scanning.

I think this table will help us to fix the scanning range of the Marconi frequency. This will also help in predicting the position of the resonance peak corresponding to the injected frequency.

fdiff = fm ±80 MHz ;                     fdiff = N*FSRy ;              FSRy = 3.893 MHz.

N = Integer number fdiff =injected fm = Marconi frequency
1 3.893 76.107
2 7.786 72.214
3 11.679 68.321
4 15.572 64.428
5 19.465 60.535
6 23.34 56.66
7 27.251 52.749
8 31.144 48.856
9 35.037 44.963
10 38.93 41.07
11 42.79 37.21
12 46.716 33.284
13 50.609 29.391
  13939   Mon Jun 11 13:55:33 2018 keerthanaUpdateGeneralProject Updates

As of now, I have made the codes needed to sweep the marconi frequency for taking the cavity scan data, the photo diode at the y-end is conected to the spectrum analyser already and I also have the finesse simulation of the Ideal Fabry-perot cavity. By seeing my last elog entry, Gautam suggested me that I need to take a different approach for estimating the FSR and TMS value from the Finesse graph. That is, by using least square fit models. Now I am trying to do that and get a better estimate of the error values. Based on my understanding I am dividing this project into various tasks.

1. Getting a better estimate of the error value by using least square fits. Also plotting a graph of frequency Vs mode number and finding the value of Free Spectral Range from its slop.

2. Inserting zernike polynomials to the Finesse simulation and with the help of least square fit, plotting the graph of frequency Vs mode number. Understanding the shifts from the Ideal graph we obtained from step 1. Using this data, plotting the phase map corresponding to this.

3. Repeating step 2 by taking different zernike polynomials and creating a data base which will be useful for the analysis of the real data. This will also prepare me to do the fitting models easily.

4. Collecting data from the IFO and applying these fitting models to it. Finding the set of zernike polynomials which are similar to the actual fugure error of the mirror. Plotting the Phase map corresponding to those zernike polynomials.

If you feel that there is some mistake in the steps, please correct me. It will be really helpful!

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

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

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

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

I am uploading 4 python scripts to the github.

1. Analytical Solution

2. Finesse model- cavity scan

3. Finesse model- fitting

4. Finesse model- residual

Quote:

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

fitting_1.pdf

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

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

Quote:

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

Yes, I this does not give us 0.70%

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

But any way, go for the fitting.

 

  13954   Wed Jun 13 11:59:03 2018 keerthanaUpdateelogcommand line enabled code for frequency scanning

I have modified the code for frequency scanning and have made it completely command line enabled. The code is written in python. It is saved in the name "frequency_scanning_argparse.py". I have uploaded it to the Mode-Spectroscopy Github repository.

Inorder to use this code there are two ways.

1. We can mention the ' frequency' on which marconi need to work. Then it will change the marconi frequency to that perticular value.

eg: Type in the terminal as follows for changing the marconi frequency to 59 Mhz.

python frequency_scanning_argparse.py 59e6

2. Inorder to give a scan to the marconi frequency, provide the 'start frequency', 'end frequency' and the 'number of points' in between. This will be more conveniant when we want to run the scan in different ranges.

eg: Type in the terminal as follows for a start frequency of 59 Mhz, end frequency of 62MHz and number of points in between equal to 1000.

python frequency_scanning_argparse.py 59e6 62e6 1000

In both cases the code will show you the frequency of the marconi before we run this code and it will change the marconi frequency to the desired frequency.

  13956   Wed Jun 13 18:08:36 2018 keerthanaUpdate Finesse code for cavity scan

The unit mentioned in the x-axis was wrong. So I have remade the graphs. The point where frequency equals to zero is actually the frequency corresponding to the laser, which is in the range of 1014 Hz and it caliberated as zero.

Quote:

The cavity scan data obtained from the Finesse simulation is attached here. Fig1 indicates the cavity scan data in the absence of induced misalignment. In that case only the fundemental mode is resonating. But when a misalignment is induced, higher order modes are also present as seen in Fig2. This is in the absence of surface figure error in the mirrors. Now I am trying to provide perturbations to the mirror surface in the form of zernike polynomials and get the scan data fom the simulation. These cavity scan data can be used to develop fitting models. Once we have a model, we can use it to analyse the data from the experimental cavity scan.

finesse1.pdffinesse2.pdf

Attachment 1: finesse1.pdf
finesse1.pdf
Attachment 2: finesse2.pdf
finesse2.pdf
ELOG V3.1.3-