Displaying reports 58561-58580 of 83395.Go to page Start 2925 2926 2927 2928 2929 2930 2931 2932 2933 End
Reports until 11:52, Thursday 11 February 2016
H1 CDS
david.barker@LIGO.ORG - posted 11:52, Thursday 11 February 2016 (25504)
faster sus computers occasionally glitching SEI and ISC end station models

Most cpu overruns associated with the faster SUS computers (which were installed in the end stations this Tuesday) only glitch the SUS-IOP and SUS-ETMX,Y models. Once in a while the glitch extends to the SEI IOP/ISI model and the ISC/ALS models and also glitches the SUS-TMS and SUS-PI models.

To keep the overview GREEN and help with trending, I have extended my end_station_sus_diag_resets.bsh script to clear these additional models. This script is ran roughly once a minute on opsws16.

H1 SEI
hugh.radkins@LIGO.ORG - posted 11:35, Thursday 11 February 2016 (25503)
WHAM6 ISI should have its Z Position Drive Relaxed/Reset

WHAM6 ISI is lifting itself almost 40um from its free hanging position during isolation.  The drive to the Z actuators is running nearly 2000 cts on average.

What's the issue?  Excess drive ==> excess noise?  Unnecessary heating?  Trip vulnerablility?

The attached plot shows 15 minutes when I deisolated the ISI.  Channel 9 shows the free hang sag position.  This was not so low until the HAM6 work back in April/May when it decidedly dropped.  While I balanced and leveled the platform, maybe we need to bias that work high to deal with thermal sagging.  I don't see it obviously sagging lower over time.  See Channels 14 thru 16 for the vertical drives.

Second attachment is 120 days of the outside temp and the vertical drives.  I'd say there is nice inverse correlation with phase thrown in related to our typical step wise heating response to seasonal temperature changes.

My recommendation is remove some payload to raise the free hang position.  Maybe not to big a deal but the free hang positions of the Vertical CPS are on the low side (Channels 4 thru 6.)  This requires a vent of course so maybe not.

Otherwise, we should accept & show that the OMC position does not care about the 90um shift and reset.

Images attached to this report
H1 General
kiwamu.izumi@LIGO.ORG - posted 05:49, Thursday 11 February 2016 - last comment - 14:03, Thursday 11 February 2016(25501)
Left the interferometer in observing

Evan and I left the interferometer in the observing mode at around 20:00 pm local last night. The ISS 2nd loop now keeps correcting the diffraction power all the time via a feedack loop and maintains it at 8%.

Comments related to this report
kiwamu.izumi@LIGO.ORG - 14:03, Thursday 11 February 2016 (25506)

By the way, we had a difficulty in engaging the ASC soft loops yesterday. Those loops kept dragging the optics to a point where the recycling gain is low enough to unlock the interferometer.

This issue is not resolved yet although we were able to manually engage the loops through a very careful and slow process.

I suspect some part of the interferometer has misaligned in a very subtle way.

 


[The symptoms]

The recycling gain could reach as high as roughly 38 which is more than enough to stably achieve full lock. However, as soon as the guardian came across the ASC_PART3 state, the interferometer unlocked. This happened multiple times yesterday. The error signals for all four soft loops had signals were as big as 0.2 before engaging the loops. Since the error signals are derived from the TRX and Y QPDs, this roughly means that the beam spots on TRX and TRY were off from the optimal by 20% of the QPD range. With these big offsets, once we closed the loops, the interferometer started drifting slowly away from the optimal alignment on a time scale of probably a few minutes which was then followed by rapid decrease in the sideband power in the recycling cavity and the carrier power every where on a time scale of about 10 seconds and then unlocked.

[ I don't think TMSs are culprit]

Then I looked for suspicious drift or jump in the angles of the TMSs in trend because this is very similar to the case we had during O1 (alog 22575). I did not find obvious misalignment with the TMSs in the past few days. In addition, the digital offsets in the TR QPDs seem to have unchanged at least in the past week.

For the record, in the past we had a trouble when the input optics were not well aligned (alog 23538). Looking at trends of those optics, I did not find obvious misalignment in the past few days either. The IM4 TRANS and POP B QPDs seem to have almost the same values as they should be. Performing a full initial alignment sequence did not help this issue either.

[Manual engagement]

Later, we tried engaging the loop manually and succeeded in it. This is just a test and not a permanent solution. We added an intentional digital offset to each loop so as to cancel the large signals at the error points. Then we engaged all the loops with the nominal gains. Since the error signals are already close to zero by the digital offsets, the servo did not really do on the soft degrees of freedom as expected. We then gradually reduced the digital offsets to zero very slowly so that the soft loops come back to the intended operating points. Since we did not want to lose the lock we went very slowly and took about 20 minutes or so to complete the process. Lame.

A good thing is that as we reduced the offsets, TRX, TRY and POP signal kept increasing. This indicates that the QPD signals from TRX and TRY are still good reference point. I conclude that the interferometer is the one which has been misaligned rather than the TMSs. Since the recycling gain can be still as high as 38, the misalignment we are chasing here may be something subtle.

H1 CDS
keita.kawabe@LIGO.ORG - posted 17:59, Wednesday 10 February 2016 - last comment - 12:06, Thursday 11 February 2016(25500)
SR3 cage servo problem comes from high frequency oscillation of the satellite amp (Evan, Keita)

This is yet another followup of Kiwamu's cage servo followup: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=25416

In the attached left panel is a 12-days trend of SR3 signals. Left column is the EPICS version of M3 witness sensors, and PMON is used for the cage servo. Middle column is a DQ-version of the same signal.

At first YMON and PMON were going happy together with DQ version, but at around Feb 02/03 midnight UTC, PMON and YMON got huge at the same time the cage servo went crazy, but WIT_Y_DQ didn't feel it. Later when Kiwamu turned down the cage servo gain, WIT_P_DQ (middle bottom) went back to normal-ish but PMON and YMON didn't.

It turns out that when you look at non-DQ version of these signals (attached middle panel), there are huge lines in all four M3 OSEMs of SR3 at 1.7kHz and its harmonics, totally dominating the RMS (top). Bottom plot shows the comparison between SR3 (green) and PR3 (red), and PR3 doesn't show any of these huge lines.

DQ version is decimated by the frontend, but it seems like PMON (as well as YMON and LMON) are just sparsely sampled version of the fast signals, no filter modules therefore no decimation, thus the high frequency junk directly goes into low frequency (right panel).

In the past, the solution for oscillating satellite amps was to power-cycle them repeatedly until the oscillation stops.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 12:06, Thursday 11 February 2016 (25505)

(Keita, Kiwamu)

Satellite amp power cycled several times, 1.7kHz don't go away, new 1.9kHz oscillation shows up, and it won't go away either. It seems like the entire group of satellite amps are now with 1.7Hz and 1.9kHz lines (e.g attached bottom).

Attached, top blue is before power cycling, red and brown are after several rounds of power cycling, green is when the amp was powered down.

Maybe another round of pwer cycling fest, and if that doesn't do it the satellite amp swap, but not today.

Images attached to this comment
LHO VE
kyle.ryan@LIGO.ORG - posted 16:50, Wednesday 10 February 2016 (25499)
Manually over-filled CP3
1515 - 1600 hrs. local -> To and from Y-mid 

Next over fill to be Friday, Feb. 12th before 4:00 pm
LHO VE
kyle.ryan@LIGO.ORG - posted 16:49, Wednesday 10 February 2016 (25498)
Can't find shorted section of X2-8 beam tube ion pump high voltage cable
Today I cut off the excess length of HV cable at the controller end which included the suspect portion of cable previously noted but the short did not change.  I inspected the length within the raceway in the VEA but nothing looks suspicious.  Thus, all of the length which is accessible looks unremarkable.  There is still 10'-15' that is within EMT conduit in the VEA that could be exposed if pulled through the conduit body at the exterior wall penetration but other than that there isn't much else to do barring pulling another 900' run of "not free" 10,000V rated cable.  

Recall that the ion pump controller was found tripped off several days ago and could not restart the ion pump do to its power limiting feature and can only achieve 500VDC @ 0.5 amps implying 1000 ohms between HV conductors.  This "shorted" resistance value is duplicated with the "Megger" unit, as well as, with the low voltage VOM which measures 1080 ohms.
H1 CAL (CAL)
craig.cahillane@LIGO.ORG - posted 15:39, Wednesday 10 February 2016 (25496)
Response Function Comparisons with Individual Frequency Dependence Systematic Errors Removed
C. Cahillane

There was some concerned voiced by Alan and Peter about the LLO uncertainty budget combined with the systematic error corrections at around 100 Hz at gpstime = 1126259461.
This post is merely to mirror the study I did at LLO with a similar one at LHO explaining why we do not see the LLO 'hump' at LHO.  See LLO aLOG 24796
I have included the LHO C01 vs C03 response functions systematic error and statistical uncertainty plot. (See PDF 1) 

I began with the "perfect" C03 version of calibration response which includes all systematic corrections.  Then, one by one I removed each systematic correction and compared it to the original C03 response: (See PDF 2)
Sensing:    C_r (Plot 1)
Actuation:  A_tst, A_pum, and A_uim (Plot 2, 3, and 4)
Kappas:     kappa_tst, kappa_pu, kappa_C, and f_c (cavity pole) (Plot 5, 6, 7, and 8)

So you don't have to go through and view every plot yourself, I have compiled all of the systematic error values at 100 Hz for each of the parameters:
C_r = 0.98932
A_{tst} = 1.0018
A_{pum} = 0.99381
A_{uim} = 1
kappa_{tst} = 1.0251
kappa_{pu} = 0.99465
kappa_C = 1.002
f_C = 1

Total Syst Error = +0.0068

So the total systematic error at 100 Hz is < 1% because it is countered by the C_r, A_pum, and kappa_pu systematic errors.
Non-image files attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 14:53, Wednesday 10 February 2016 (25495)
CDS model and DAQ restart report, Friday - Tuesday 5th-9th February 2016

model restarts logged for Tue 09/Feb/2016
2016_02_09 10:05 h1psliss
2016_02_09 10:23 h1broadcast0
2016_02_09 10:23 h1dc0
2016_02_09 10:23 h1nds0
2016_02_09 10:23 h1nds1
2016_02_09 10:23 h1tw1

2016_02_09 10:42 h1sysecaty1plc3sdf
2016_02_09 10:43 h1sysecaty1plc3sdf
2016_02_09 10:45 h1sysecaty1plc2sdf
2016_02_09 10:49 h1sysecaty1plc1sdf
2016_02_09 10:50 h1sysecatx1plc3sdf
2016_02_09 10:52 h1sysecatx1plc2sdf
2016_02_09 10:53 h1sysecatx1plc1sdf
2016_02_09 10:54 h1sysecatc1plc3sdf
2016_02_09 10:56 h1sysecatc1plc2sdf
2016_02_09 10:58 h1sysecatc1plc2sdf
2016_02_09 10:59 h1sysecatc1plc1sdf

2016_02_09 11:50 h1iopsusey
2016_02_09 11:52 h1susetmy
2016_02_09 12:02 h1iopsusey
2016_02_09 12:02 h1susetmy
2016_02_09 12:03 h1iopsusey
2016_02_09 12:03 h1susetmy
2016_02_09 12:04 h1susetmypi
2016_02_09 12:04 h1sustmsy
2016_02_09 12:28 h1iopsusey
2016_02_09 12:28 h1susetmy
2016_02_09 12:28 h1sustmsy
2016_02_09 12:29 h1iopsusey
2016_02_09 12:29 h1susetmy
2016_02_09 12:29 h1sustmsy
2016_02_09 12:30 h1susetmypi
2016_02_09 12:35 h1hpietmy
2016_02_09 12:35 h1iopseiey
2016_02_09 12:35 h1isietmy
2016_02_09 12:37 h1alsey
2016_02_09 12:37 h1caley
2016_02_09 12:37 h1iopiscey
2016_02_09 12:37 h1iscey
2016_02_09 12:37 h1pemey
2016_02_09 13:27 h1iopsusex
2016_02_09 13:27 h1susetmx
2016_02_09 13:27 h1susetmxpi
2016_02_09 13:27 h1sustmsx
2016_02_09 13:28 h1hpietmx
2016_02_09 13:28 h1iopseiex
2016_02_09 13:28 h1isietmx
2016_02_09 13:42 h1susetmx
2016_02_09 13:46 h1iopiscex
2016_02_09 13:46 h1pemex
2016_02_09 13:48 h1alsex
2016_02_09 13:48 h1calex
2016_02_09 13:48 h1iscex

Maintenance day. New PSLISS code, new Beckhoff C1PLC2 code and associated DAQ restart.

New Beckhoff SDF system code install.

Install of faster SUS computers at both end stations, required restart of all Dolphin attached computers for SEI and ISC.

model restarts logged for Mon 08/Feb/2016 No restarts reported

model restarts logged for Sun 07/Feb/2016 No restarts reported

model restarts logged for Sat 06/Feb/2016 No restarts reported

model restarts logged for Fri 05/Feb/2016 No restarts reported

H1 IOO
cheryl.vorvick@LIGO.ORG - posted 14:14, Wednesday 10 February 2016 (25494)
IO IM2 shaking vs alignment change data summary

IM2's alignment changes after a shaking event (ISI trip) such that the alignment drive is unchanged, but the pointing of the optics (as measured on OSEMs) is different.

These jumps in alignment are anywhere from 5urad to 42urad in pitch.

IM2 is the most effected, but IM1 and IM3 also show this behavior.

I've looked at six shaking / alignment change events, and recorded the amount of motion (shaking) the optic, ISI, and HEPI experienced.

The results shows that the amount of HEPI-ISI shaking can vary during an event that results in a change in IM2 alignment.

What is consistant is the average amount the optic shakes (pitch plus yaw divided by two) to produce a jump in alignment are between 2.1 and 6.1 urad of optic alignment change per urad of average optic shaking.

This suggests the conclusion that optic shaking is the cause of the alignment change, however, in looking at a few events where the optic tripped but HEPI and ISI didn't, I have not seen a significant alignment change, so this part of the IM alignment jump investigation is ongoing.

Based on my curent data, the mechanism that creats and alignment jump on IM2 is a combination of optic shaking and HEPI-ISI shaking.

Non-image files attached to this report
H1 CDS
patrick.thomas@LIGO.ORG - posted 13:57, Wednesday 10 February 2016 - last comment - 16:25, Wednesday 10 February 2016(25493)
Stopped Conlog test on conlog-test-master
Feb. 10 2016 ~ 21:51 UTC Stopped Conlog process on conlog-test-master. Had connected to channels on Feb. 3 2016 16:38 UTC (alog 25344).
Comments related to this report
patrick.thomas@LIGO.ORG - 16:25, Wednesday 10 February 2016 (25497)
Feb. 11 2016 00:04 UTC Reconnected and disconnected to ~ 99,614 channels a couple of times. Left connected to 99,614 channels.
H1 SEI
jim.warner@LIGO.ORG - posted 13:47, Wednesday 10 February 2016 (25492)
High UGF loops for HAM1 HEPI

Before O1, LLO installed some high UGF loops and blend filters on their HAM1 HEPI, in an attempt to better isolate some of the steering mirrors in HAM1. When I tried here, I found that our HAM1 piers weren't as stiff as LLO's in some DOF's because the piers had never been grouted. The grouting was done during O1, and Hugh got new tf's over a couple of down days. I just finished working through the commissioning scripts and have some higher UGF loops to install. These higher UGF loops are needed in order to get sufficient gain at a few hertz. Attached is a pdf of the loops. I'll wait for a convenient maintenance day to try installing.

Non-image files attached to this report
H1 CDS (SUS)
david.barker@LIGO.ORG - posted 12:36, Wednesday 10 February 2016 (25491)
SUS BS M2_LOCK_L filter loaded yesterday evening, looks like a scripting bug

After removing all partial filter loads yesterday during maintenance, I noticed today that SUS BS_M2_LOCK_L had been loaded. On further investigation I found that the H1SUSBS.txt filter file has not been changed since 20th January. So the front end is reporting a load, but there is no archived filter file since no actual filter change was made.

Conlog says that BS_M2_LOCK_L was loaded 18:50:13 PST last night (writing 1 to RSET performs a load) and then had its history cleared fifteen seconds later at 18:50:28  (writing a 2 to RSET clears history).

This looks like it could be a scripting or guardian bug, We should not be loading filters automatically.

I have performed a full filter load on SUS-BS to see if this comes back again.

H1 AOS
corey.gray@LIGO.ORG - posted 11:41, Wednesday 10 February 2016 (25490)
Cleaned Up Dust Monitor Alarm Handler

Following Hugh's clean up of the VAC screen from yesterday, I went through the exercise of editing the Alarm Handler file for dust.alhConfig (located at /optrtcds/userapps/release/cds/h1/alarmfiles).  It actually wasn't that painful.

So now we have NO open (i.e. constantly ON) alarms for the Alarm Handlers (yay!), and should address any audio alarms and new & real.

For the DUST alarm handler, I commented out the following:

We can add any new ones fairly easily.  For instructions on alarm handler editting, go here.

LHO VE
john.worden@LIGO.ORG - posted 08:55, Wednesday 10 February 2016 (25486)
Y END Getter Pump Regen

Gerardo performed a regen on the YEND non-evaporable getter(NEG) pump yesterday. The plot attached shows a 25% reduction in pressure in the end station pressure.

The last regen was performed in July prior to O1. Impressive performance for such a small package.

Images attached to this report
H1 General
bubba.gateley@LIGO.ORG - posted 07:41, Wednesday 10 February 2016 (25484)
FIRE PUMP RUNNING THIS MORNING
As I was doing my usual morning rounds, I discovered one of our main fire pumps running, apparently ran overnight pumping a large amount of water into the desert. I shut the pump down.
Richard had the HFD onsite yesterday so they were probably testing something that initiated the fire pump start. Someone should be informed when HFD completes their work and is ready to leave the site. This is not the first time this has happened.

I also found the door left open on the grey storage container located out by the water tank, again, apparently overnight. I checked for critters and did not see any large ones but could be some small ones trying to find a new home. I closed the door. If you remove things from the containers, PLEASE close the door when you are finished. If you are not able to close the door, contact me and I will be happy to close them for you. 
H1 ISC (ISC)
jenne.driggers@LIGO.ORG - posted 22:19, Tuesday 09 February 2016 - last comment - 08:48, Wednesday 10 February 2016(25480)
Something wrong with DARM loop

I'm not sure if the ESD changes today (alog 25468) are at fault, or if something else has changed today, but I cannot lock ALS Diff using the nominal loop. 

In order to lock ALS Diff, I have included a gain of 0.001 in the DARM2 filter bank (usually just has gain of 1, no filters yet).  Also, I have commented out the line in the Diff guardian that turns on DARM1 filters 2 and 3 (an integrator and resG respectively).  I can turn the DARM2 gain up to 0.002 or 0.004 most of the time, but at 0.006 the DARM loop starts to ring up over 2-3 seconds until we saturate the ETMX L3 coils.  Even at the very lowest teensy-tiny gain, I can't turn on either the integrator or the resG. 

There is so very little gain here that I can't measure the DARM loop in the 10-100 Hz band. 

Unsurprisingly, this means that Diff is too noisy to hold the Yarm anywhere in particular, so I can't move on with the locking sequence (with the thought that it would all be okay if I could get far enough to transfer to RF DARM). 

I am reverting my changes (uncommenting line 228 in ALS diff guardian and gain to 1 for DARM2 bank).

 

I'm calling it a night since I'm running low on ideas.

Also, Kiwamu straightened me out about the DARM filter module screen situation - the auto-generated screens live in the OMC folder.  He'll fix the overview screen tomorrow.

Comments related to this report
daniel.sigg@LIGO.ORG - 05:13, Wednesday 10 February 2016 (25482)

One should check for high frequency saturations. The ALS DIFF signal is fairly noisy and with the new wide bandwidth ESD we might have too much noise at ~kHz..

evan.hall@LIGO.ORG - 06:42, Wednesday 10 February 2016 (25483)

The digital compensation logic for the high-range ESD state is not correct.

In the high range state, the low-noise path is disconnected by a switch, so the analog PI RC network does not enter the overall TF of the driver. Therefore, we do not need to compensate its p/z pair (now 3.2 kHz / 67 kHz). However, the digital logic will still engage this p/z compensation unless you manually disable it (i.e., turn off the antiAcq filter in the ESD SFMs).

Turning off this filter allows DIFF to lock.

During the run, we ran with the binary I/O logic disabled (state request = −1), and the antiAcq filter off. This was changed during maintenance day on 19 Jan, after which point we were incorrectly compensating for this nonexistent p/z pair. This probably also explains the continual EX saturations that appeared during DRMI locking a few weeks ago.

keita.kawabe@LIGO.ORG - 08:48, Wednesday 10 February 2016 (25485)

It should have been digital sign flip.

Old filter was also incorrect in EX and was much more aggressive than the new one, so the HV driver saturation is not the reason that the IFO didn't lock.

The real issue is, when I changed the number of poles (from 1 to none because it went too high due to the hardware change), the sign of the digital TF unintentionally flipped. It's hard to read the sign flip by just looking at the gain-normalized zpk expression in foton (i.e. "n (Hz/norm)"), you need to look at something else e.g. "s" or "f" expression or the bode diagram:

Old one: zpk([152], [3250], 1, "n") in Hz/norm = zpk([-955], [-20420], 21.38) in s (red in the attached)

New one: zpk([3225, [], 1, "n") in Hz/norm = zpk([-20263.27], [-32768], -1.617) in s (blue in the attached)

This of course applies to both EX and EY, so even if with the filter disabled for EX, handing off to EY would break the lock.

New filter with correct sign was made, saved and loaded to the frontend: zpk([3225, [], -1, "n") in Hz/norm = zpk([-20263.27], [-32768], 1.617) in s.

Images attached to this comment
H1 ISC
evan.hall@LIGO.ORG - posted 01:15, Sunday 07 February 2016 - last comment - 11:32, Wednesday 10 February 2016(25431)
DARM offset noise test

Summary

Varying the DARM offset by a factor of 2 has no effect on the unexplained noise above 70 Hz.

Details

Nominally we run with 20 mA of DCPD sum current, which (with an optical gain of 3.2 mA/pm) corresponds to a DARM offset of 13 pm. I took quiet data (15 minutes at a time) with sum currents varying from 10 to 40 mA, which corresponds to DARM offsets from 9 to 18 pm.

Thanks to the automatic gain scaling that Dan and Stefan installed before O1, no manual gain adjustment is needed either for the DARM loop or the calibrated freerunning channels. At each offset, I remeasured the DARM OLTF just to be sure.

I did not adjust the SRCL feedforward during this test, and indeed the coherence below 70 Hz between DARM and the SRCL control signal is increased at DARM offsets other than 13 pm. At 40 mA sum current, the coherence is >0.3 from 25 to 40 Hz. Therefore, the excess noise below 70 Hz during this test is due almost certainly to the SRCL feedforward becoming mistuned.

Non-image files attached to this report
Comments related to this report
rana.adhikari@LIGO.ORG - 11:32, Wednesday 10 February 2016 (25489)

also true for the opposite sign of the offset?

Does the SRCL or MICH noise change during the DARM offset changes?

H1 SEI
hugh.radkins@LIGO.ORG - posted 16:10, Friday 11 December 2015 - last comment - 11:22, Wednesday 10 February 2016(24130)
HAM3 ISI GS13 Gain Switch Study

On Wednesday TJ and I tripped the ISI several times executing the HAM3 ISI GS13 gain switch in various ways.  I have several examples to look at but here is a comparison of one trip to a successfull switch of the gains using the SEI COMMAND perl script.

The first attachment has 20 seconds of the trip example next to the switch that does not trip.  It looks like there isn't anything different going on before the two cases: There are larger swings in X & Y in both and the other DOFs all look fairly similar too.  There is a larger glitch 5+ seconds before the trip in Z but that seems to be settled by the switch/trip time; these would be related to Reference Position ISO servoing.

In the second attachment, again side by side are the two cases zoomed in a bit closer (10 sec.)  The two stage switch by the perl script is evident with the gain switch doing more glitching and the whitening stage doing nothing.  There is a delay of the sensors wrt to the switching by the guardian which seems weird but I'm not looking at outputs from the filter bank as we have no DQ channels here...  These channels are the inputs to the blend bank after transforming to cartesian basis.   Again, nothing stands out as to why there is a problem with the guardian script.  We (TJ & I) did adjust the guardian code to separate the FMs switching like the perl script does but it still tripped the ISI.

The third attachment is a close zoom in on the ISI trip switch.  It is what it is...  Given that the Y and RZ are the dofs that ultimately go big, I'll suspect the horizontals but I could be fooled.

Images attached to this report
Comments related to this report
hugh.radkins@LIGO.ORG - 17:40, Friday 11 December 2015 (24133)

4 trips of the ISI with Guardian. Three are H3 and one is V3.  Problem with corner 3?

I thought I had a trend going seeing the only excursion hitting the trip level on H3 first (see first three attachments.)  Watch the channel colors as I added a channel but they are all H3.  The fourth plot shows that the V3 sensor goes to the rail and causes the trip.  If I saw a bunch more instances and they all hapened on corner3 I'd be very suspicious of bio switching or something; as it is I'm just suspicious.

The fifth plot compares the switching sequence on the six sensors between the COMMAND perl (left) and the Guardian (right.)  Yes, the perl script does manage to hit the switches all at once whereas the guardian is clearly spaced in time.  Of course, guardian manages to switch these on all the other platforms (except HAM2) without problem.  Hmmmm.  I'd like to work HAM2 over too and see wwhat that tells us.

Images attached to this comment
hugh.radkins@LIGO.ORG - 11:22, Wednesday 10 February 2016 (25487)

Actually, we, TJ & I, are getting confused as to which of the above is guardian or perl as we mucked with the guardian code.

We think the one on the right is guardian with sleeps between the switches trying to mimic the perl Command script shown on the left.

Displaying reports 58561-58580 of 83395.Go to page Start 2925 2926 2927 2928 2929 2930 2931 2932 2933 End