40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 295 of 344  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  8616   Wed May 22 15:08:37 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

It seems that the effect is from the (linear) residual fluctuation of the digital AI filter for the zero-padded signal.

Namely, if we give the larger constant number, we get more oscillation.

Attachment 1: Screenshot.png
Screenshot.png
  8626   Thu May 23 10:24:23 2013 JamieSummaryCDSc1scy model continues to run at the hairy edge

c1scy, the controller model at the Y END, is still running very long, typically at 55/60 microseconds, or ~92% of it's cycle.  It's currently showing a recorded max cycle time (since last restart or reset) of 60, which means that it has actually hit it's limit sometime in the very recent past.  This is obviously not good, since it's going to inject big glitches into ETMY.

c1scy is actually running a lot less code than c1scx, but c1scx caps out it's load at about 46 us.  This indicates to me that it must be some hardware configuration setting in the c1iscey computer.

I'll try to look into this more as soon as I can.

  8654   Thu May 30 10:40:59 2013 JamieConfigurationCDSAttempt to cleanup c1ioo ADC connections

I have attempted to reconcile all of the ADC connections to c1ioo.  Upon close inspection, it appears that there was a lot of legacy stuff hanging around.  Either that or things have not been properly connected.

The c1ioo front end machine has two ADC cards, ADC0 and ADC1, which are used by two models, c1ioo and c1als.  The CURRENT ADC connections are listed in the table below.  The yellow cells indicate connections that were moved.  The red cells indicate connections that were removed/unplugged:

  channel block connection channel usage  model
ADC0 8-15 MC WFS1 interface   MC WFS1 c1ioo
16-23 MC WFS2 interface   MC WFS2 c1ioo
0-7

generic interface card (2 pin lemo)

0    
1    
2    
3 ALS TRX c1als
4 ALS TRY c1als
5    
6 MCL c1ioo
7 MCF c1ioo

 

  channel block connection channel usage model
ADC1 0-31 1U interface board 0/1 (J1A) PSL FSS MIXER/NPRO c1ioo
2/3 (J2) ALS BEAT X/Y DC c1als
4/5 (J3) PSL eurocrate DAQ interface J4  
6/7 PSL eurocrate DAQ interface J5  
8/9 PSL eurocrate DAQ interface J6  
10/11 MC eurocrate DAQ interface J1  
12/13 MC servo board DAQ  
14/15 (J8)    
16/17 (J9A) UNLABELLED ("DAQ ISS1"???)  
18/19 (J10) "DAQ ISS2"  
20/21 "DAQ ISS3"  
22/23 ALS BEAT X I/Q c1als
24/25 ALS BEAT Y I/Q c1als
26/27    
28/29    
30/31 (J16)    

The following changes were made:

  • "MC L" had been connected to ADC_0_0, moved to ADC_0_6
  • "MC F" had been connected to ADC_0_6, moved to ADC_0_7

The c1ioo model was rebuilt/restarted to reflect this change.

The PSL-FSS_MIXER and PSL-FSS_NPRO connections were broken in the c1ioo so I fixed them when I moved the MC channels.

All the removed connections from ADC1 were not used by any of the front end models, which is why I unplugged them.  Except for the MC DAQ interface J1 and MC servo DAQ connections, I left all other cables plugged in to wherever they were coming from.  The MC cables I did fully remove.

I don't know what these connections were meant for.  Presumably they expose they expose some useful DAQ channels that we're now getting elsewhere, but I'm not sure.  We don't currently have an ISS, which is presumably why the cables labelled "ISS" are not going anywhere.

TODO

I would like to see some more 4-pin lemo --> double BNC cables made.  That would allow us to more easily use the ADC1 generic interface board:

  • Moved ALS TRX/Y to ADC1, so that we can keep all the ALS connections together in ADC1.
  • POP QPD X/Y/SUM

We should also figure out if we're sub-optimally using the various "DAQ" connections to the DAQ cable connectiosn to the eurocrate DAQ interface cards and servo boards.

  8656   Thu May 30 11:28:34 2013 JamieConfigurationCDSc1als model cleanup

The c1als model was pulling out some ADC0 connections that were no longer used for anything:

  • ADC_0_1 --> sfm "FD" --> IPC "C1:ALS-SCX_FD"
  • ADC_0_5 --> sfm "OCX" --> term
  • ADC_0_6 --> sfm "ADC" --> term

The channels would have shown up as C1:ALS-FD, C1:ALS-OCX, C1:ALS-ADC.  The IPC connection that presumably was meant to go to c1scx is not connected on the other end.

I removed all this stuff from the model and rebuilt/restarted.

  8722   Wed Jun 19 02:46:19 2013 JenneUpdateCDSConnected ADC channels from IOO model to ASS model

Following Jamie's table in elog 8654, I have connected up the channels 0, 1 and 2 from ADC0 on the IOO computer to rfm send blocks, which send the signals over to the rfm model, and then I use dolphin send blocks to get over to the ass model on the lsc machine. 

I'm using the 1st 3 channels on the Pentek Generic interface board, which is why I'm using channels 0,1,2. 

I compiled all 3 models (ioo, rfm, ass), and restarted them.  I also restarted the daqd on the fb, since I put in a temporary set of filter banks in the ass model, to use as sinks for the signal (since I haven't done anything else to the ASS model yet).

All 3 models were checked in to the svn.

  8727   Wed Jun 19 18:24:14 2013 JenneUpdateCDSProto-ASC implemented in ASS model

I have implemented a proto-ASC in the ASS model.  

In an ASC block within the ASS model, I take in the POP QPD yaw, pit, and sum signals.  I ground the sum, since I don't have normalization yet (also, the QPD that we're using normalizes in the readout box already).  The pit and yaw signals each go through a filter bank, and then leave the sub-block so I can send the signals over to the SUS model, to push on PRM ASCPIT and ASCYAW. 

In doing this, I have removed the temporary PRM ASCYAW connection that Koji had made from the secret 11'th row of the LSC output matrix (see Koji's elog 8562 for details from when he implemented this stuff).

LSC, SUS and ASS were recompiled, and restarted.  I also restarted the daqd on the fb.

  8739   Mon Jun 24 16:41:40 2013 JenneUpdateCDSProto-ASC implemented in ASS model

I am working on making the Proto-ASC less "proto".  I have put IPC senders in the LSC model to send the cavity trigger signals over to the ASS model, for ASC use.  I'm partially done working on the ASC end of things to implement triggering.

LSC should be compile-able right now, ASS is definitely not.  But, I expect that no one should need to compile either before I get back in a few hours.  If you do - call me and we'll figure out a plan.

  8740   Tue Jun 25 00:13:00 2013 JenneUpdateCDSProto-ASC implemented in ASS model

I have finished my work on the LSC and ASS models for now. The triggering is all implemented, and should be ready to go.  There are no screens yet.

I have *not* compiled either the LSC or the ASS, since Rana and Manasa still have the IFO.

  8809   Tue Jul 9 11:37:37 2013 gautamUpdateCDSset up for testing DAC Interface-board pin outs

The bank marked channel 9-16 is free, but the connector is a 40 pin IDC and I need to know the exact pin-out configuration before I can set about making the custom ribbon cable that will send the control signals from the DAC card to the PZT driver board. 

The DAC interface board on rack 1Y4 seems to be one of the first versions of this board, and has no DCC number anywhere on it. Identical modules on other racks have the DCC number D080303, but this document does not exist and there does not seem to be any additional documentation anywhere. The best thing I could find was the circuit diagram for the ADL General Standards 16-bit DAC Adapter Board, which has what looks like the pin-out for the 68 pin SCSI connector on the DAC Interface board. Koji gave me an unused board with the same part number (D080303) and I used a multimeter and continuity checking to make a map between DAC channels, and the 40 pin IDC connector on the board, but this needs to be verified (I don't even know if what is sitting inside the box on 1Y4 is the same D080303 board).

Jenne suggested making a break-out cable to verify the pin-outs, which I did with a 40-pin IDC connector and a bit of ribbon wire. The other end of the ribbon wire has been stripped so that we can use some clip-on probes and an oscilloscope to verify the pin-outs by sending a signal to DAC channels 9 through 16 one at a time. On the software side, Jenne did the following:

  • Restarted the mx_stream on c1iscey  (unrelated to this work)
  • 8 Excitation points added in the simulink model on c1scy 
  • Model compiled and installed

We have not restarted c1scy yet as Annalisa is working on some Y-arm stuff right now. We will restart c1scy and use awggui to perform the test once she is done.

 Pink edits by JCD

  8811   Tue Jul 9 12:01:20 2013 gautamUpdateCDSset up for testing DAC Interface-board pin outs

 

 Jenne just rebooted c1scy and daqd on the framebuilder. We will do the actual test after lunch.

  8814   Tue Jul 9 18:44:37 2013 gautamUpdateCDSDAC Interface Board-Pin Outs

  Summary:

The pin-outs for the DAC interface board have been determined.

Details:

  • I used a temporary break-out cable (pic attached) and connected the 40pin IDC connector on this to the DAC interface board at 1Y4.
  • I had a hypothetical pin-out map which was to be verified. So I connected pairs of ribbon wire to an oscilloscope in the configuration which I believed to be correct, and then used awggui to send a 3Hz, 10000 count sine-wave to the corresponding channel via the excitation points set up earlier.
  • I verified that the correct waveform showed up on the scope screen. I then tried sending the same signal to another DAC channel and verified that there were no accidental shorts/bad connections. The signal was fairly noisy, but this was probably because of the makeshift connections.
  • Repeated the above for all 8 channels in the bank marked 9-16 on the DAC interface board.

Turns out that my deductions using the D0902496 wiring diagram, a spare D080303 DAC to IDC adaptor and a multimeter were correct! The pin outs as determined by this test are sketched in the graphic below.

To Do:

  •  Now that the pin-outs have been determined, I need to go about making the custom ribbon that will connect the 40pin IDC on the DAC interface board to the 10-pin IDC on the PZT driver board. Because there is a pair of wires that will have to be 'skipped' while going from the 40-pin to the 10 pin IDC (corresponding to the pair not-connected between two DAC channels on the 40-pin IDC), this may be tricky.

Misc:

The excitation points added to the simulink model are still there, I plan on keeping it as such till I finish installation of the boards as they will be useful for testing purposes.

 

Pin-Outs of the DAC to IDC Adaptor (D080303) inside the "DAC Interface Box at 1Y4":

DAC_Interface_Board_Pin-out.pdf

 

Makeshift break-out ribbon cable:

 

break-out_ribbon.JPG

 

 

  8858   Tue Jul 16 15:22:27 2013 manasaUpdateCDSFront ends back up

c1sus, c1ioo, c1iscex and c1iscey were down. Why? I was trying to lock the arm and I found that around this time, several computers stopped working mysteriously. Who was working near the computer racks at this time???

I did an ssh into each of these machines and rebooted them sudo shutdown -r now

But then I forgot / neglected/ didn't know to bring back some of the SLOW Controls computers because I am new here and these computers are OLD. Then Rana told me to bring them back and then I ignored him to my great regret. As it turns out he is very wise indeed as the legends say.

So after awhile I did Burtgooey restore of c1susaux (one of the OLD & SLOW ones) from 03:07 this morning. This brought back the IMC pointing and it locked right away as Rana foretold.

Then, I again ignored his wise and very precious advice much to my future regret and the dismay of us all and the detriment of the scientific enterprise overall.

Later however, I was forced to return to the burtgooey / SLOW controls adventure. But what to restore? Where are these procedures? If only we had some kind of electronics record keeping system or software. Sort of like a book. Made of electronics. Where we could LOG things....

But then, again, Rana came to my rescue by pointing out this wonderful ELOG thing. Huzzah! We all danced around in happiness at this awesome discovery!!

But wait, there was more....not only do we have an ELOG. But we also have a thing called WIKI. It has been copied from the 40m and developed into a thing called Wikipedia for the public domain. Apparently a company called Google is also thinking about copying the ELOG's 'find' button.

When we went to the Wiki, we found a "Computer Restart Procedures" place which was full of all kinds of wonderous advice, but unfortunately none of it helped me in my SLOW Controls quest.

 

Then I went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive. And then I burtgooey'd some of them (c1susaux) ?? And then I thought that I should update our 'Computer Restart Procedures' wiki page and so I am going to do so right now ??

And then I wrote this elog.

 

  8860   Tue Jul 16 18:20:25 2013 JenneUpdateCDSProto-ASC implemented in ASS model

The proto-ASC now includes triggering.  I have updated the hacky temp ASC screen to show the DoF triggering.  I have to go, but when I get back, I'll also expose the filter module triggering.  So, for now we may still need the up/down scripts, but at least the ASC will turn itself off if there is a lockloss.

  8880   Fri Jul 19 12:23:34 2013 manasaUpdateCDSCDS FE not happy

I found CDS rt processes in red. I did 'mxstreamrestart' from the medm. It did not help. Also ssh'd into c1iscex and tried 'mxstreamrestart' from the command line. It did not work either.

I thought restarting frame builder would help. I ssh'd to fb. But when I try to restart fb I get the following error:

controls@fb ~ 0$ telnet fb 8088
Trying 192.168.113.202...
telnet: connect to address
192.168.113.202: Connection refused

 

Screenshot-Untitled_Window.png

  8881   Fri Jul 19 14:04:24 2013 KojiUpdateCDSCDS FE not happy

daqd was restarted.


- tried telnet fb 8088 on rossa => same error as manasa had

- tried telnet fb 8087 on rossa => same result

- sshed into fb ssh fb

- tried to find daqpd by ps -def | grep daqd => not found

- looked at wiki https://wiki-40m.ligo.caltech.edu/New_Computer_Restart_Procedures?highlight=%28daqd%29

- the wiki page suggested the following command to run daqd /opt/rtcds/caltech/c1/target/fb/daqd -c ./daqdrc &

- ran ps -def | grep nds => already exist. Left untouched.

- Left fb.

- tried telnet fb 8087 on rossa => now it works

  8895   Mon Jul 22 22:06:18 2013 KojiUpdateCDSFE Web view was fixed

FE Web view was broken for a long time. It was fixed now.

The problem was that path names were not fixed when we moved the models from the old local place to the SVN structure.

The auto updating script (/cvs/cds/rtcds/caltech/c1/scripts/AutoUpdate/update_webview.cron) is running on Mafalda.

Link to the web view: https://nodus.ligo.caltech.edu:30889/FE/

  8900   Tue Jul 23 04:07:48 2013 gautamUpdateCDSExcitation points set up on c1scx

 

 In light of recent events and the decision to test the piezo tip-tilts for green beam steering on the X-end table, I have set up 8 excitation points to channels 8 through 15 of the DAC on c1scx (as was done earlier for the DAC at 1Y4 with Jenne's help) in order to verify that the pin-outs of the DAC interface board. I have not yet compiled the model or restarted the computer, and will do these tomorrow, after which I will do the test. The channels are named YYY_CHAN9 etc. 

 

 

 

 

  8909   Tue Jul 23 16:47:01 2013 gautamUpdateCDSExcitation points set up on c1scx

 I just compiled and installed the model with the excitation points on c1scx and then restarted framebuilder. The channels I set up are now showing up in the awggui dropdown menu. I will do the tests on the DAC channels shortly.

Just to keep things on record, these are the steps I followed:

  • opened the model c1scx (path: /opt/rtcds/userapps/release/sus/c1/models) with MATLAB
  • Added 8 excitation points and saved the model. A copy has been saved as c1scx.mdl.r2010b because of the recent upgrade to r2013a. 
  • ssh to c1iscex (computer running the model c1scx). 
  • Entered the following sequence of commands in terminal: rtcds make c1scx ,  rtcds install c1scx , rtcds start c1scx 
  • ssh to framebuilder, and restarted the framebuilder by entering telnet fb 8088   and then   shutdown.
  8911   Tue Jul 23 19:38:58 2013 gautamUpdateCDSCharacterisation of DAC at 1X9

 

 I just finished carrying out the same checks for the DAC at 1X9 (with channels 9 through 16 that are unused as of now) as those I had done for the DAC at 1Y4, as the hardware prep up till now was done with the characterisation of the DAC at 1Y4. Conclusions:

  • The accessible range of output voltage are -10 V to +10V w.r.t ground --> No change needs to be made to the gain of the HV amplifier stage on the PZT Driver Board
  • The pin-outs of the DAC Adaptor Board at 1X9 is identical to that at 1Y4 --> Custom ribbons do not need to be modified.
  • The PSD of the DAC output has a peak at 64 kHz --> Notches on AI Board do not need to be moved again.

I will now proceed to install various pieces of hardware (AI Board, PZT driver board, HV Power Supply and cabling) at 1X9, while not making the connection to the PZTs till I receive the go ahead. 

  8949   Thu Aug 1 12:12:35 2013 gautamUpdateCDSNew model for endtable PZTs

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

 

C1ASX_GDS_TP.png

 

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

  8950   Thu Aug 1 13:09:17 2013 gautamUpdateCDSNew model for endtable PZTs-procedure

 

 These are roughly the steps I followed in setting up the new model for the endtable PZT servo - C1ASX.


Simulink model:

I made a SIMULINK model of the servo, using MATLAB R2013a. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1asx.mdl. I am listing the parameters set on the CDS_PARAMETERS block:

  • host = c1iscex
  • site = c1
  • rate = 16k
  • dcuid = 44 (which I chose after making sure that this dcuid was not used on this list which was last updated end Feb 2013)
  • specific_cpu = 5 (again chosen after checking the available CPUs in the above list).
  • adc_Slave = 1
  • shmem_daq = 1
  • no_rfm_dma = 1
  • biquad = 1

 

Making, Compiling and Installing the Model:

After saving the model, I ssh-ed into c1iscex and ran the following commands:

rtcds make c1asx - this gave me a whole bunch of errors initially, which I tracked down to a naming problem in some of the from and goto flags: there should not be any spaces.

rtcds install c1asx 

rtcds start c1asx - this gave me an error which said something like 'can't start/stop model.' Koji pointed out that given that a new model is being started, there is an additional step involved, which is to add the model name to the rtsystab file (this is located at /diskless/root/etc/rtsystab on framebuilder, and is mirrored in the various computers. It would be advisable to make sure that the changes are mirrored in the corresponding file on the computer in which the new model is being installed). 

After adding the model name to the rtsystab file, I tried running rtcds start c1asx again. This time, no errors were output, but the model was not up and running as verified by looking at the C1:ASX_GDS_TP medm screen.


 Debugging 

Koji suggested making a simple model (1 CDS parameters block, 1 ADC block and 2 filter modules, appropriately terminated) and see if that starts up, which it did. I then tried adding my servo minus the DAC block and recompiled and restarted the model. This too worked fine. I figured that the next logical step would be to add the DAC block to the model, and restart the model. But when I tried this, c1iscex crashed .

Jenne helped in restoring things to a working state (we reverted the c1asx model to just 2 filter modules, and went to the X-end and restarted the computer. This did not work the first time so I went back in and restarted it again, at which point we were able to ssh into c1iscex again and restart the four models running on it).

Since Manasa and Koji were working on getting things set up for the pumpdown,I did not try anything again till later in the evening, when Koji helped in debugging the problem further. In the meantime, at Jenne' suggestion, I made the model once again in MATLAB R2010b. In the evening, when I tried restarting the model, Koji suggested that the DAC channels in c1asx may be used by other models, at which point I realised I had set up excitation points on channels 8 through 15 of the DAC in c1scx (detailed here) in order to test the hardware at 1X9. I removed the excitation points from channels 8-11 of the DAC block in c1scx (these are the ones used in c1asx), and recompiled and restarted c1asx (using the above sequence of commands). I then tried recompiling and starting c1asx once more, and this time, it worked . At least, the GDS_TP screen suggests that the model is running alright, except for the fact that some computer generated channels seem to be missing. This problem is unresolved for now, and probably has something to do with the fact that C1ASX channels do not appear in Dataviewer.

I do not think this has to do with restarting framebuilder (I did the usual telnel fb 8088 followed by shutdown). In any case, I have added the new model to the CDS_FE_STATUS screen, and will continue to debug the same. I have also got a template medm screen (work in progress) which I will elog about soon as I get it done.

 

Note to self: There are 4 more excitation channels still hooked up to the DAC (channels 12-15) in the c1scx model. I plan to remove these and put them in c1asx.

 

  8951   Thu Aug 1 15:06:59 2013 jamieUpdateCDSNew model for endtable PZTs

Quote:

I have made a new model for the endtable PZT servo, and have put it in c1iscex. Model name is c1asx. Yesterday, Koji helped me start the model up. The model seems to be running fine now (there were some problems initially, I will post a more detailed elog about this in a bit) but some channels, which are computer generated, don't seem to exist (they show up as white blocks on the MEDM GDS_TP screen). I am attaching a screenshot of the said screen and the names of the channels. More detailed elog about what was done in making the model to follow.

 

C1ASX_GDS_TP.png

 

Channel Names:

C1:DAQ-DC0_C1ASX_STATUS (this is the channel name for the two leftmost white blocks)

C1:DAQ_DC0_C1ASX_CRC_CPS

C1:DAQ-DC0_C1ASX_CRC_SUM

I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...

Is there a reason that you're making a new model for this?  You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block.  Then you wouldn't have to worry about all of the issues with adding and integrating a new model.

  8952   Thu Aug 1 15:28:44 2013 gautamUpdateCDSNew model for endtable PZTs-problem solved

Quote:

 

I don't know what's going on here (why the channels are white), and I don't yet have a suggestion of where to look to fix it but...

Is there a reason that you're making a new model for this?  You could just use and existing model at c1iscex, like the c1scx, and put your stuff in a top-names block.  Then you wouldn't have to worry about all of the issues with adding and integrating a new model.

Koji just fixed this.

It seems that the new model's channels were not automatically added to the master file in the framebuilder (/opt/rtcds/caltech/c1/target/master). Adding the following two lines to the master file fixed the problem;

/opt/rtcds/caltech/c1/chans/daq/C1ASX.ini

/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1asx.par

The box is now green. It looks like C1ASX.ini is created automatically in /opt/rtcds/caltech/c1/chans but the master file needs to be manually edited. The channels are now showing up on dataviewer etc. I have updated the information on the wiki page.


 

 

 

 

 

  8956   Thu Aug 1 20:58:56 2013 gautamUpdateCDSNew model for endtable PZTs-MEDM Screens setup

 

I have made some minor changes to the model, made all the MEDM screens, and linked monitors on these to the appropriate channels. I have borrowed heavily from the C1ASS MEDM screens (particularly for the small filter modules-it was convenient to just copy and paste an existing module, and edit the channel names using EMACS/GEDIT), and have edited these to suit the needs of this servo. Some features:

  • The feedback signal (only the output of the servo to the PZTs, plus any contribution from the on-screen sliders, and not including the LO output) is monitored with both a slow (using CDS_EPICS_OUTPUT block from the CDS_PARTS library) and fast channel (using Test Point from the same library). The idea is that it would be useful to know the output to the PZTs such that if coarse adjustment ever needs to be done at the endtable, the PZTs can be restored to the middle of its operating range by means of the sliders.
  • Sliders are incorporated into the master screen for adjusting the output to the PZTs. There are text-input fields below the sliders as well, which control the same channel.
  • I have removed the 4 remaining excitation points to the DAC set up in C1SCX, and have relocated them to channels 12-15 of the DAC in C1ASX.

I think I am now ready to take some measurements and try and optimize this servo. There is no green transmission at the PSL table at the moment, so not much can be done, though the first step would be to take the power spectrum of the error signal, which would help me decide the appropriate frequencies for the LOs. I would then have to add the appropriate filters to the model. The last, and most difficult step, would be the measurement of the output matrix, though Koji has given me some ideas about how this measurement can be done. I also have a template script ready, though I will only finalise this after optimising the servo and running it a couple of times manually.

 

Attached are screenshots of the MEDM screens.

 

MAIN_SCREEN.pdf      MATRICES.pdf   

LOCKINS.pdf      CONTROL_FILTERS.pdf

 

  8957   Thu Aug 1 21:28:09 2013 gautamUpdateCDSSlow channels set-up in ALS

The following slow channels have been added and are now being recorded by FB.

 

C1:ALS-X_OVEN_TEMP

C1:ALS-Y_OVEN_TEMP

C1:ALS-BEATX_FREQ

C1:ALS-BEATY_FREQ


Details:

In order to integrate the data collected by the Raspberry-Pi from the Y-end doubling oven temperature controller and also the data from the frequency counter which will be hooked up to monitor the beat frequency, Koji helped me set up some slow EPICS record channels (in ALS as we felt this was most appropriate). The procedure for setting up slow channels was as follows (virtually identical to what is detailed in this elog:

  1. Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  2. Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/als.db).
  3. Restart framebuilder. 
  4. Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

I will now integrate these channels into my scripts, and make some simple MEDM screens.

 

  8966   Mon Aug 5 18:18:32 2013 gautamUpdateCDSChoosing LO Amplitudes and Frequencies

In order to decide what frequencies to dither the 4 degrees of freedom (M1-pitch&yaw, M2-pitch&yaw) at, I took the power spectrum of the X and Y-arm green transmission (C1:ALS-TRX_OUT, C1:ALS-TRY_OUT). Plots showing the power spectra are attached. Looking at the power spectra, I would think that for the X-arm, it would be okay to dither at 40, 50, 60 and 70 Hz. In order to check if the piezos could respond to these frequencies, I used my QPD setup and shook the PZTs with a 100Hz, 1Vpp sinusoid, and saw that the spot moved smoothly on the QPD.


 As for choosing the modulation amplitude, I did a simplistic approximation assuming that the misalignment only rotates the beam axis relative to the cavity axis, and determined what angle coupled 10% of the power into the next eigenmode. Assuming that this is small enough such that if we are already locked to TEM00, the dither won't kick it up to some higher-order mode, the LO amplitude should be in the range of 30-60 digital counts (determined using the PZT calibration constants determined here. This corresponds to a sine-wave of ~50mV amplitude reaching the PZTs (after HV amplification). I am not sure if this is too small, but according to the PZT datasheet, these platforms are supposed to have a resolution of 0.02 urad, which would correspond to the input signal changing by ~0.1 mV, so this signal should be capable of dithering the tip-tilt. 


 I have already added band-pass filters centered at these frequencies to the model (with a passband of 5Hz, 2Hz on either side), and low-pass filters to pull out the DC component of the output of the lock-in amplifiers. It remains to tune the gains of the filter stages. These parameters (frequency, amplitude of the LOs) may also have to be changed after tests). Hopefully the PZTs can be plugged in tomorrow, and I can try and make a measurement of the output matrix. 

Koji also suggested that it may be good to have a path in the model that feeds back to the PZTs by dithering the cavity mirrors as opposed to the PZT mounted mirrors. I will work on incorporating this into the SIMULINK model (c1asx.mdl) and also into the master medm screen.


 

Notes:

  1. The spot size of the X-arm green transmission on the PD was larger than the active surface. I moved the GTRX PD a little back and put in a lens (KPX085, 62.9mm FL, AR.14) in front of the PD, such that the spot is now occupying about 1/4th of the active surface area. The lens was mounted in a Thorlabs LMR1mount, and has been labelled.
  2. I made a slight change to the SIMULINK model, so as to calibrate the PZT sliders to (approximately) volts (I added a multiplier block that multiplies the slider value by constant value 3267.8). The idea is that we can approximately relate the slider value to tilt, knowing the calibration constant in mrad/V for the PZTs.

 

Power Spectra of Arm Green Transmission:

GTR_Power_Spectrum.pdf

  8968   Mon Aug 5 19:10:01 2013 KojiUpdateCDSChoosing LO Amplitudes and Frequencies

- I suppose the green transmission paths were thoroughly inspected and aligned in prior to the measurement

- Of course it is a BAD idea to use 60Hz as the LO frequency.

- Power spectra should be plotted as "RIN (relative intensity noise)" as the DC of 1 and 100 gives you 100 times different power spectra for the same beam.
  Don't forget to subtract the offset from your DC values.

  8972   Tue Aug 6 16:36:51 2013 gautamUpdateCDSChoosing LO Amplitudes and Frequencies-revised

I redid the power spectrum measurement for the X-arm green transmission after aligning the arm to green using the ITMX/ETMX Pitch and Yaw sliders on IFOalign.

The Y-axis now reflects the relative intensity noise (RIN), which I obtained by taking the average value of the X-arm green transmission using tdsavg. Based on this measurement, I have now picked four new frequencies at which to try and modulate the PZT mirrors: 10, 19, 34 and 39 Hz. Bandpass filters in the LIA stage have been appropriately modified. 

Power Spectrum:

powerSpec0806.pdf

  8983   Wed Aug 7 23:40:49 2013 gautamUpdateCDSX-End Green ASS - A first update

 I have done some preliminary testing of the X-End Green ASS Servo. I will write a more detailed elog about this soon, but I thought I'd note down the important stuff here.


Yesterday, while we were venting, I aligned the X-arm to the green using the sliders on IFOalign, maximizing the transmission. Then I retook a power spectrum so as to determine the LO frequencies. Jenne pointed out that LO frequencies should not be integers (it usually suffices to append a .098725 or something to the frequency) so I made the necessary changes.

I did a first run of the servo yesterday, and more runs today. Notable points:

  1. I was able to lock to 00 from a 08 or 09 mode using the PZT sliders
  2. The green transmission having locked to 00 was ~0.2. I then ran the servo and got it up to ~0.4 and then 0.6 (see time series plot attached). The servo was able to recover this level of transmission after misaligning the steering mirrors using the PZT sliders.
  3. This was not the optimal transmission level as when Koji moved ETMX a little, the transmission improved.
  4. The actuators are degenerate. Most of the time, only two of the four servos are doing anything significant. This is probably because of the fact that the two steering mirrors are so close to each other, that moving one or the other produces virtually the same effect. I do however have some cool videos of mode-hopping :)
  5. The range of actuation of the PZTs is probably not enough to maximize the green transmission from an arbitrary state because of point 4 (i.e. we need to move one mirror in some direction a lot, and move the other a lot to compensate for the change, and the overall gain in input pointing/alignment is marginal). It may be that things will be slightly better at the Y-end. It would also be interesting to see if there is any improvement in the servo performance by dithering the cavity mirrors as opposed to the PZT mirrors.
  6. To this end, I tried modifying the c1asx model to incorporate an option to dither the cavity mirrors. The plan was to make a second set of LOs in the model that output to ITMX and ETMX suspensions. However, for some reason, when I recompiled the model and restarted it, c1iscex crashed. Parity has now been restored. Note that in order to accommodate the new LOs, I had to make changes to C1SUS, C1RFM and C1SCX as well. I have since removed all my additions, saved, built and installed these models, but have not restarted them (with the exception of C1SCX which restarted when I manually restarted c1iscex). 
  7. The plan tomorrow is to try incorporating cavity dither into the model again. This time, I'll try grabbing the LO-related signals from c1ass directly, as I am not clear why my approach did not work.

More details to follow.

time-series.pdf

  8993   Sat Aug 10 05:53:51 2013 gautamUpdateCDSX-End Green ASS - Roundup

Over the last three days, I've had the interferometer to test and optimize the ASX Servo. Based on what I have seen, I think the conclusion is that with the current parameters, the servo does its job provided the input pointing set up at the endtable with the coarse adjustment knobs is reasonably good. Once the cavity is aligned and IR transmission maximized using ASS, I have been able to get the green transmission up to 0.8 which is close to the best we had pre-vent. I have not been elogging regularly over the last few days, so this one is going to be a longish one.


Major changes made:

  1. The SIMULINK model has been modified to accommodate an option to dither the cavity mirrors and not the PZT mirrors. Details are as follows:
    • I have sent the LO signals (CLK,SIN and COS) from the ASS model to the ASX model via the RFM model. Appropriate changes were made to all these three models, and recompiling and restarting the models was done without issue. The SIN and COS signals are used to demodulate green transmission at the dither frequencies. ***The CLK signal is not required to be sent between models as it is not being used by ASX (I turn the dither ON using the channels already set up for ASS). I realised this a little late, and at present the ASS and RFM models are compiled such that the CLK signal is also sent from ASS to RFM. This can be removed, thus freeing up 4 unnecessary inter-process communication channels. Also, I am not too sure if this is relevant, but the maximum computation time of both the RFM and ASX models seem to have gone up after I added these inter-process communication links.***
    • The rest of this part of the servo is a replica of the part where PZT mirrors are dithered. At present the servo output is the sum of its two branches (PZT mirror dither branch and cavity mirror dither branch) which works fine under the assumption that at any one time, only one arm will run. Ideally, the summing block should be replaced by a switch. However, when I tried (in an earlier attempt to include the cavity dither) to do this and restart the model, c1iscex crashed, and so I decided against using the switch block for this trial.
    • The control signal generated using green transmission demodulated at the ETM dither frequencies are used to actuate on M1 while the ITM ones are used to actuate on M2. Of course, by setting the appropriate off-diagonal elements in the output matrix, this can be modified as desired.
  2. The main MEDM screen has been updated to reflect the new additions to the SIMULINK model. Screenshot is attached. The picture isn't entirely accurate as the monitor channels in the upper row actually show the servo output + slider output. This needs to be changed in the model, and a new set of monitors need to be added to the MEDM screen. In the end, we require four sets of monitor-points in the model: PZT dither servo output, cavity dither servo output, sum of these with any offset from the PZT sliders, and the sum of the latter with the dither signal (this is what eventually goes to the PZT mirrors while the dither is on).
  3. I added scripts to the MEDM screen that turn the PZT mirror dither servo on and off. Note that when you want to run a new script on an MEDM screen using medmrun, you need to change the permissions of the file by going to the path where your script is located and running chmod 755 <name of script>. Manasa has updated the same on the wiki.

 Details of tests runs:

For the most part, I have been trying to optimize the PZT mirror dither servo. To this end, I did the following:

  • Went to the X-end and fixed the input pointing which was not optimal. Manasa first aligned the arm and ran ASS to maximize the IR transmission. I then used the coarse adjustment knobs on the mirror mounts to get the green transmission up to ~0.6.
  • I then set the following parameters in the servo (these are all in the script, path to which is /opt/rtcds/caltech/c1/scripts/ASX):
    1. LO frequencies of 10, 19, 34 and 39 Hz respectively for M1 PIT, M1 YAW, M2 PIT and M2 YAW.
    2. LO amplitudes of 75 for all the four degrees of freedom (determined by using PZT calibration to see what amplitude would couple 10% of power into the first higher-order-mode assuming a perfectly aligned beam to start with.
    3. LIA BP filters centered at the above frequencies with 2Hz passband on either side.
    4. LIA LP filters with corner frequency 0.5 Hz.
    5. LIA Signal filter bank gain set to 100 for all degrees of freedom.
    6. LIA Demod I phase filter bank gain set to 5 for all degrees of freedom.
    7. Control filter gains to 1 for all degrees of freedom (control filters are all integrators).
    8. Demod phase set to 0 for all degrees of freedom. I did not really try to optimize this but the servo seems to be doing reasonably well even with this setting.
    9. Overall servo gain to 1 (the servo worked well when I increased this to 5 as well, but became unstable when I increased it further).
  • I ran the servo. Observations were as follows:
    • Having fixed the input pointing to get green transmission up to ~0.6, the servo was able to improve it to ~0.8, which is the best we had after hours spent at the X-end prior to the vent.
    • Given a good input pointing, we can use the PZT mirrors to lock to 00 mode from some misaligned state using either the sliders, or by leaving the servo on, and helping it out at the points where it gets 'stuck' in some higher mode using either the sliders or by toggling the shutter.
    • In order to recover green transmission of ~0.8, it was often necessary to first run ASS to optimize the IR transmission. Otherwise, green-transmission saturates at ~0.6 or 0.4 depending on the misalignment of the arm cavity mirrors. The servo was unable to change the input pointing enough to deal with overly misaligned cavity mirrors. 
    • The servo is sometimes capable of bringing about mode-hopping from a higher order mode to a lower one, though this is not always the case as the PDH lock is sometimes too strong, in which case I toggled the shutter after which the servo kicked in.
    • I tested the servo under as many different conditions as I could. For instance, having left the green shutter open overnight, I saw that the transmission had fallen from 0.8 (which was what we saw on Thursday night) to ~0.4 on Friday morning. Running the servo got the transmission up to 0.6. I then asked Manasa to run ASS, (while leaving the ASX servo on), after which point the green transmission went up to 0.8. Sometimes, the servo locks to a 'bad' 00 mdoe, where the transmission saturates at ~0.2, but toggling the shutter fixes this most of the time.

Attempt to measure transfer function:

One of the things that came up during my presentation was how fast the loop was capable of responding. I was able to get a quantitative idea of this by playing around with the overall servo gain. Initially, it took ~30 seconds for the servo to get the transmission up to its peak value, with a servo gain of 1. When I ramped this up to 5, the response was much faster, with the peak transmission being reached in ~5seconds. 

 

I wanted to get a more quantitative picture, and hence tried to measure the transfer function by first injecting an excitation into the 'SIG' filter-bank in the demodulation stage. However, coherence between the IN1 and IN2 signals was very poor for all the amplitude configurations I tried. At Jenne's suggestion, I tried injecting the excitation at the control-filters stage, but found no improvement. Perhaps the amplitude envelope was wrong or the measurement technique has to be rethought. 


 Misc remarks:

  1. M1 is the first steering mirror and M2 is the second one (right before the beam enters the arm cavity).
  2. Though I have added the cavity dither feature to the model, I was not able to optimize this servo. Some calculations need to be done to get an estimate of the output matrix, after which the filter gains etc can be optimized.
  3. Today, I cleaned up my temporary setup at the SP table to calibrate the PZTs. Most of the hardware for the Y-end is now in the tupperware box. The QPD and laser have been restored to the optical bench next to MC2 where I found them. The second KEPCO HV supply which I had set up has now been installed at 1Y4 in anticipation of the PZT mirrors at the Y-endtables. It is currently powered OFF.
  4. Performance plots to follow as I have not pulled the data out yet.
  5. I had bought a cake from chandler today in an effort to clear my meal plan, but in the rush in the afternoon, completely forgot about it. It is in the fridge, and is strawberry tart, hope it tastes good.

 


 New MEDM screen:

New_ASX_MEDM_MAIN.pdf 

  8995   Mon Aug 12 12:57:59 2013 JenneUpdateCDSX-End Green ASS - Roundup

Quote:
  1. The SIMULINK model has been modified to accommodate an option to dither the cavity mirrors and not the PZT mirrors. Details are as follows:
    • I have sent the LO signals (CLK,SIN and COS) from the ASS model to the ASX model via the RFM model. Appropriate changes were made to all these three models, and recompiling and restarting the models was done without issue. The SIN and COS signals are used to demodulate green transmission at the dither frequencies. ***The CLK signal is not required to be sent between models as it is not being used by ASX (I turn the dither ON using the channels already set up for ASS). I realised this a little late, and at present the ASS and RFM models are compiled such that the CLK signal is also sent from ASS to RFM. This can be removed, thus freeing up 4 unnecessary inter-process communication channels. Also, I am not too sure if this is relevant, but the maximum computation time of both the RFM and ASX models seem to have gone up after I added these inter-process communication links.***

    •  

 Getting rid of the LO transmission will certainly help / be good.  After adding these channels, the RFM model is regularly hitting 62usec (out of a max acceptable of 60).

I'm not really sure why the ASS was involved in this.  I feel like it might have been simpler to just do everything in the ASX model, to keep things cleaner.  Also, the IPC blocks for this stuff (in both ASS and ASX) are not on the top level of the model.  I had thought that this was expressly forbidden (although I'm not sure why).  I'm emailing Jamie, to see if he remembers what, if anything, is breakable if the IPC blocks are down a level.

  8996   Mon Aug 12 13:30:33 2013 JamieUpdateCDSX-End Green ASS - Roundup

Quote:

I'm not really sure why the ASS was involved in this.  I feel like it might have been simpler to just do everything in the ASX model, to keep things cleaner.  Also, the IPC blocks for this stuff (in both ASS and ASX) are not on the top level of the model.  I had thought that this was expressly forbidden (although I'm not sure why).  I'm emailing Jamie, to see if he remembers what, if anything, is breakable if the IPC blocks are down a level.

I'm not sure if it's forbidden by the RCG, but you should definitely NOT do it.  All IO, whether it be between ADC/DACs or IPCs, should always be at the model top level.  That's what keeps things portable, and makes it easier to keep track of where are signals are going/coming from.

  9000   Mon Aug 12 21:27:03 2013 manasaUpdateCDSc1iscex needs help

I started to modify the c1asx model to reduce the RFM model from hitting its max time.
Instead of bringing in ASS, I have modified ASX to do everything and only the clock signals to ITMX pitch and yaw are now going through RFM. RFM is still hitting 62usec and I suppose that is because of the problems with c1iscex.

c1iscex not happy

Cause and symptoms

While restarting the models, c1iscex crashed a couple of times because of some errors and had to be powercycled. The models were modified and they seem to start ok.
But it looks like there is something wrong with c1iscex since the models were started. The GPS time is off and C1:DAQ-DC0_C1X01_CRC_SUM keeps building up even for c1x01 which was left untouched.

Trial treatments

1. Since c1x01 ans c1spx were not touched,c1scx and c1asx were killed and we tried to start the other models. This did not help.
2. Koji did a manual daqd restart which did not help either.

We are leaving c1iscex as is for the time being and calling Jamie for help.

P.S. While making the models, I had created IPCx_PCIE blocks in c1iscex which do not exist. I changed them to RFM and SHMEM blocks. This did not allow me to compile the model and was only spitting errors of IPCx mismatch. After some struggle and elog search I figured out from an old elog that eventhough the IPCx blocks are changed in the model, the old junk exists in the ipc file in chans directory. I deleted all junk channels related to the ASX model. The model compiled right away.

  9002   Tue Aug 13 07:40:53 2013 SteveUpdateCDSc1iscex needs help

 

 Sorrensen ps ouput of +15V at rack 1X9 was current limited to 10.3V @ 2A

Increased threshold to 2.1A  and the voltage is up to 14.7V

Attachment 1: c1iscexSick.png
c1iscexSick.png
  9007   Tue Aug 13 17:20:54 2013 KojiUpdateCDS[Fixed] c1iscex needs help

c1x01 timing issue was solved. Now all of the models on c1iscex are nicely running.

Symptons

- c1x01 was synchronized to 1PPS in stead of TDS

- C1:DAQ-DC0_C1X01_STATUS (Upper right indicator) was red. The bits were 0x4000 or 0x2bad.
  C1:DAQ-DC0_C1X01_CRC_SUM kept increasing

 - c1scx, c1spx, c1asx could not get started.

Solution

- login to c1iscex "ssh c1iscex"

- Run "sudo shutdown -h now"

- Walk down to the x end rack

- Make sure the supply voltages for the electronics are correct (See Steve's entry)

- Make sure the machine is already shutdown.

- Unplug two AC power supply of the machine.

- Turn off the front panel switch of the IO chassis

- Wait for 10sec

- Turn on the IO chassis

- Plug the AC power supply cables to the machine

- Push the power switch of the realtime machine

  9020   Fri Aug 16 21:15:04 2013 ranaUpdateCDSNew/old CDS laptop for X-End

I took the "aso-laptop" and made it into Ubuntu a couple months ago. Today I added it to the Martian network and then moved it to the X End.

I followed the instructions in (https://wiki-40m.ligo.caltech.edu/Network) and added it to the files in /var/named/chroot/var/named on linux1 and did the "service named restart".

The router already had his MAC address in its list (because Yoichi was illegally using his personal laptop on the Martian). The new laptop's name is 'asia'. This is a legal name according to our computer naming conventions and this Wikipedia page (http://en.wiktionary.org/wiki/Category:Italian_female_given_names). It has been added to the Name Pool on the wiki.

The terminal on the laptop still calls itself 'aso-laptop' so I need some help in fixing that. It successfully connects to 40MARS and displays a MEDM sitemap after sshing in to pianosa.

I use 'ssh -X -C' since I find that compression actually helps when the laptops are so far from the router.

  9021   Sun Aug 18 16:04:07 2013 ranaSummaryCDSFB lights all RED: mxstream restart

Sun Aug 18 15:52:50 2013

Found the FB lights (C1:FEC-NN_FB_NET_STATUS and C1:DAQ-DC0_C1XXX_STATUS) RED for everything on the CDS_FE_STATUS screen.

I used the (! mxstream restart) button ro restart the mxstreams. Everything is green now.

PMC was out of lock- relocked it and the IMC locked itself as did the X & Y arms on IR. X was already green locked.

Attachment 1: IFO-Trend.png
IFO-Trend.png
  9022   Sun Aug 18 17:56:16 2013 ranaSummaryCDSMEDM Screen CPU Usages

I noticed at LLO (?) that the LSC screen there uses up ~25-30% of the CPU time on a single core for the control room iMac workstations - this seems excessive.

Here is an accounting of CPU usage percentages for some of our screens:

 

Screen Name CPU (%)
LSC_OVERVIEW 7
ALS_OVERVIEW 0
ALS 1
SUS_SUMMARY 0
IOO_WFS_MASTER 0.3
OPLEV_MASTER 0.5

These were measured using the program 'glances' on rosalba. MEDM running with only the sitemap used up 0.9% of a CPU. With the screens running, the fluctuation from sample to sample could be ~ +/- 0.5%. While the LSC screen seems to be the biggest pig, it is only big in comparison to small pigs. Certainly this pig has gotten bigger after getting sent to Louisiana.

Attachment 1: obama1404_666531c.jpg
obama1404_666531c.jpg
  9066   Mon Aug 26 19:54:15 2013 manasaUpdateCDSc1als model modified

I had made changes to the c1als model a couple of weeks ago. I had removed all the beat_coarse channels that had existed from pre-phase tracker era.

Also, I forgot to elog about it then. This dawned on me only when I found that c1als isn't working the way it should right now.

mistake-cartoon.gif

  9070   Tue Aug 27 15:44:08 2013 manasaUpdateCDSIssues with ALS fixed

I figured out the problem with ALS from yesterday. While the model was just fine, the medm screens were not checked if they were reading the correct channel names. 

The channel names of the ALS input matrix elements had changed when the coarse channels were deleted from the c1als model. So the error signals were not reaching the servo modules as expected. This is why I was not able to make sense as to what the ALS was doing. 

All is fixed now and should be back to normal

  9074   Tue Aug 27 19:34:36 2013 JamieConfigurationCDSfront end IPC configuration

So the IPC situation on the front end network is not so great right now.  For various no-longer-valid reasons, c1lsc had no RFM card, all the IPC connections were routed through the c1rfm model on c1sus, and routed to c1lsc via dolphin PCIe as needed.  As things grew, c1rfm became overloaded.  Koji tried to fix the situation by breaking things out of c1rfm to make direct connections where we could.  This cleared up c1rfm a bit, but not c1mcs is overloading.

Reminder: PCIe (dolphin) is faster and higher bandwidth than RFM.  The more things we can put on PCIe the better.

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends.  By "intended direct" I mean what should be direct connections if we had all the appropriate hardware.  Right now the actual connection graph is more convoluted than this since things are passing through c1rfm.  I note this graph was NOT particularly easy to make, which is very unfortunate.  I had to manually look through every model and determine the ultimate source of every incoming IPC.  Kind of a pain in the butt.  It would be nice if there was a simple way to represent this.

Here are some various solutions to the problem as I see it:

a) put c1lsc on the RFM network

This would allow c1lsc to talk to c1ioo, c1iscex, and c1iscey without having to go through c1sus, thereby eliminating c1rfm altogether.  I'm not sure why we didn't just do this originally.

Requires:

  • One RFM card for c1lsc

b) put c1ioo on the PCIe network (and move c1sus's RFM card to c1lsc)

This is probably the most robust solution.

b1) There are roughly 8 IPCs going from c1ioo to c1sus, and 4 going the other way, and 3 IPCs from c1ioo to c1lsc.  If we put c1ioo on PCIe all of these now RFM connections would become direct PCIe connections, which would be a big win.

At this point only the end station front ends would be on RFM, and most of the connections to those come from c1lsc, so it would make sense to give c1lsc the RFM card, thereby eliminating a lot of stuff from c1rfm.

Requires:

  • dolphin card for c1ioo (do the old sun machines support these?  if they don't we could swap the old sun machine with a new spare aLIGO-approved supermicro machines, which we have spares of)
  • dolphin fibre to go to dolphin switch in 1X3 rack

b2) OR, we could move c1ioo to 1X4 with c1lsc and c1sus, and get a OneStop fibre cable to connect to its IO chassis.  We would still need a dolphin card, but we could use coper instead of fibre.  This is my preferred solution, since it moves c1ioo out of 1X1, where it's really in the way and making a lot of noise.  It would also be easier to manage all the machines if they're together in one rack.

Requires:

  • dolphin card for c1ioo
  • dolphin coper cable for c1ioo
  • OneStop fibre for c1ioo

c) put another cpu in c1sus

c1sus is (I believe) able to support another 6-core cpu.  If we added more cores to c1sus, we could break up c1rfm into c1rfm0, c1rfm1, etc.  This is a less elegant solution imho, but it would probably do the job.

Requires:

  • one new CPU for c1sus
Attachment 1: hosts.png
hosts.png
  9076   Tue Aug 27 20:43:34 2013 KojiConfigurationCDSfront end IPC configuration

The reason we had the PCIe/RFM system was to test this mixed configuration in prior to the actual implementation at the sites.
Has this configuration been intesively tested at the site with practical configuration?

Quote:

Attached is a graph of my rough accounting of the intended direct IPC connections between the front ends. 

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

I personally prefers to give the PCIe card to c1ioo and move the RFM card to c1lsc.
But in either cases, we want to quantitatively compare what the current configuration is (not omitting the bridging by c1rfm),
and what the future configuration will be including the addtional channels we want add in close future,

because RFM connections are really costly and moving the RFM card to c1lsc may newly cause the timeout of c1lsc
just instead of c1sus.

  9077   Wed Aug 28 00:41:23 2013 JenneUpdateCDSCDS svn commits not happening

svn status update. asx, als and ioo were found not committed. Not sure about who modified ioo last after Jenne.

//edit Manasa - edited the/ elog instead of replying //

  9079   Wed Aug 28 05:21:58 2013 manasaUpdateCDSCDS svn commits not happening

I am responsible for missed svn commits with als and asx. I have committed them.

But I have not modified anything with ioo in the last few weeks.

 

  9086   Wed Aug 28 19:47:28 2013 jamieConfigurationCDSfront end IPC configuration

Quote:

It's hard to believe that c1lsc -> c1sus only has 4 channels. We actuate ITMX/Y/BS/PRM/SRM for the length control.
In addition to these, we control the angles of ITMX/Y/BS/PRM (and SRM in future) via c1ass model on c1lsc.
So there should be at least 12 connections (and more as I ignored MCL).

Koji was correct that I missed some connections from c1lsc to c1sus.  I corrected the graph in the original post.

Also, I should have noted, that that graph doesn't actually include everything that we now have.  I left out all the simplant stuff, which adds extra connections between c1lsc and c1sus, mostly because the sus simplant is being run on c1lsc only because there was no space on c1sus.  That should be corrected, either by moving c1rfm to c1lsc, or by adding a new core to c1sus.

I also spoke to Rolf today and about the possibility of getting a OneStop fiber and dolphin card for c1ioo.  The dolphin card and cable we should be able to order no problem.  As for the OneStop, we might have to borrow a new fiber-supporting card from India, then send our current card to OneStop for fiber-supporting modifications.  It sounds kind of tricky.  I'll post more as I figure things out.

Rolf also said that in newer versions of the RCG, the RFM direct memory access (DMA) has improved in performance considerably, which reduces considerably the model run-time delay involved in using the RFM.  In other words, the long awaited RCG upgrade might alleviate some of our IPC woes.

We need to upgrade the RCG to the latest release (2.7)

  9087   Wed Aug 28 23:09:55 2013 jamieConfigurationCDScode to generate host IPC graph
Attachment 1: hosts.png
hosts.png
Attachment 2: 40m-ipcs-graph.py
#!/usr/bin/env python

# ipc connections: (from, to, number)
ipcs = [
    ('c1scx', 'c1lsc', 1),
    ('c1scy', 'c1lsc', 1),
    ('c1oaf', 'c1lsc', 8),

    ('c1scx', 'c1ass', 1),
    ('c1scy', 'c1ass', 1),
... 96 more lines ...
  9137   Wed Sep 18 11:29:43 2013 manasaUpdateCDSDataviewer cannot connect to fb

Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.

When I started dataviewer from the terminal I obtained the following error:

controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.

I restarted fb to see if it made any difference. telnet fb 8088

It hasn't helped. Anything else that can be done??

CDS_FE.png

  9138   Wed Sep 18 11:52:53 2013 JamieUpdateCDSDataviewer cannot connect to fb

Quote:

Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.

When I started dataviewer from the terminal I obtained the following error:

controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.

I restarted fb to see if it made any difference. telnet fb 8088

It hasn't helped. Anything else that can be done??

I've fixed the problem.  This was due to a change I made in the NDSSERVER environment variable so that it would work with cdsutils.  I didn't realize there was an incompatibility with how dataviewer parses NDSSERVER.  Joe and I will have to figure it out.

In the mean time I've changed things back so that that dataviewer should now work as expected.  You might have to log out and back in for it to work (or at least open a new terminal).

  9182   Tue Oct 1 14:12:22 2013 ranaSummaryCDSsvndumpfilter on linux1 makes NFS slow

 Yesterday and this morning's slow NFS disk access was caused by 'svndumpfilter' being run at linux1 to carve out the Noise Budget directory. It is being moved to another server; I think the disk access is back to normal speed now.

  9184   Tue Oct 1 19:42:19 2013 ranaSummaryCDSmegatron upgrade

Max and I started upgrading megatron to Ubuntu 12.NN today. We were having some troubles with getting latest python code to run to support the Summary pages stuff.

Its also a nice test to see what CDS tools fail on there, before we upgrade the workstations to Ubuntu 12.

Since its Linux, none of the usual upgrading commands worked, but after an hour or so of reading forums we were able to delete some packages and all the 3rd party packages and get the upgrade to go ahead. We'll have to re-install the LSC, GDS, LAL repos to get it back into shape and get NDS2 working. The upgrade is running in a 'screen' command on there.


Wed Oct 02 14:50:16 2013 

Update #1: The upgrade asks a couple dozen questions so it doesn't proceed by itself. I've been checking in to the 'screen' every couple hours to type in 'Yes' to let it keep going.


Update #2: It finished a few hours ago:

controls@megatron:~ 0$ uname -a
Linux megatron 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
controls@megatron:~ 0$ date
Wed Oct  2 18:33:41 PDT 2013

ELOG V3.1.3-