40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 68 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  14222   Mon Oct 1 20:39:09 2018 gautamConfigurationASCc1asy

We need to set up a copy of the c1asx model (which currently runs on c1iscex), to be named c1asy, on c1iscey for the green steering PZTs. The plan discussed at the meeting last Wednesday was to rename the existing model c1tst into c1asy, and recompile it with the relevant parts copied over from c1asx. However, I suspect this will create some problems related to the "dcuid" field in the CDS params block (I ran into this issue when I tried to use the dcuid for an old model which no longer exists, called c1imc, for the c1omc model).

From what I can gather, we should be able to circumvent this problem by deleting the .par file corresponding to the c1tst model living at /opt/rtcds/caltech/c1/target/gds/param/, and rename the model to c1asy, and recompile it. But I thought I should post this here checking if anyone knows of other potential conflicts that will need to be managed before I start poking around and breaking things. Alternatively, there are plenty of cores available on c1iscey, so we could just set up a fresh c1asy model...

 
  • (write programming code of making alignment control automatically)
  14238   Mon Oct 8 18:56:52 2018 gautamConfigurationASCc1asx filter coefficient file missing

While pointing Yuki to the c1asx servo system, I noticed that the filter file for c1asx is missing in the usual chans directory. Why? Backups for it exist in the filter_archive subdirectory. But there is no current file. Clearly this doesn't seems to affect the realtime code execution as the ASX model seems to run just fine. I copied the latest backup version from the archive area into the chans directory for now.

  7531   Thu Oct 11 12:11:23 2012 jamieUpdateIOOc1ass with new DAC0 output has been recompiled/install/restarted

I rebuilt/install/restarted c1ass.  It came up with no problems.  It's now showing DAC0 with no errors.

After lunch I'll test the outputs.

  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
  4726   Mon May 16 11:47:59 2011 kiwamuUpdateASSc1ass update part II

The medm screen for c1ass started being modified to be more user-friendly.

The modification is still ongoing, but the goal is to make a screen which anyone can easily understand and play with.

 

Still to do : ( need a volunteer )

- Modification of the screens

- Commission the input beam and X-arm servos

- Make scripts for X-arm

- Measure the PZT mirrors' matrix for the translation and angle

c1ass.png

Quote from #4709

Here the status of the dither alignment or c1ass:

Still to do:

- Commission the input beam and X-arm servos

- Make scripts for X-arm

 

  4709   Fri May 13 00:39:53 2011 valeraUpdateASSc1ass update

Here the status of the dither alignment or c1ass:

- Both pitch and yaw centering on ETMY/ITMY were closed simultatenously with ugf of ~1/30 Hz.

- I made a medm screen with beam positions as measured by the dither system.The snapshot is attached. There are visual perimeter alarms (red box around the display) to warn about arm power being low or the dither lines not being on. The screen has a pull down menu with 4 scripts:

. assUp - sets up the gains, phases and matricies for the dither system (both the spot centering and the input beam alignment)

. assOn - turns on the dithers and servo - just the Y-arm centering part at the moment

. assOff - turns off the servo and dither lines

. assDitherOn - turns on the dither lines but does not turn on the servo

- All scripts are in scripts/ASS and the medm screen is in medm/c1ass/master/

 

Still to do:

- Commission the input beam and X-arm servos

- Make scripts for X-arm

Attachment 1: c1assqpds.jpg
c1assqpds.jpg
  13470   Fri Dec 8 23:31:31 2017 johannesFrogsASSc1ass slow channel offloading scripts with small

While staring at epics records all day I noticed something about the PIT/YAW offset sliders and ASS offset offloading to slow channels scripts that I'm not sure others are aware off, so I'll briefly discuss it in this post.

The PIT and YAW sliders directly control soft channels that are hosted on the slow machine. Secondary epics records disentangle them for the individual coils:

  • UL = PIT+YAW
  • LL = -PIT+YAW
  • UR = PIT-YAW
  • LR = -PIT-YAW

These channels are the direct input for the physical output channels that generate the control voltage.

The fast channels for PIT and YAW have a numerical correction factor built in that accounts for differences between the OSEMs, but the slow channels don't. This means that the slow PIT/YAW controls are not entirely orthogonal but have crosstalk on the order of 10 percent. This in itself is not that dramatic, however the offload offsets scripts for the dither alignment use the fast PIT/YAW values as inputs, which represent the necessary adjustments to the OSEMs only after the individual correction factors have been applied. The offloading to slow knows nothing of this calibration difference between the OSEMs. The result is that there is a ~10 percent of the offset correction error on the mirror alignment AFTER offloading. This will of course converge after a few iterations, but in any case it is recommendable to run the dither alignment again after offloading and not offload the new offsets to the fast channels.

  13476   Thu Dec 14 19:33:20 2017 gautamFrogsASSc1ass slow channel offloading scripts with small

I don't think this is really a problem - we offload to the fast channels and not to the slow (although we really should offload to the slow channels). I think the best approach is to use the ezcaservo utility to offload the DC part of the ASS control signals to the slow channels, so as to not waste fast channel DAC counts on DC offsets. In principle, this approach should be somewhat immune to the slow channel calibration not being perfect.

Quote:

While staring at epics records all day I noticed something about the PIT/YAW offset sliders and ASS offset offloading to slow channels scripts that I'm not sure others are aware off, so I'll briefly discuss it in this post.

The PIT and YAW sliders directly control soft channels that are hosted on the slow machine. Secondary epics records disentangle them for the individual coils:

  • UL = PIT+YAW
  • LL = -PIT+YAW
  • UR = PIT-YAW
  • LR = -PIT-YAW

These channels are the direct input for the physical output channels that generate the control voltage.

The fast channels for PIT and YAW have a numerical correction factor built in that accounts for differences between the OSEMs, but the slow channels don't. This means that the slow PIT/YAW controls are not entirely orthogonal but have crosstalk on the order of 10 percent. This in itself is not that dramatic, however the offload offsets scripts for the dither alignment use the fast PIT/YAW values as inputs, which represent the necessary adjustments to the OSEMs only after the individual correction factors have been applied. The offloading to slow knows nothing of this calibration difference between the OSEMs. The result is that there is a ~10 percent of the offset correction error on the mirror alignment AFTER offloading. This will of course converge after a few iterations, but in any case it is recommendable to run the dither alignment again after offloading and not offload the new offsets to the fast channels.

 

  1981   Thu Sep 10 15:55:44 2009 JenneUpdateComputersc1ass rebooted

c1ass had not been rebooted since before the filesystem change, so when I was sshed into c1ass I got an error saying that the NFS was stale.  Sanjit and I went out into the cleanroom and powercycled the computer.  It came back just fine.  We followed the instructions on the wiki, restarting the front end code, the tpman, and did a burt restore of c1assepics. 

  4680   Tue May 10 16:45:19 2011 josephbUpdateCDSc1ass now receiving AS55I from c1lsc

[Valera, Joe]

We added a cdsPCIx_SHMEM connection between the c1lsc and c1ass models.  This connection is called C1:LSC-ASS_AS55I, and sends the normalized AS55I data to Lockin 11 of the c1ass model.

In addition, in order to get the c1ass model to compile, we had to place all the non-IO parts inside a subsystem block, which we called ASS, and gave the top_names tag to.

The c1lsc and c1ass models were rebuilt, the frame builder restarted, and the models restarted.

  7795   Thu Dec 6 02:55:46 2012 DenUpdateAlignmentc1ass

Today I've set c1ass model to improve alignment of X and Y arms. I've added all measured parameters to ASS scripts. I've also added a script to c1ass.adl that downloads calculated OFFSETs to corresponding ASC filter banks and blocks outputs. It should be called after alignment convergence.

XARM phase rotation and sensing matrix

Demodulator Phase rotation, degrees
ETM_P_T -5
ETM_Y_T -10
ITM_P_T -62
ITM_Y_T 163

                                                           

I-quadrature ETM_PIT ETM_YAW ITM_PIT ITM_YAW
ETM_P_T

1.0000  

-0.6116 -0.560 0.5660
ETM_Y_T -0.1600 1.0000 0.2310 -0.3979
ITM_P_T -0.0794 0.4960 1.0000 -0.8791
ITM_Y_T 0.0624 -0.3903 -0.4787 1.0000

 

Output gains were (-0.5, 0.5, -0.25, -0.25). XARM Gain was set to 0.5.

xarm_ass.png

YARM phase rotation and sensing matrix

Demodulator Phase rotation, degrees
ETM_P_T 10
ETM_Y_T 0
ITM_P_T 107
ITM_Y_T -35

 

I-quadrature ETM_PIT ETM_YAW ITM_PIT ITM_YAW
ETM_P_T

1.0000  

0.3899 -0.515  -0.0309
ETM_Y_T 0.1017 1.0000 -0.3143 -0.5269
ITM_P_T -0.3505 0.0565 1.0000 -0.0945
ITM_Y_T -0.2085 -0.3607 0.6042 1.0000

Output gains were (-0.25, 0.25, 0.7, -0.7). YARM Gain was set to 0.8.

yarm_ass.png

  7796   Fri Dec 7 00:08:39 2012 ranaUpdateAlignmentc1ass

 

 This looks like a good performance tuning for these. It would be good if you can codify this procedure in the wiki so that even unexperienced people can tune up the system after reboots or vacuum work.

Is it possible to have some python scripts automatically measure and set the phases and matrices? If so, can we also run them iteratively so that after the second run we can confirm that they have converged? Then the script can output a short report of numbers telling us how well the system is now tuned.

I suppose that there is also a similar system possible to align the arms in a continuous way; i.e. low level drives and very low bandwidth. Also something fast / slow for the the DRMI.

  7797   Fri Dec 7 02:02:23 2012 DenUpdateAlignmentc1ass

I suppose that there is also a similar system possible to align the arms in a continuous way; i.e. low level drives and very low bandwidth. Also something fast / slow for the the DRMI.

 c1ass was really useful today when we slowly aligned PZT and servo kept arms aligned to the input beam. I think it is possible to automate phase and matrix measurements. DRMI servo will be very useful.

Today I tried to investigate the mode in PRCL and MICH. I locked them but power build-up was only 27. The beam on the POP camera looked like interference of 00 mode and a long strip of fringes. (I wanted to make videocaptures but script is not working - the problem is that it is looking for /usr/lib/*.so.4 libraries but they were updated to *.so.5, I made a few links .so.4 -> .so.5 but this kept going for many libraries, so this should be fixed in a better way). 

We looked at PRM and BS faces and they had the same shape - interference of a circle with a strip. There were also a lot of bright spots all over the frames. Loops were closed and circle was not moving. Strip was oscillating at ~1Hz and also its position significantly changed with alignment. Looking at PRM face camera we made a conclusion that the length of the strip is ~5 cm and width ~1cm. Interesting that strip has plenty of power - approximately 10 times of transmitted beam when cavity is not locked. As a result POYDC was oscillating at the same frequency as a strip.

  898   Fri Aug 29 11:05:11 2008 josephbSummaryComputersc1asc was down this morning
I had to manually reboot c1asc this morning, as for some unknown reason its status was red, and the fiber lights on the board were status:red, sig det:amber, own data: nothing. Shut the crate down, turned it back on, heard a beep, then followed wiki reboot instructions. Seems to be working now.
  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

  8709   Fri Jun 14 17:15:45 2013 ManasaUpdateGreen Lockingc1als model edited

I have edited the daq channels in c1als model.

Added: DQ channels for the error signal (phase tracker output)
Removed: DQ channels that existed for the beat_coarse signals

Installed and restarted the model on c1ioo.
Frame builder restarted.
Changes were committed to the svn. 

  8754   Wed Jun 26 11:32:11 2013 ManasaUpdateGreen Lockingc1als model edited

I have added more DAQ channels to the c1als model. Installed and restarted the model on c1ioo. Frame builder restarted.

DAQ channels added:
C1:ALS-XARM_IN1
C1:ALS-YARM_IN1
C1:ALS-OFFSETTER1_OUT
C1:ALS-OFFSETTER2_OUT

  8760   Wed Jun 26 23:32:15 2013 ManasaUpdateGreen Lockingc1als model edited

I have modified the ALS model to now include PHASE_OUT calibration for both X and Y. MEDM screen has not been edited to include these yet.

c1als_mdl.png

  8761   Thu Jun 27 02:44:33 2013 ranaUpdateGreen Lockingc1als model edited

 Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?

  8769   Thu Jun 27 17:49:17 2013 manasaUpdateGreen Lockingc1als model edited

Quote:

 Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?

The calibration is applied by adding an extra gain. But, I missed the point that I should be doing this outside the phase-tracking loop....my BAD .

So I modified the model such that the calibration is done without disturbing the phase tracking loop.

Right now, epics input 'PHASE_OUT_CALIB' accepts the calibration and we get the calibrated phase tracker output converted from deg to Hz at 'PHASE_OUT_HZ'.  I have also made it a DAQ channel to be used with dataviewer and dtt.

medm screens have been modified to accommodate these additions to the phase tracker screen. I used Yuta's phase tracker calibration data in elog to set PHASE_OUT_CALIB in the medm screens.

ALS_PHASEcalib.png

BEATX_FINE.png

  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.

  10028   Wed Jun 11 16:01:31 2014 SteveUpdateCDSc1Vac1 and c1vac2 rebooted

Quote:

 

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot" (or something like that).  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.

 

 Koji, Jenne and Steve

 

Preparation to reboot:

1, closed VA6, V5 disconnected cable to valves ( closed all annuloses )

2, closed V1, disconnected it and stopped Maglev rotation

3, closed V4, disconnected its cable

   See Atm1,  This set up is insured us so there can not be any accidental valve switching to vent the vacuum envelope if reboot-caos strikes.[moving=disconnected]

4, RESET c1Vac1 and c1Vac2 one by one and together. They both went at once. We did NOT power recycled.

    Jenne entered the new "carma" words on  the old Dell laptop and checked the good answers. The reboot was done.

    Note: c1Vac1 green-RUN indicator LED is yellow. It is fine as yellow.

5, Checked and TOGGLED valve positions to be correct value ( We did not correct the the small turbo pumps monitor positions, but they  were alive )

6,  V4 was reconnected and opened. Maglev was started.

7,  V1 cable reconnected and opened at full rotation speed of 560 Hz

8,  V5 cable reconnected,  valve opened..............VA6 cable connected and opened........

9,   Vacuum Normal valve configuration was reached.

 

Attachment 1: beforeReboot.png
beforeReboot.png
  10596   Fri Oct 10 14:27:44 2014 SteveUpdateCDSc1Vac1 and c1vac2 reboot was a failure

Quote:

Quote:

 

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot" (or something like that).  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.

 

 Koji, Jenne and Steve

 

Preparation to reboot:

1, closed VA6, V5 disconnected cable to valves ( closed all annuloses )

2, closed V1, disconnected it and stopped Maglev rotation

3, closed V4, disconnected its cable

   See Atm1,  This set up is insured us so there can not be any accidental valve switching to vent the vacuum envelope if reboot-caos strikes.[moving=disconnected]

4, RESET c1Vac1 and c1Vac2 one by one and together. They both went at once. We did NOT power recycled.

    Jenne entered the new "carma" words on  the old Dell laptop and checked the good answers. The reboot was done.

    Note: c1Vac1 green-RUN indicator LED is yellow. It is fine as yellow.

5, Checked and TOGGLED valve positions to be correct value ( We did not correct the the small turbo pumps monitor positions, but they  were alive )

6,  V4 was reconnected and opened. Maglev was started.

7,  V1 cable reconnected and opened at full rotation speed of 560 Hz

8,  V5 cable reconnected,  valve opened..............VA6 cable connected and opened........

9,   Vacuum Normal valve configuration was reached.

 

 Yesterday's  reboot was prepared as stated above with one difference. 

  c1Vac1 and c1Vac2 were DOWN before reset. The disconnected valves stayed closed (plus VC1) . This saved us, so the main volume was not vented.

  All others OPENED. PR1 and PR2  rouphing pumps turned ON.  Ion pumps gate valve opened too. The ion pumps did not matter either because they were pump down recently.

  We'll have to rewrite how to reboot vacuum.

  

 

 

 

Attachment 1: c1vac1resetReboot.png
c1vac1resetReboot.png
Attachment 2: c1Vac1&2down.jpg
c1Vac1&2down.jpg
  12115   Wed May 11 16:39:01 2016 ericqUpdateVACc0rga alive, output wonky
Quote:

Our last RGA scan is from February 14, 2016  We had a power outage on the 15th

Gautom has not succeded  reseting it. The old c0rga computer looks dead. Q may resurrect it, if he can?

The c0rga computer was off, I turned it on via front panel button. After running RGAset.py, RGAlogger.py seems to run. However, there are error messages in the output of the plotrgascan MATLAB script; evidiently there are some negative/bogus values in the output. 

I'll look into it more tomorrow.

  1157   Fri Nov 21 21:28:32 2008 ranaSummaryComputersc0daqawg restart
A few minutes after restarting fb0 for the Guralp channels, the DAQAWG lights went red on the DAQ screens.
Why?? I chose revival procedure #3 for c0daqawg from the Wiki and it came back in a couple minutes.
  8280   Tue Mar 12 14:51:00 2013 SteveUpdateComputersbuy warranty or not ?

 Details of the warranties are posted on wiki power supply cost, warranty described, cost

.......I’ve also attached a warranty renewal quote.  A 1 year warranty renewal is usually $.... per year, but we gave you special pricing of $.... / year if you renew both units.  This pricing is also special due to the fact that both warranties expired awhile ago.  We usually require that the warranty renewal begin on the date of expiration, but we will waive this for you this time if both are renewed.

 

JetStor SATA 416S, SN: SB09040111A3 – expired 04/24/2012 (3 years old)

 

JetStor SATA 516F, SN: SB09080016P – expired on 08/21/2012........

 

. Are we keep it for an other 2 years? buy warranty or buy better storage.

 

  1056   Fri Oct 17 21:41:09 2008 YoichiUpdateComputer Scripts / Programsburtwb missing on Solaris but installed on linux64
c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.
  1058   Mon Oct 20 12:18:38 2008 AlanUpdateComputer Scripts / Programsburtwb missing on Solaris but installed on linux64

Quote:
c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.



The automatic backup of /cvs/cds (and /frames/minute-trends ) to the LIGO archive in Powell-Booth,
which runs from fb40m using the scripts in /cvs/cds/caltech/scripts/backup ,
stopped when fb40m was rebooted on June 28, 2008,
and the check_backup script I run to send an email when this happens also failed due to a scripting error.

But we still have a backup of /cvs/cds from June 27.

The backup of /cvs/cds (excluding /cvs/cds/caltech and /cvs/cds/tmp)
circa June 27, 2008
has been restored to
/cvs/cds/recover_20081020 .

Please check to see that it has what we need.

Before moving it over to where it belongs,
it would be really nice to figure out what happened...

Meanwhile, I have fixed the check_backup script and restarted the backup, which will run this evening...
but maybe I should wait till the dust settles?

Now is also a good time to think about whether there is anything else besides for
/cvs/cds and /frames/minute-trends that should be backed up regularly.


- Alan
  4869   Thu Jun 23 22:00:22 2011 JamieUpdateSUSburt snapshot

I recorded a burt snapshot of these settings: /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Jun/23/21:40

  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.

  4053   Tue Dec 14 11:24:35 2010 josephbUpdateCDSburt restore

I had updated the individual start scripts, but forgotten to update the rc.local file on the front ends to handle burt restores on reboot.

I went to the fb machine and into /diskless/root/etc/ and modified the rc.local file there.

Basically in the loop over systems, I added the following line:

/opt/epics-3.14.9-linux/base/bin/linux-x86/burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/latest/${i}epics.snap  -l /opt/rtcds/caltech/c1/burt/autoburt/logs/${i}epics.log.restore -v

The ${i} gets replaced with the system name in the loop (c1sus, c1mcs, c1rms, etc)

  264   Fri Jan 25 09:22:21 2008 steveUpdatePEMburned toast award goes to
DYM for collaborating with the enemy.

In order to minimize the number of ants visiting our lab we have to take out side the lab
all food left over and organic waste. If you are eating here do not expect someone else
to clean up after you.

Thanks for your cooperation.
  1958   Thu Aug 27 16:14:28 2009 steveSummaryOMCburned photodiode

Old -pre 6/2009  LLO DCPD 3 mm od GTRAN photodiode

Attachment 1: 20090827_173252.jpg
20090827_173252.jpg
Attachment 2: 20090827_170802.jpg
20090827_170802.jpg
  7942   Thu Jan 24 16:31:46 2013 SteveUpdatePEMbuilding exterier wall painted

The wood exteier walls, gutters and doors were painted at CES-Annex building #69

Attachment 1: IMG_1880.JPG
IMG_1880.JPG
  17153   Thu Sep 22 20:57:16 2022 TegaUpdateComputersbuild, install and start 40m models on teststand

[Tega, Chris]

We built, installed and started all the 40m models on the teststand today. The configuration we employ is to connect c1sus to the teststand I/O chassis and use dolphin to send the timing to other frontends. To get this far, we encounterd a few problems that was solved by doing the following:

0. Fixed frontend timing sync to FB1 via ntp

1. Set the rtcds enviroment variable `CDS_SRC=/opt/rtcds/userapps/trunk/cds/common/src` in the file '/etc/advligorts/env'

2. Resolved chgrp error during models installation using sticky bits on chiara, i.e. `sudo chmod g+s -R /opt/rtcds/caltech/c1/target`

3. Replaced `sqrt` with `lsqrt` in `RMSeval.c` to eliminate compilation error for c1ioo

4. Created a symlink for 'activateDQ.py' and 'generate_KisselButton.py' in '/opt/rtcds/caltech/c1/post_build'

5. Installed and configured dolphin for new frontend 'c1shimmer'

6. Replaced 'RFM0' with 'PCIE' in the ipc file, '/opt/rtcds/caltech/c1/chans/ipc/C1.ipc'

 

We still have a few issues namely:

1. The user models are not running smoothly. the cpu usage jumps to its maximum value every second or so.

2. c1omc seems to be unable to get its timing from its IOP model (Issue resolved by changing the CDS block parameter 'specific_cpu' from 6 to 4 bcos the new FEs only have 6 cores, 0-5)

3. The need to load the `dolphin-proxy-km` library and start the `rts-dolphin_daemon` service whenever we reboot the front-end

Attachment 1: dolphin_state_plus_c1shimmer.png
dolphin_state_plus_c1shimmer.png
Attachment 2: FE_status_overview.png
FE_status_overview.png
  6830   Mon Jun 18 17:28:03 2012 yutaSummaryComputersbugs in CDS_PARTS/simLinkParts/Fcn

Fcn module in CDS_PARTS is used to include a user defined function in a model.
We should be able to use this by entering desired function, but I found some bugs.

BUG1: Fcn doen't work without ";"

If you put ";" after the function, we can compile.

 sin(u[1]);

But if you put without ";", like

 sin(u[1])

you get the following error message when compiling.

controls@c1ioo
~ 0$ rtcds make c1gcv
### building c1gcv...
Cleaning c1gcv...
Done
Parsing the model c1gcv...
Done
Building EPICS sequencers...
Done
Building front-end Linux kernel module c1gcv...
echo >> target/c1gcvepics/README.making_changes
echo 'Built on date' `date` >> target/c1gcvepics/README.making_changes
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild'

make[1]: Entering directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
make -C /lib/modules/2.6.34.1/build SUBDIRS=/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv modules
make[2]: Entering directory `/usr/src/linux-2.6.34.1-cs'
  CC [M]  /opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: Leaving directory `/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv'
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c: In function 'feCode':
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.c:615: error: expected expression before ';' token
make[3]: *** [/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv/c1gcv.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/rtbuild/src/fe/c1gcv] Error 2
make[1]: *** [default] Error 2
make: *** [c1gcv] Error 1


BUG2: sindeg doesn't work properly

sindeg should work as cosine with input in degrees.
I made a simple model to test this(below).
model_sindegbug.png


Output of the filter module C1:ALS-BEATY_FINE_PHASE goes to "PHASE_in"
sindeg of this goes to C1:ALS-BEATY_FINE_I_ERR
cosdeg of this goes to C1:ALS-BEATY_FINE_Q_ERR

If you sweep the phase input, you should get sin and cos, but you get the following.
cosdeg (C1:ALS-BEATY_FINE_Q_ERR) looks OK, but sindeg (C1:ALS-BEATY_FINE_I_ERR) looks funny. It looks like ~20000 is its period.

dv_sindegbug.png

  1381   Mon Mar 9 23:55:38 2009 OsamuDAQComputersbscteststand and kami1 outside martian

This morning there was a confliction of tpman running on fb40m and kami1. Alex fixed it temporary but Rana suggested it was better to move both PCs outside martian. We moved both PCs physically to the control room and connected to general network with a local router. I believe it won't conflict anymore but if you guess these PC might have trouble please feel free to shutdown.

 

Today's work summary:

 *connected expansion chassis to bscteststand

 *obtained signals on dataviewer, dtt for both realtime and past data on bscteststand with 64kHz timing signal

 

Questions:

Excitation channels are not shown, only "other" is shown.

qts.mdl should run with 16kHz but 16kHz timing causes a slow speed on dataviewer and failing data aquisition on dtt. We are using 64kHz timing but is it really correct?

  10   Tue Oct 23 11:08:20 2007 steveOtherGeneralbrush fires
There are big brush fires around LA
40 days plot show no effect in the 40m lab
Attachment 1: brushfires.jpg
brushfires.jpg
  7656   Thu Nov 1 17:37:00 2012 SteveUpdateGeneralbronze bushing for 40m vac

Suprema- SS clear edge mirror mount 2" diameter is modified for 40m vacuum use. One left and one right handed one. It's adjustment screw housing is bronze! It is not ideal for out gassing.

It will be baked and scanned. If it passes we should use it.

We may need these to bring out some pick-off beams.

Attachment 1: IMG_1764.JPG
IMG_1764.JPG
  7660   Fri Nov 2 03:28:54 2012 ranaUpdateGeneralbronze bushing for 40m vac

Quote:

Suprema- SS clear edge mirror mount 2" diameter is modified for 40m vacuum use. One left and one right handed one. It's adjustment screw housing is bronze! It is not ideal for out gassing.

It will be baked and scanned. If it passes we should use it.

We may need these to bring out some pick-off beams.

 I vote against it. We don't know about the grease inside the screw bushings - scans are not everything if adjusting the screw loosens up the grease. If we need more pick off mirrors lets just make some of the kind that we already use inside for the 2" optics.

  10120   Wed Jul 2 11:47:26 2014 SteveUpdateVACbroken changeover regulator of N2 supply

Quote:

This morning valve condition: V1, VM1, V4 and V5 valves were closed. IFO pressure rose to 1.3 mTorr

It was caused by low N2 pressure.  Our vacuum valves are moved-controlled by 60-70 PSI of nitrogen.

When this supply drops below 50-60 PSI the interlock closes V1 valve. This is the minimum pressure required to move the large valves.

It is our responsibility to check the N2 cylinder pressure supply.

The vacuum valve configuration is back to VAC. NORMAL,  CC1  4.8E-6 Torr

 

PS: Bob says that the second cylinder was full this morning, but the auto-switch over did not happen.

 The TESCOM automatic changeover regulator  [ model ACS 012-1011 ] manifold is most likely  clogged. The new one will arrive 8-8-2014

This means that the IFO pressure may go up to a few mTorr when we change cylinder or V1 valve triggered because there is no nitrogen supply.

  5298   Wed Aug 24 16:13:36 2011 kiwamuUpdateSUSbroke UL magnet on ITMX

I broke the UL magnet on ITMX

The ITMX tower was shipped into the Bob's clean room to put the magnet back on.

 

 Since we found that all the magnets were relatively high (#5296) in the shadow sensors, we decided to slide the OSEM holder bar upward.

During the work, I haven't made the OSEMs far enough from the magnets.

So the magnets and OSEMs touched as I moved the holder.

Then the UL magnets were broken off and fell into the UL coil.

 

  5978   Tue Nov 22 15:18:18 2011 kiwamuUpdateGreen Lockingbroad band noise depends on the gain of Y green PDH. and comaprator broken

Quote from #5970
Here is a plot of the latest noise : high frequency noise is still unknown.

(The broad-band noise vs. gain of the Y end green PDH)

 Last night I was trying to identify the broad band noise which is white and dominant above 20 Hz (#5970).

I found that the level of the noise depended on the servo gain of the Y end green PDH loop.

Decreasing the servo gain lowers the noise level by a factor of 2 or so. This was quite repeatable.

(I changed the gain knob of the PDH box from the minimum to a point where the servo starts oscillating)

 

(Malfunction in the comparator)

  However I had to give up further investigations because the comparator signal suddenly became funny: sometimes it outputs signals and sometimes not.

It seems the comparator circuit became broken for some reason. I will fix it.

  2420   Tue Dec 15 21:39:34 2009 AlbertoUpdateABSLbrief summary of this afternoon's measurements
I took measurements of the open loop gain of the AbsL PLL with the old Universal PDH Box.
I Also measured the filter shape of both the new and the old PDH box.
I'm going to plot the results in a nice form tomorrow morning.
For who's interested, the PLL UGF was at 10KHz.
 
I can't lock the PLL with the new PDH box. Measuring its filter's shape, as suggested by Koji, I found out that it differs from the old one. That despite the fact that the two boxes should share the same circuit schematic. O,r at least, that is what it looks like from the schematics in the DCC.
I need to understand whether that is intentional and, if that was the case, what kind of use  Rich Abbott designed it for.
 
Tomorrow I'm going to post in the elog the filter's transfer functions too.
 
Before leaving the lab I closed the auxiliary laser's mechanical shutter.
  3832   Mon Nov 1 10:17:55 2010 steveUpdateGeneralbreakers relabelled

Pedro of the electrical shop helped to retrace wires from the racks to the breakers. Many wrong labels were replaced. These labels are  still representing                          the south arm as Y and  the east arm as X.

Racks: 1X1,2,3,4 and 1Y3,4,5,6,7 and 9 are connected through manual disconnect swithes to  AC power breaker PC-1 on the west wall of IFO room 104.

             This panel PC-1 is connected to T1 isolation transformer in room 101 Panel L - # 38, 40, 42

Racks: 1Y1 & 2  psl and mc are connected through manual disconnect switches to AC power breaker PC-2 just west of the psl enclosure.

             This panel is connected to T2 isolation transformer in room 101 Panel L - # 32, 34, 36

Attachment 1: P1060970.JPG
P1060970.JPG
Attachment 2: P1060972.JPG
P1060972.JPG
Attachment 3: P1060975.JPG
P1060975.JPG
  456   Sun Apr 27 18:11:58 2008 robDAQComputersbr40m?

The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.

The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:

Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203


If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.
  457   Sun Apr 27 22:57:15 2008 ajwDAQComputersbr40m?

Quote:

The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.

The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:

Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203


If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.


I *think* Alex is responsible for the daqd daemon running on br40m (he set up some new stuff recently, a data concentrator and broadcaster); I'll make sure he sees this post.
  12448   Fri Aug 26 17:48:14 2016 gautamUpdateSUSbounce mode coupling reduction

We worked on reducing the bounce mode coupling into the sensor signals today. After some trial and error, essentially following the procedure I had put up in my previous elog, we think we were successful in reducing the coupling. We have now left the optic free swinging, so that we can collect some data and look at a spectrum with finer bandwidth. But as per the methodology we followed, we saw that the peak height corresponding to the bounce mode increased when we rotated the OSEM either side of its current position (except for the side OSEM, which we felt was in a good enough position to warrant not touching it and messing it up - of course only the spectrum will tell us if we are right or not. I also took some pictures with the camera with the IR filter removed, but we couldn't get any real information from these photos. I also checked with Jenne and Jamie who both suggested that they didn't have any metric with which they judged if the rotation of the OSEM was good enough or not. So we will wait to have a look at the spectrum from later tonight, and if it looks reasonable enough, I vote we move on. As Eric suggested, perhaps we can repalce the UL OSEM coil and see if that solves the apparent UL coil problem. Then we should move on to putting the arm cavity together.

Addendum 11pm 26 Aug 2016: I've uploaded the spectra - looks like our tweaking has gained us a factor of ~2 on LL, LR and SD, and no significant improvement on UL and UR compared to yesterdays spectrum.

Attachment 1: ETMY_BounceSpectra_26Aug2016_1.pdf
ETMY_BounceSpectra_26Aug2016_1.pdf
  8162   Mon Feb 25 21:25:14 2013 yutaUpdateAlignmentboth arms locked in IR

[Jenne, Evan, Yuta]

After Y alignment, X arm is aligned to IR and we got both arms locked in IR.
There's some dift (input pointing?) and this made aligning both arms tough. I will elog about it later.
Attached is ETMYF. ETMXF, ITMYF, ITMXF when both arms are locked by IR.

Alignment Procedure:
  1. Algined BS/ITMX to get MI fringe in AS. We got X arm flashing at this point.
  2. Use BS/ITMX/ETMX to get TRX maximized, without losing good MI fringe in AS. We reached 0.75.
  3. There was clipping of TRX beam at Xend optics. Since whole IFO alignment is started from Y green, this clipping is because of poor Y green pointing. But we needed clear TRX for aligning Xarm, so we re-arranged Xend TRX path to avoid clipping.

X arm issues:
  - Beam motion at TRX is larger than TRY. Turning off clean table air didn't help. Maybe we need BS oplev on or ETMX coil gain balancing.
  - X green scatters into TRX PD and ETMXT camera. Fix them.

Attachment 1: QUAD1_1045890588.png
QUAD1_1045890588.png
  6840   Wed Jun 20 18:09:23 2012 yutaUpdateLockingboth arms aligned, ITMX oplev centered

[Jenne, Yuta]

We aligned FPMI. I also centered ITMX oplev because the light was not hitting on QPD.
Alignment procedure we took was;

1. Align Y arm to the Y end green(Y green trans to PSL is now 195 uW with Y end laser measured temperature 34.14 degC).
2. Aligned IR using PZT2 to Yarm(Now, TRY ~ 0.90).
3. Aligned ITMX monitoring AS spots.
4. Aligned X arm so that TRX maximize.
5. Fine adjusted both BS and X arm(Now, TRX ~ 0.82).

Beam spot position on ETMX looks a little too high & left (from ETMXF camera), but we will leave it until ASS scripts is fixed.

FPMIalignment2010620.png

ELOG V3.1.3-