Displaying reports 72581-72600 of 84513.Go to page Start 3626 3627 3628 3629 3630 3631 3632 3633 3634 End
Reports until 15:20, Tuesday 10 June 2014
H1 ISC (INS, ISC)
corey.gray@LIGO.ORG - posted 15:20, Tuesday 10 June 2014 (12282)
HAM6 Notes: Documentation Redlines, Photos, Cabling Spreadsheet

Corey, Dan, Jeff B, Keita, Sheila

DOCUMENTATION REDLINES

During the HAM6 work from last week, we all noted variances, missing info, errors in documentation as we went.  Just wanted to post my specific list of items I came across.

D1300122:  HAM6 Cable Harness Routing Configutation

  1. Both WFS_AS_A (25-pin cables) are at Flange D3 2C1 & 2 (instead of D5 3C1 & 2)...they follow the Flange Document (D1002877).  (D5 3C1 & 2 is instead being used as a Purge Air Port.
  2. Some Tip Tilts could be labeled better.  Tip Tilt #2 (also named "M2"), is actually connected to what we call Tip Tilt#3 according to the Optics Layout & Flange Layout drawings.  Similarly, Tip Tilt #3 is actually what we call Tip Tilt #2.  This is basically just a naming discrepancy.
  3. For Cable Bracket #1 (CB1), which is located on the OMC Structure, the cable runs occupy opposite Floors on CB1.  We tried to move these cables to the correct floors, but the cables were pretty tight on the OMC, so we opted to keep them as is.  So D1300369/D1000225 is really on CB1's 2nd Floor & D1300376 is actually on CB1's 1st Floor.
  4. The OMC cables were handled/connected at CIT.  I could not determine their serial numbers (perhaps these cables were stamped with s/ns?).

D1000342:  ISC HAM6 Assembly

  1. M7 has a picomotor!  (drawing shows this, but spreadsheet under drawing does not show this)
  2. A variance is that we had to make adjustments to our WFS Sled opitcs & WFS for them to fit correctly on table.

PHOTOS

All photos of installation are in ResourceSpace, here.

Highlights of the work are attached to this alog.  Take special note of the scratches which were observed on a QPD (photos #7 & 8).

CABLING SPREADSHEET

To the best of my ability I made a spreadsheet noting cable serial numbers and where they were used in HAM6.  As noted earlier, the OMC cables were handled at CIT, and I was not able to note their s/n's.  Also, the OMC PZT in-air cable is not connected to the chamber, so it is not noted.  I do make note of the OMC CB floor discrepency noted above, as well as the switch of cables from D5 to D3.  Here is the HAM6 Cable Table:

IN-AIR CABLE CHAMBER FEED-THRU SR CABLES CABLE BRACKET IN-VAC CABLE OMC CB IN-VAC COMPONENT
CAB_H1:ISC_307 D6-F1 D1000225s/nS1106784 .. D1300369s/n?? CB1, 2nd Floor DC PD preamps, OMC
.. D6-F2 D1000225s/nS1106832 .. D1300376s/n?? CB1, 1st Floor PZTs, OMC
CAB_H1:ISC_404 D6-F3 D1000225s/nS1106829 .. D1300373s/n?? CB2, 1st Floor DC QPD, OMC
CAB_H1:ISC_232 D6-F4 D1000225s/nS1106780 CB5, 2ND D1101654s/nS1108061 .. QPD A/B
CAB_H1:ISC_235 D6-F6 D1000223s/nS1202641 CB5, 1ST D1000238s/nS1105053 .. OMC PICO
CAB_H1:ISC_236 D6-F10 D1000225s/nS1106728 .. D1000228s/nS1105236 .. Tip Tilt #1
CAB_H1:ISC_317 D6-F8 D1000223s/nS1202649 CB3, 1ST D1000237s/nS1202732 .. BDV1
CAB_H1:ISC_316 D6-F9 D1000223s/nS1202652 CB3, 2ND D1000237s/nS1202730 .. BDV2
CAB_H1:ISC_234 D6-F7 D1000223s/nS1202643 CB4, 1ST D1000238s/nS1105220 .. ASC_C Picomotors
CAB_H1:ISC_233 D6-F5 D1000225s/nS1106785 CB4, 2ND D1101654s/nS1202409 .. ASC_C_DC QPD
CAB_H1:ISC_238 D6-F12 D1000225s/nS1106830 .. D1000228s/nS1105241 .. Tip Tilt#2 (really #3!)
H1:ISC_RF-26B D5-1D1 D1300278s/nS1301448 .. .. .. WFS-A rf
H1:ISC_RF-27B D5-1D2 D1300278s/nS1301451 .. .. .. WFS-A rf
CAB_H1:ISC_265 D5-3C1-->D3-2C1!! D1000225s/nS1106835 .. .. .. WFS-A
H1:ISC_RF-28B D5-2D1 D1300278s/nS1301449 .. .. .. WFS-B rf
H1:ISC_RF-29B D5-2D2 D1300278s/nS1301453 .. .. .. WFS-B rf
CAB_H1:ISC_266 D5-3C2-->D3-2C2!! D1000225s/nS1106833 .. .. .. WFS-B
CAB_H1:ISC_237 D6-F11 D1000225s/nS1106834 .. D1000228s/nS1105239   Tip Tilt#3 (really #2)
H1:SUS_HAM6-10 D3-1C1 D1000225s/nS1106791 .. D1000234s/n?? CB2, 2nd SUS OMC
H1:SUS_HAM6-11 D3-1C2 D1000225s/nS1106831 .. D1000234s/n?? CB2, 3rd SUS OMC
Images attached to this report
H1 AOS
thomas.vo@LIGO.ORG - posted 14:58, Tuesday 10 June 2014 (12288)
Removing component at ITMX spool

Jason, Apollo, Thomas

We removed the optical lever as well as the camera components for the spool extraction. All the viewports have a lexan protector with a yellow viewport cover with the exception of the two ELIGO TCS viewports which have odd shapes and does not take a yellow cover or a lexan viewport.  These are covered with lens cloth and foil, both secured with cleanroom tape; these particular viewports are going to be taken out and replaced with blanks for ALIGO.

H1 CDS
cyrus.reed@LIGO.ORG - posted 14:58, Tuesday 10 June 2014 - last comment - 11:41, Wednesday 11 June 2014(12287)
Switch Firmware Upgrade Notes
Switch Firmware Upgrade Notes
 
These are the full details of today's switch upgrades.
 
The core switch (sw-msr-core) ROMMON was upgraded from 15.0(1r)SG7 to 15.0(1r)SG10.  This addresses an issue where the switch may drop into ROMMON if the boot process is interrupted by a powercycle if the config-register ends in 0x2.  (We use 0x2102, so it's worthwhile to upgrade).  The IOS was upgraded from XE 3.4.0SG to XE 3.4.3SG.  This includes some fixes for memory leaks, among many other things.
 
The various Cisco C2960-C switches were upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6.  This includes removing support for creation of type 4 password hashes, which were demonstrated to be weaker than the type 5 password hashes they were meant to replace (Crypto is Hard(tm)).  These swtiches are: sw-gc-cdsadmin, sw-mech-aux, sw-psl-aux, sw-mx-aux, sw-my-aux.
 
All Cisco 3560-X switches were likewise upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6, with same notes as above.  In addition there was an ASIC microcode update.  These switches are: sw-ex-aux, sw-ey-aux, sw-lvea-aux, sw-msr-gc, sw-msr-ops, sw-msr-server1, sw-msr-server2, sw-msr-video2.  sw-msr-gc and sw-msr-video2 show an amber SYST LED after reboot indicating some kind of POST failure.  I rebooted sw-msr-video2 and according to the console it passes all the POST tests though the LED remained amber.  These switches appear to be operating, so I will have to look into this more later.
 
The Netgear GSM72XXv2 FE network switches were upgraded from 8.0.1.27 to 8.1.0.36.  This addresses an issue with ssh management access hanging, requiring a reboot to fix, and high idle CPU usage.  These switches are: sw-ex-h1daq, sw-ex-h1fe, sw-ey-h1daq, sw-ey-h1fe, sw-msr-h1fe.  The odd one out, sw-msr-h1daq, is a different model switch and has not exhibited any issues worth fixing as yet.
 
The Fujitsu XG2600 switch that is used to broadcast data between the data concentrator and the rest of the DAQ (sw-msr-h1daqbc) was upgraded from V02.00 to V02.02.  The older version of firmware is no longer available for download, but there are no release notes for the new version to know for sure what changed.
Switch Firmware Upgrade Notes
 
These are the full details of today's switch upgrades.
 
The core switch (sw-msr-core) ROMMON was upgraded from 15.0(1r)SG7 to 15.0(1r)SG10.  This addresses an issue where the switch may drop into ROMMON if the boot process is interrupted by a powercycle if the config-register ends in 0x2.  (We use 0x2102, so it's worthwhile to upgrade).  The IOS was upgraded from XE 3.4.0SG to XE 3.4.3SG.  This includes some fixes for memory leaks, among many other things.
 
The various Cisco C2960-C switches were upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6.  This includes removing support for creation of type 4 password hashes, which were demonstrated to be weaker than the type 5 password hashes they were meant to replace (Crypto is Hard(tm)).  These swtiches are: sw-gc-cdsadmin, sw-mech-aux, sw-psl-aux, sw-mx-aux, sw-my-aux.
 
All Cisco 3560-X switches were likewise upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6, with same notes as above.  In addition there was an ASIC microcode update.  These switches are: sw-ex-aux, sw-ey-aux, sw-lvea-aux, sw-msr-gc, sw-msr-ops, sw-msr-server1, sw-msr-server2, sw-msr-video2.  sw-msr-gc and sw-msr-video2 show an amber SYST LED after reboot indicating some kind of POST failure.  I rebooted sw-msr-video2 and according to the console it passes all the POST tests though the LED remained amber.  These switches appear to be operating, so I will have to look into this more later.
 
The Netgear GSM72XXv2 FE network switches were upgraded from 8.0.1.27 to 8.1.0.36.  This addresses an issue with ssh management access hanging, requiring a reboot to fix, and high idle CPU usage.  These switches are: sw-ex-h1daq, sw-ex-h1fe, sw-ey-h1daq, sw-ey-h1fe, sw-msr-h1fe.  The odd one out, sw-msr-h1daq, is a different model switch and has not exhibited any issues worth fixing as yet.
 
The Fujitsu XG2600 switch that is used to broadcast data between the data concentrator and the rest of the DAQ (sw-msr-h1daqbc) was upgraded from V02.00 to V02.02.  The older version of firmware is no longer available for download, but there are no release notes for the new version to know for sure what changed.Switch Firmware Upgrade NoteThese are the full details of today's switch upgrades.
These are the full details of today's switch upgrades.
 
The core switch (sw-msr-core) ROMMON was upgraded from 15.0(1r)SG7 to 15.0(1r)SG10.  This addresses an issue where the switch may drop into ROMMON if the boot process is interrupted by a powercycle if the config-register ends in 0x2.  (We use 0x2102, so it's worthwhile to upgrade).  The IOS was upgraded from XE 3.4.0SG to XE 3.4.3SG.  This includes some fixes for memory leaks, among many other things.
 
The various Cisco C2960-C switches were upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6.  This includes removing support for creation of type 4 password hashes, which were demonstrated to be weaker than the type 5 password hashes they were meant to replace (Crypto is Hard(tm)).  These swtiches are: sw-gc-cdsadmin, sw-mech-aux, sw-psl-aux, sw-mx-aux, sw-my-aux.
 
All Cisco 3560-X switches were likewise upgraded from IOS 15.0(2)SE2 to 15.0(2)SE6, with same notes as above.  In addition there was an ASIC microcode update.  These switches are: sw-ex-aux, sw-ey-aux, sw-lvea-aux, sw-msr-gc, sw-msr-ops, sw-msr-server1, sw-msr-server2, sw-msr-video2.  sw-msr-gc and sw-msr-video2 show an amber SYST LED after reboot indicating some kind of POST failure.  I rebooted sw-msr-video2 and according to the console it passes all the POST tests though the LED remained amber.  These switches appear to be operating, so I will have to look into this more later.
 
The Netgear GSM72XXv2 FE network switches were upgraded from 8.0.1.27 to 8.1.0.36.  This addresses an issue with ssh management access hanging, requiring a reboot to fix, and high idle CPU usage.  These switches are: sw-ex-h1daq, sw-ex-h1fe, sw-ey-h1daq, sw-ey-h1fe, sw-msr-h1fe.  The odd one out, sw-msr-h1daq, is a different model switch and has not exhibited any issues worth fixing as yet.
 
The Fujitsu XG2600 switch that is used to broadcast data between the data concentrator and the rest of the DAQ (sw-msr-h1daqbc) was upgraded from V02.00 to V02.02.  The older version of firmware is no longer available for download, but there are no release notes for the new version to know for sure what changed.
 
Comments related to this report
cyrus.reed@LIGO.ORG - 11:41, Wednesday 11 June 2014 (12311)

The source of the mystery SYST amber LED on sw-msr-gc and sw-msr-video2 are bad power supply fans; one each per switch, both in PS1.  The fans appear to operate, and come back OK for a while if the supply is reinserted, so they are probably just running out of spec in some fashion.  I'll either swap out the supplies, or see if just the fans can be replaced, as time allows.

H1 SUS (AOS, COC, INS, SYS)
jeffrey.kissel@LIGO.ORG - posted 14:37, Tuesday 10 June 2014 (12286)
Photos (and Video!) From H1 SUS ITMY Install
M. Phelps, T. Sadecki, G. Traylor, B. Weaver, [and J. Kissel as photographer]

Since LHO was disconnected from the outside world this morning, I decided to tag along and recall what awesome installation work is still on-going. Here's a slide show of pictures for the H1 SUS ITMY, BSC3 install [[2014-06-10_H1SUSITMY_Install.pdf]], and I attach some of the highlights as raw images. The movie fits in between photos 3943 and 3949, and captures the move from mounted in the installation arm to staged in-chamber -- download the video from . Congrats on another successful install to Margot, Travis, Gary, and Betsy! 

#positivitytraining
Images attached to this report
Non-image files attached to this report
H1 SUS (ISC)
jeffrey.kissel@LIGO.ORG - posted 12:51, Tuesday 10 June 2014 (12285)
ECR E1400078 M1V&R to M2P&Y Damping Path installed on H1SUSBS
J. Kissel

As per ECR E1400078, I've installed the infrastructure for damping the highest vertical and roll modes of H1 SUS BS (a BSFM triple suspension), sensed at the top (M1) stage, and actuated upon using the middle (M2) stage pitch and yaw drive. Many thanks to Stuart for prototyping; install was as simple as an update to the userapps repository, and then a recompile, reinstall, restart, and restore. A new safe.snap has been captured and committed with the input to the new filter banks turned off. The DAQ was restarted later in the afternoon to account for new channels (and other bugs from the network outage).

This closes out ECR E1400078, and completes integration issue 723.

Once we get back under vacuum, we'll begin to commission the loops in a similar fashion as LLO -- hoping that we have a similar amount of SNR and control authority.

Follow the development story from LLO:
Original Investigation: LLO aLOG 11069
Original Implementation: LLO aLOG 11076
Loop Design Description: LLO aLOG 11233
Reimplementation: LLO aLOG 12973
Integration to Library Parts: LLO aLOG 12991

LHO General
patrick.thomas@LIGO.ORG - posted 10:10, Tuesday 10 June 2014 (12278)
morning meeting notes
HAM6 is fully payloaded. Hugh will unlock and balance the ISI and inspect the cabling.
Keita and Corey are done with HAM6 in chamber work.

ITMY is ready to come out.
ITMX will be installed today.

A first cleaning has been done in the spool area at GV7.
Kyle will install a vacuum pump.
Thomas and Jason will remove the optical lever components. Apollo will remove the optical lever piers.
Apollo will break bolts and remove the annulus piping.
A second cleaning will be done.
The spool will probably be removed tomorrow.

The H1 PSL laser diodes are reaching the end of their life.

Filiberto will be working on SUS watchdog cabling at end Y in addition to the ongoing AA/AI chassis work.

Jeff K. will add damping software infrastructure for the BS.

The storage container for the 3IFO BSC1 needs to be craned into its LTS location. The 3IFO HAM4 and 5 ISIs need to be moved from their shipping containers to their LTS containers.

GV11 and GV18 will be closed for Y2 accumulation pressure measurements.

Temporary plugs will be put in the annulus ports on the HAM5 and 6 door flanges to allow leak checking of the septum between the chambers.

Cyrus is doing maintenance on the CDS switches.
Logbook Admin General
jonathan.hanks@LIGO.ORG - posted 10:02, Tuesday 10 June 2014 (12281)
aLOG maintenance 10:30am pacific (Complete)
Please save or post any aLOG entries prior to 10:30.  I will be rebooting the system to apply patches.

The work is completed
LHO General
patrick.thomas@LIGO.ORG - posted 09:47, Tuesday 10 June 2014 - last comment - 09:52, Tuesday 10 June 2014(12279)
GC networking is currently down


			
			
Comments related to this report
patrick.thomas@LIGO.ORG - 09:52, Tuesday 10 June 2014 (12280)
GC should be back.
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:19, Tuesday 10 June 2014 (12277)
CDS model and DAQ restart report, Monday 10th June 2014

no restarts reported.

H1 SEI
sebastien.biscans@LIGO.ORG - posted 07:19, Tuesday 10 June 2014 (12275)
Watchdogs trips summary - Lock Loss

Here's the presentation that I'll be giving today during the Seismic call.

I'm focusing on lock losses, and how they are linked to the ISIs trips.

Non-image files attached to this report
H1 CDS
cyrus.reed@LIGO.ORG - posted 06:56, Tuesday 10 June 2014 - last comment - 11:23, Tuesday 10 June 2014(12274)
CDS Switch Maintenance Today

I'll be starting work on the CDS core switch soon, as specified in WP4660.  This will impact most network traffic within CDS, and by extension offsite access to CDS.

Comments related to this report
cyrus.reed@LIGO.ORG - 07:58, Tuesday 10 June 2014 (12276)

I have finished with the core switch, and have now started on the other internal CDS switches.  Rebooting the core switch freed the used memory, so it is probably an issue with a slow memory leak.  The subsequent firmware update will hopefully address this.

cyrus.reed@LIGO.ORG - 11:23, Tuesday 10 June 2014 (12283)

I have finished with all of the major work on the switches, there should be no more network interruptions.  The GC offsite network outage was just unhappy coincidence, and was unrelated to the CDS work.

H1 ISC
keita.kawabe@LIGO.ORG - posted 16:34, Monday 09 June 2014 - last comment - 16:38, Monday 09 June 2014(12268)
All electronics tests that needs the HAM6 door to be off was done.

Beam diverters good.

At first neither of two beam diverters worked, using Beckhoff driver. The sensors are good, the motors tried to move but they couldn't fully move the mirror.

We brought a beam diverter testor, and one of them (OMC_REFL_AIR_BDIV) moved slowly, but the other (AS_AIR_BDIV) didn't. The difference between the testor and the Beckhof thing is that the latter has a maximum current set in software, thus the tester is beefier.

When pushing the BDV by hand, it was obvious that the friction was big (and they both squeaked and squauked screeched). I loosened the front/back plate screws to make the plates more aligned with the axle, tightened them, and loosened the axle collar screw so there was more space between the front/back plate and the jewel bearing. This seemed to help, and after doing this for both BDVs the one that worked slowly started moving smoothly, and the one that didn't move started to move.

Switching back to Beckhof, the AS_AIR_BDIV didn't move. After another round of loosening screws and aligning, it finally started moving.

One thing is, open/close logic in AS_AIR_BDIV is reversed, which should be fixed in Beckhof.

Picos good.

We brought a picomotor driver and a testor because ISCT6 is not in position.

At first none of three AS picos (AS_A and AS_B for WFS centering, AS_C for AS QPD centering) worked, but QPD sled picos were good.

We swapped the in-air cable and the AS picos started working. Swapped the in-air cable back and the AS picos still worked.

One of the shafts for the in-air pico DB25 connector on the feed through was bent, and it was kind of hard to screw it in. Maybe the cable was not fully seated because of that.

Anyway, all picos work.

Note to self: M10 is the first pico on the QPD sled cable, M9 is the second.

Comments related to this report
keita.kawabe@LIGO.ORG - 16:38, Monday 09 June 2014 (12273)

Remaining tasks can be done from outside without going into the chamber (unless, of course, something is found to be bad in chamber):

  1. Ground loop check (I don't know/remember which cable was done, but at least we need to do this for newly installed QPD sled and AS_C QPD).
  2. Measure capacitance of OMC PZTs + cables.
H1 ISC
filiberto.clara@LIGO.ORG - posted 16:21, Monday 09 June 2014 (12271)
ISC Electronics - CER
Did not get as far with the modifications of the AA/AI ISC electronics in the CER. All AA/AI units are currently powered off and not connected. Will continue with work tomorrow morning and try to bring them back up around noon.

Filiberto Clara
LHO VE
kyle.ryan@LIGO.ORG - posted 16:20, Monday 09 June 2014 (12270)
Valved-in RGA mounted on BT port Y2-1 at Y-mid
Adhered temp recorder to Y2 BT -> Dumped unpumped volume seen be PT246 dead space into RGA assembly at port Y2-1 -> Isolated turbo pump from RGA -> Opened 10" gate valve -> Energized PT246B (eventually had to "tap" lightly with wrench to get gauge to fire) -> RGA scanning in Faraday MID, amus 2,5,14 and 28 -> will isolate Y2 BT from ion pump tomorrow by hard-closing GV11 and GV18  

This exercise is part of the Y2 pressure accumulation data collection 
H1 SUS
arnaud.pele@LIGO.ORG - posted 14:13, Friday 06 June 2014 - last comment - 17:14, Wednesday 11 June 2014(12228)
X1 QUAD08 TF

[Mark B Jeff B Arnaud P]

Yesterday we did some software debugging in the staging building in order to run transfer functions on the assembled quad 08.
When driving the top mass, we usually monitor the lower stages osems, in both osem and euler basis. For some reason the model running for the quad doesn't record those channels (particularly the ones in the euler basis "WIT_{L/P/Y}_DQ"). We decided not to spend too much time understanding what the model situation was, and instead simply not monitor the lower stages channels during the top mass TFs.

The undamped transfer function measurements for the main and the reaction chain are attached.
 

Non-image files attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 13:12, Tuesday 10 June 2014 (12255)

[Mark Jeff Arnaud]

QUAD08 should be compared to the model called "wireloop"  (=wires from UIM to PUM looping around PUM) instead of the "wire" one (=cable segments between UIM and PUM). The first attachment from the alog above was modified since I was using the wrong model for comparison. With the wireloop model there is still a small discrepancy in the second pitch mode (modeled at 1.33Hz and measured at 1.45Hz). By playing with the d values (defined p7 of T080188) I came up with a good match, cf attachment.

Here are the modified d values for reference :
new_dm = old_dm + 0.7mm
new_dn = old_dn + 0.7 mm
new_d4 = old_d4 - 0.8 mm

Also, after an other round of matlab debugging (pb with channel sampling rates in the matlab scripts, path definitions etc...) we were able to get spectra of TOP and UIM osems, with the suspension undamped. Results are attached in the second pdf.
The only thing to notice is the noise content at high frequencies for the left osem of M0 (cyan curve, 1st page). This might be harmonics from the large 60Hz signal.

Non-image files attached to this comment
arnaud.pele@LIGO.ORG - 18:31, Tuesday 10 June 2014 (12305)

Jeff B Andres Arnaud

This afternoon we tested the noise seen in the left bosem of the main chain. We swapped left and right osem cables (at the osem output), and measured a spectra before and after. When plugging the right channel to the left osem, the noise was still present in the spectra (cf screenshot) meaning the noise comes from the left osem itself.

Second attachment is a comparison of the transfer functions between different "wireloop" quads. The 2nd pitch mode frequency is varying from quad to quad, but the largest discrepancy is on QUAD08.

Images attached to this comment
Non-image files attached to this comment
arnaud.pele@LIGO.ORG - 17:14, Wednesday 11 June 2014 (12319)

[Andres Arnaud]

Today we replaced the left osem of the main chain of QUAD08 in the staging building with an other BOSEM (stolen from one of the 3rd IFO TMS). New OLV were stored, offsets and gains were set in medm.
 Results of individual osems spectra are attached. The M0 LF channel dosen't show the elevated noise seen yesterday anymore

Non-image files attached to this comment
H1 SEI (CDS, SUS)
jeffrey.kissel@LIGO.ORG - posted 11:03, Friday 10 January 2014 - last comment - 16:29, Monday 09 June 2014(9204)
SUS Hardware Watchdog Threshold Test
J. Kissel, R. Bork, B. Abbott, D. Barker

In order to determine a good threshold for the new SUS Hardware Watchdog, we've shaken the ITMY chamber vigorously in various states of excitation. 
In summary, with 
- the HEPI and SUS user watchdogs disabled (actuator and inertial sensors set to un-tripably high values)
- ISI damping, SUS damping, and HEPI loops OFF (I just left the ISI tripped the whole time) and 
- driving HEPI at the limit of its DAC range (in Y, RX, and RZ), 
we shook the suspension (and ISI) enough that I would say "Wow, that's a *lot* of motion; it's giving me the willies. We should cut off SEI excitation after 10-20 minutes of this." 

This level of excitation produces roughly 110 [mV] RMS* from the RMS circuit of the SUS Hardware Watchdog. 
* The Hardware Watchdog currently does not expose the output RMS variables, either to analog or digital, so we've replicated what we believe is the SUS Hardware Watchdog's signal chain in the IOP model for the h1susb123's computer, based on the limited documentation available (namely Fig 4 of T1200306), and the DC gain of 31.2 [V/V] from the SUS Hardware Watchdog Chassis, measured on an identical setup in the H1 DAQ Test Stand (thanks Ben/Rolf!).

My figures of merit were 
- the ISI BLRMS Performance matrices, in which 
     - ST1 was solid red above the 0.3 [Hz] band in XYZ, 
     - ST1 was solid red in all frequency bands, and 
     - ST2 was solid red in all bands in all DOFs
- the QUAD M0 OSEM speed dials (the raw ADC input version), in which (for these particular DOFs of excitation from HEPI)
     - F1, F2, and F3 (which are the L, P, and Y sensors) were swinging quickly over *most* (not all) of their range (which is 0.7 [mm])
     - LF, RT, (which are the V and R sensors) showed signs of abnormally large movement, say 25% of their range
     - SD was moving minimally
- The DAC saturation counter screen for HEPI, which was showing several channels off-and-on saturating
- The ITMY Optical Lever, which was not swinging out of its range, but moving abnormally large, say 50% of its range



For future forensics, the rough times that I had this large excitation going was roughly between 
GPS: 1073411801 and 1073412182
UTC: Jan 10 2014 17:56:25 - Jan 10 2014 18:02:46
PST: Jan 10 2014 09:56:25 - Jan 10 2014 10:02:46 

Drive was 0.1 to 10 [Hz] "uniform" white noise, using three independent awggui sessions, driving channels
H1:HPI-ITMY_ISO_Y_EXC    100000 [cts]
H1:HPI-ITMY_ISO_RX_EXC   100000 [cts]
H1:HPI-ITMY_ISO_RZ_EXC   100000 [cts]

The QUAD, ISI, and HEPI survived admirably (as expected), and after the excitation was turned off, SUS and ISI damping loops were immediately functional again, and it quieted down to normal damped motion with ambient input motion from an unisolated chamber. All software watchdog values have been set back to their nominal values.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:51, Friday 10 January 2014 (9208)CDS, SUS
Regarding what it means for the ISI BLRMS performance matrix elements to be "solid red" -- remember the color corresponds to the ratio of the band-limited RMS of the motion currently and the aLIGO requirement for that stage. If the elements are red, the platform motion is greater than 100x the motion requirement for that isolation stage in that frequency band. For example, the RMS of the 1-3 [Hz] requirement is 6e-12 [m] RMS for ISI ST2, so the motion at ST2 caused by the excitation exceeded 6e-10 [m] RMS. Check out figure 2 of section 3.5 in E990303 for the full requirements, and T1100613 for details of the RMS calculation. I don't think there's specific documentation on the performance matrices themselves. 
jeffrey.kissel@LIGO.ORG - 16:29, Monday 09 June 2014 (12272)CDS, SUS, SYS
Just for posterity, I've trended the former version of the IOP, software watchdog's, RMS output values during this excitation test; see attached. 

Recall that this watchdog's trip threshold had been set arbitrarily at 15000 [ct] RMS. One can see that at this threshold, it would have never tripped for this amount of motion rendering it useless. The maximum (minute trend) peaked at roughly 8500 [ct], half of what the threshold has been for these trigger channels.

This version of the watchdog's RMS algorithm is known to be buggy, ringy, and will be replaced in the next release of the RCG, meaning this test will have to be performed again to properly tune its threshold. 
Images attached to this comment
Displaying reports 72581-72600 of 84513.Go to page Start 3626 3627 3628 3629 3630 3631 3632 3633 3634 End