Displaying reports 61301-61320 of 77278.Go to page Start 3062 3063 3064 3065 3066 3067 3068 3069 3070 End
Reports until 17:40, Monday 02 February 2015
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 17:40, Monday 02 February 2015 (16423)
End station ISC front end models ready for tomorrow's change

Daniel, Jim, Dave:

WP5034. We have changed the PEM, CAL and ISC models for EX and EY and created the new ALS model. For this week's test, CAL will be integrated into PEM and the ISC model split into two (ISC and ALS). The IOP and ODC models will remain unchanged. 

We have compiled the models h1iscex, h1alsex, h1pemex, h1iscey, h1alsey, h1pemey against a modified H1.ipc file. We have not performed "make install" and have reverted back to the running H1.ipc overnight.

H1 General
travis.sadecki@LIGO.ORG - posted 16:00, Monday 02 February 2015 (16417)
Morning meeting notes and OPS shift summary

Morning meeting:

SEI running TFs as target of opportunity for feedforward on all ISIs

Krishna will be here this week for BRS work at EX

HEPI pumpstation work

TJ working on RM and OM SUS Guardians

Jamie will be here this week working on Guardian

Matt Heintze will be here this week for 3IFO work

Beamtube cleaning ongoing

Bubba working on 3IFO purge plumbing in LVEA

 

OPS Shift Summary:

6:30 Cris and Karen to LVEA

8:19 Karen to EY, Cris to EX

8:23 Ken working on air handlers at EX and EY

8:50 Corey to squeezer bay

8:51 Ken to EY

8:51 Bubba to LVEA H2 input area

9:05 Corey done

9:19 Jodi to mid stations

9:23 Karen done

9:33 JeffK, Krishna, and Hugh to HEPI pumpstation

9:40 Jodi back

10:06 JeffK, Krishna, and Hugh done

12:00 Ken to EX HVAC work

13:48 Ken done at EX

13:54 Fil to MY for parts hunt

14:24 Fil done
 

I locked both arms with green this morning, and attempted to lock DRMI, but was foiled due to sneaky filter settings and constantly changing methodology (unable to follow OPS instructions due to changes by commissioners).

H1 SEI (DetChar)
jeffrey.kissel@LIGO.ORG - posted 15:53, Monday 02 February 2015 - last comment - 17:22, Monday 02 February 2015(16419)
Field HPI Pump Servo Sensor Inputs Terminated
J. Kissel, H. Radkins

Hugh and I continue to investigate the corner station HEPI pump servo noise at its source. As such, we've switched the servo OFF and terminated the two pressure sensors used for the loop error point (read in as H1:HPI-PUMP_L0_BSC2SUP_PRESS, and H1:HPI-PUMP_L0_BSC2RET_PRESS) with 100 [ohms] at 3:45 pm (23:45 UTC). The hope is to quantify the servo's ADC noise floor. We intend to leave it in this configuration for an hour or so before restoring it. Meanwhile, Hugh continues to manually maintain the pump pressure (though very little has been required but for a few 1 [ct] tweaks).
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:22, Monday 02 February 2015 (16421)DetChar
Pressure sensors have been reconnected at 2015-02-02 5:01pm PST (2015-02-03 01:01 UTC), and pump servo turned back ON at 5:20pm PST (01:20 UTC).
H1 SEI
hugh.radkins@LIGO.ORG - posted 14:45, Monday 02 February 2015 - last comment - 15:57, Wednesday 11 February 2015(16416)
WHAM6 ISI GS-13s are in Low Gain so as to not trip when the AS port Shutter fires. Are we ADC noise limited? It appears we are.

The first attachment is a time series of the HAM6 Watchdog, the Fastshutter State, and a GS-13 trace on HAM6.  The switch to low Gain is clear on this last trace.  This is a 5 day trend and the ~20 minutes needed to get the below .005Hz BW data is comfortably unmolested by the ISI or the fastshutter--the start times of the Spectra calculations begin at the vertical black lines.  As for ISI trips and shutter fires--there were none.

The High Gain Spectra period begins at 0800utc on 29 Jan, the Low Gain Spectra begins at 0800utc 1 Feb.

The second attached graph has Horizontal GS13s on HAM6 in High and Low Gain on the upper plot.  The Verticals are in the lower plot. High Gain Spectra is Dashed, Low Gain traces are Solid.  Also shown is our ADC noise in counts.

One caveat is that the ground motion is different at the two times.  The third attachment shows the Cartesian DOFs for the HAM6 GS-13s in the upper two plots and the ground noise in the bottom plot.  We've had a ground motion decrease in the microseism frequencies and below during the low gain period.  You can see the Low Gain Spectra are at the ADC level below 50mHz.  And the 10x signal reduction expected is more like 5x below these frequencies.  If this conclusion passes mustard, we'll have to revisit the GS13 triggering delays/levels.

DTT template is /ligo/svncommon/SeiSVN/seismic/Common/MatlabTools/HAM6_GS13_GainNoiseTest.xml

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 20:18, Monday 02 February 2015 (16425)
J. Kissel, H. Radkins

Which GS13 gain/whitening configurations are the "right" gain configurations? 
How many times have we asked this? 
Hugh is trying to settle this once-and-for-all with quantifiable results like the above entry, but I relay the history and current problems with the GS13 gain / whitening switching below.

The GS13 Interface Board (D1002706), used for both HAM and BSC ISI GS13s (in D1000067 and D1002432, respectively), has two *independent* switches: one for an analog whitening filter (switching between a flat gain of 1, or a zero:pole filter of 10:50 [Hz] -- a gain of 1 at low-frequency, 5 at high frequency), and one for analog gain (switching between a flat gain of). Thus, there are four possible gain/whitening states for this interface board. See attached visual aide.

These two states are compensated for digitally in FMs 4 and 5 of the GS13INF banks, by the difference between the two states (the overall gain of 2 is folded into the calibration filter). FM4 is the switchable gain compensation, FM5 is the switchable compensating de-whitening filter. The front-end code for the HAMs and BSCs is set up that these digital banks control the analog switching. 
- When FM4 is ON, the gain switch is HI (or a binary output of 1), so the analog gain is 2, and FM4 compensates the gain of 10 difference. 
- When FM4 is OFF, the gain switch is LO (or a binary output of 0), so the analog gain is 20.
- When FM5 is ON, the analog whitening is LO (or a binary output of 0), so there is no whitening, and FM5 compensates the z:p = 50:10 difference. 
- When FM5 is OFF, the analog whitening is HI (or a binary output of 1), so the whitening is engaged.

A long time ago, Brian had performed a design study (see G1000412) that had suggested (on pg 24-25) that
"Low Gain Mode [is] good enough to get close to requirements at all [frequencies] above 300 [mHz], tilt[-horizontal] coupling [from vertical GS13 noise turning into RX & RY, which causes X & Y].
[In] High Gain Mode, ADC noise is at least 2x below the sensor noise at all frequencies."
where he defines 
"Low-gain is DC gain of 2, with a zero at 10 [Hz], pole at 50 [Hz]"
and
"High-gain is fixed gain of 12 (input stage of 6)."
Clearly the later statement is now out-of-date with respected to the current revision of D1002706, but the intention is clear -- 
HI Gain = analog gain ON, analog whitening OFF (FM4 OFF, FM5 ON)
LO Gain = analog gain OFF, analog whitening ON (FM4 ON, FM5 OFF)
Indeed -- that a "Gain of 10" and "No Whitening" is the "nominal" configuration is now written directly surrounding the circuit in the schematic D1002706.
Why? Because 
- having *no* whitening or additional gain (i.e. FM4 and FM5 ON, or an overall interface response of a flat gain of 2), you'll likely be buried in the ADC noise floor at all relevant frequencies, and
- having *both* whitening and additional gain (i.e. FM4 and FM5 OFF, or an overall interface response of low-frequency gain of 20 and high-frequency response of 100, with a z:p pair at 10:50 [Hz]) will likely saturate the ADC.

Further, this was solidified in a SEI team summit at the March 2011 meeting, notes were taken (see T1200373) that say the following:
"
FM4 - Switchable Readout Gain:
	- Gain of 10 (7) [113] (cancels fixed gain in FM1)
	- FM4 is ON when analog gain is OFF
	- FM4 is ON in "low gain" mode (analog x10 gain is OFF)
	- FM4 is hooked to analog gain via BIO, such that when FM4 is turned OFF, the analog gain is turned ON
	- Choose for analog switch to happen at zero crossing (a bit you can flag in the foton .txt file)
FM5 - Switchable Whitening (for GS13s only):
	- Filter matches analog whitening (cancels fixed dewhitening in FM1)
	- FM5 is ON when analog whitening is OFF
	- FM5 is OFF in "low gain" mode (analog whitening is ON)
	- FM5 is hooked to analog whitening via BIO, such that when FM5 is turned ON, the analog whitening is turned OFF
	- Choose for analog switch to happen at zero crossing (a bit you can flag in the foton .txt file)
"

Seems clear, right? Great. 

Here's the problem:

(1) The front end does not restrict the user from the ADC-noise-swamped state, lets call it "ultra-lo gain mode," of FM4 and FM5 ON (additional analog gain and whitening OFF) or the ADC saturating state, let's call is "ultra-high gain mode," of FM4 and FM5 ON (additional gain and whitening ON).

(2) The python command script used to switch between the modes is 
${userapps}/isi/common/scripts/sensor_hilo
and IT ONLY SWITCHES FM4. This (and the name "hi gain" and "low gain") has confused users who only use this command script into thinking that the difference between the two relevant states is *only* the x10 gain and FM4. 

This had resulted in chaos and confusion during LHO's period of revolving commissioners, and ingrained a long-standing, almost superstitious, confusion about what "low gain" and "high gain" states mean.

Thankfully, I think after 15 discussions on SEI calls, 20 individual-to-individual email chains, and some LLO spy sessions via remote log-in over the past few years, Jim and Hugh have settled on what Brian thought was right answer for GS13s back in 2010:
- All* HAMs are in high-gain mode (with FM4 OFF and FM5 ON, i.e. additional analog gain of 10 and no whitening.)
- All* BSCs are in high-gain mode ("")
Why do I have asterisks next to ALL in both cases that continue to add to the confusion? 
Because of blasts from lock-acquisition / lock-loss.

From experience with DRMI lock-acquisition, LLO has found that ISI BS ST2 GS13s saturate regularly if in (nominal, not ultra) hi-gain mode. If the GS13s are in the (nominal, not ultra) low gain configuration, they don't saturate. As such, for the ISI BS only, we use the nominal lo-gain mode.

For experience with the Fast Shutter closing and opening on HAM6, LLO has found that the ISI HAM6 GS13s saturate regularly even in the nominal lo-gain mode. Thus, we've changed the configuration of the HAM6 ISI to the ultra-low gain mode (FM4 and FM5 ON, no additional analog gain or whitening).

So here's my suggestions: 
- we rewrite the python script sensor_hilo to be a FOUR state system instead of a TWO state system, and make sure that FM5 gets toggled as well as FM4. 
- we use either GUARDIAN or the new SDF system to keep track of these FMs. If the chamber needs to switch gains after lock acquisition or lock loss, it should be controlled by guardian.
- we continue to measure the performance of all platforms to find out where we're ADC noise limited in all possible states of the GS13 interface. 
Non-image files attached to this comment
jeffrey.kissel@LIGO.ORG - 17:36, Tuesday 10 February 2015 (16612)
"Trust, but verify." Always!

Hugh has caught an error in the above description of the GS13 interface's state machine which didn't obey reality. Thankfully, he was able to confirm this with real data from HAM6 -- see LHO aLOG 16606. I've added the following [clarification of / correction to] the above to Hugh's entry, and I repeat it here for completeness:

- When FM4 is ON, the gain switch is HI (or a binary output of 1), so the analog gain is 2, and FM4 compensates the gain of 10 difference. 
- When FM4 is OFF, the gain switch is LO (or a binary output of 0), so the analog gain is 20.
- When FM5 is ON, the analog whitening is HI (or a binary output of 1), so the analog whitening is engaged, and FM5 compensates the analog whitening of z:p = 10:50 [Hz] with a de-whitening z:p = 50:10 [Hz] filter. 
- When FM5 is OFF, the analog whitening is LO (or a binary output of 0), so the analog whitening is is OFF, and no FM5 means no compensation.
jeffrey.kissel@LIGO.ORG - 15:57, Wednesday 11 February 2015 (16663)
Here's a corrected drawing to indicate the state of the FMs in each HI and LO states.
Non-image files attached to this comment
H1 SUS (ISC)
betsy.weaver@LIGO.ORG - posted 14:01, Monday 02 February 2015 - last comment - 15:26, Monday 02 February 2015(16414)
A bit of SDF work today

This morning, I worked on adding a few more suspensions to be monitored by the SDF, mostly to add progress on my SDF learning curve.  While we continue to work through a path which monitors filter channels more efficiently, I went ahead and set the SDF to monitor every channel that the guardian doesn't touch for the MC1, MC2, and MC3 suspensions.

 

While I was at it, I decided to set the SDF to also monitor every LSC and LSCAUX channel.  I did not set any channels in these snap files to be ignored by SDF.  However, when I hit the LOAD TABLE ONLY button, I noticed that there are currently 9 unmonitored channels in the SDF LSC monitor.  See attached below.  Huh??  When I look at the h1lsc_safe.snap file, I confirm that the last column is all 1s, no zeros (therefore no ignoring any channels in this file).

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 15:26, Monday 02 February 2015 (16418)

So, the attached snapshot of the LSC SDF channels that are not being monitored is the same list as the SDF "NOT INIT" list.  Does this mean that the snap is old and there are new channels to be monitored?  These 9 channels (mostly associated with REFLAIR) are not in the burt request file (and therfore not in the safe.snap).  Possibly the alog below regarding new REFLAIR work will connect these channels in at some point...

If so, we'll have to reset the files with the appropriate 1s and 0s for the SDF to monitor after a new safe.snap is taken.

 

New update to this alog - I went ahead and started SDF monitoring on all ASC channels as well.  At least now, operators, etc can watch the lists change as guardian switches stuff if they want.

H1 CDS (CDS, ISC)
evan.hall@LIGO.ORG - posted 11:31, Monday 02 February 2015 - last comment - 12:24, Monday 02 February 2015(16410)
Normalized REFLAIR9I alongside REFL9I; nominal ISC cabling restored

The LSC model has been edited to accommodate a normalized REFLAIR9I signal (LSC-TR_REFLAIR9) alongisde normalized REFL9I (LSC-TR_REFL9). A switch determines which of these is signals is fed into LSC-REFLBIAS.

Correspondingly, I have switched back the cabling on the ISC rack so that the demodulated REFL_A_RF9 signals feed into the REFL_A_RF9 whitening chassis, and likewise for REFLAIR_A_RF9.

Images attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 12:24, Monday 02 February 2015 (16412)

The guardian scripts, whitening settings, and demod phases are now corrected back to their settings prior to the cable swap. 

H1 SEI
hugh.radkins@LIGO.ORG - posted 10:17, Monday 02 February 2015 (16409)
CS HEPI Pump Station--Noise Check with/without remote amplified signals connected

Wanted to confirm the long runs to the amplified BSC2 Pressure Sensors weren't the main ground noise culprit.  Richard plans to add following resistors to the satellite amplifier before the long runs.

Anyway, it does not look like these are making the Pump Station Pressure signals noisy.

Attached is 30 minutes where we disconnected these channels from the servo inputs: Ch3 goes away as the return and supply pressures from BSC2 (Chs7 & 8) are disconnected. The Main Supply pressure, Ch9, shows that the noise level doesn't change during this period.  The servo is in free running manual mode.

Images attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:19, Monday 02 February 2015 (16408)
CDS model and DAQ restart report, Sunday 1st February 2015

model restarts logged for Sun 01/Feb/2015
2015_02_01 14:40 h1fw0
2015_02_01 20:06 h1fw0

both unexpected restarts. Conlog frequently changing channels report attached.

Non-image files attached to this report
H1 AOS
sheila.dwyer@LIGO.ORG - posted 15:21, Sunday 01 February 2015 - last comment - 16:16, Sunday 01 February 2015(16406)
a little sunday cleanup

Evan, Sheila

We did a little bit of cleaning up today.  First edited the IMC guardian to adjust the input gain for different input powers.  We though we had implemented this before, but what we had actually wasn't working.  I added an if statement in the BOOST step that sets the input gain for 1W, 4W, or 10W.  We could have something better which adjusts it for any input power.  

We also changed the ISC_CONFIGs guardian to accoun for the cable swap we did on friday night, PRX locked is not using reflAIR in the input matrix, which is really REFL 9.  

Evan and I then locked DRMI just to make sure everything is OK with the TCS back on, it locked with no problem, now we are checking demod phases.  

Comments related to this report
evan.hall@LIGO.ORG - 16:16, Sunday 01 February 2015 (16407)

Demod phases are as follows. We have not made any changes.

  • REFL_A_RF9 (which is really the REFLAIR_A  photodiode): 92°
  • REFLAIR_A_RF45: 142°
  • REFLAIR_B_RF27: 111.8°
  • REFLAIR_B_RF135: 25°

For 9 MHz and 45 MHz, DRMI was locked on 1f, and for 27 MHz and 135 MHz, DRMI was locked on 3f. We drove a 132 Hz line into PRM (and then later SRM) to gauge the suitability of these demod phases.

For the 3f locking, tuning the 135 MHz demod phase to 25° is sufficient to minimize the appearance of PRCL and SRCL in the 135Q phase. However, for the 1f locking, tuning the 45 MHz demod phase to 142° minimizes only the appearance of SRCL in 45Q; for PRCL, the demodulated 45Q signal is about 15% of the demodulated 45I signal. The demod phase required to minimize the apperance of PRCL in 45Q is instead 150° (but this leaves the SRCL 45Q signal at about 15% of the SRCL 45I signal).

H1 IOO (IOO, ISC)
evan.hall@LIGO.ORG - posted 14:47, Sunday 01 February 2015 (16405)
IMC OLTF, 4 W PSL power

Sheila, Evan

We have been changing the PSL power up and down during CARM offset reduction. Among other things, this changes the optical gain of the IMC PDH loop. So far, we've been compensating for this gain using the IMC servo board as follows:

Just to make sure that the IMC loop is still OK in the latter configuration, we took an OLTF by driving a 20 mV swept sine into EXC A and monitoring the test points before and after. The result is attached.

Non-image files attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 08:58, Sunday 01 February 2015 (16404)
CDS model and DAQ restart report, Saturday 31st January 2015

model restarts logged for Sat 31/Jan/2015
2015_01_31 06:40 h1fw0
2015_01_31 08:08 h1fw0
2015_01_31 18:39 h1fw0
2015_01_31 19:04 h1fw0

all unexpected restarts. Conlog frequently changing channels report attached.

Non-image files attached to this report
H1 ISC
daniel.hoak@LIGO.ORG - posted 00:26, Sunday 01 February 2015 (16402)
weekend work on TCS, OMC

Dan, Elli

Today we did a few non-locking things:

As part of this work we changed a few whitening gains.  The gain for IM4 TRANS had been turned down to zero because it was saturating from the aux laser for the Schnupp and PRCL measurements.  We turned this gain back to 36dB.

Also we increased the whitening gain on the OMC QPDs, they are now 30dB (were 18dB).

Non-image files attached to this report
H1 TCS
eleanor.king@LIGO.ORG - posted 22:43, Saturday 31 January 2015 (16403)
ITMX CO2 laser is back on

Turned on at 1Feb 2:55:22 UTC.  .3W requested power, 0.21W registered at the power meter. 

I requested central heating, although the H1:TCS-ITMX_CO2_FLIP2MON and H1:TCS-ITMX_CO2_FLIP1MON mon channels are jumping all over the place, we need to fix this.  ITMx HWS was runningand shows an increase in the spherical power, which is consistent with central heating.  

H1 AOS
daniel.sigg@LIGO.ORG - posted 17:36, Friday 30 January 2015 - last comment - 13:08, Monday 02 February 2015(16385)
TCSX CO2 laser Off

(Elli, Richard, Dave, Rich, etc.)

Last Tuesday around 1pm the readback channels of the TCSX CO2 laser system went crazy. We tracked this to the AI/AA chassis which were not powered. Not clear why, but maybe the power connector fell off, when someone worked in the PEM rack? When the digital system goes down, the chiller doesn't get a temperature setpoint. It will then turn itself off with a fault. In turn the laser shuts off. With the power restored, it was possible to turn the chiller on, and then the laser. Both actions need to be done on the floor. The laser is now back in operation with the requested heating set to 0W. Once we leave we can set it back to 0.3 W. The mask is set to central heating, but the monitor for the annular mask is flaky.

In conclusion: The TCSX CO2  was probably off since last Tuesday 1pm.

Images attached to this report
Comments related to this report
greg.grabeel@LIGO.ORG - 13:08, Monday 02 February 2015 (16413)TCS
The TCS Y arm chiller was off when I investigated the problem. There were no fault codes on restart and the reservoir level was well above the trip level. The X arm chiller was still running. However, the laser controller was showing a flow fault for both the X and Y arm. Toggling the key and re-enabling the gate restored the controller to its operating state.  
H1 SUS (SUS)
thomas.abbott@LIGO.ORG - posted 14:34, Friday 30 January 2015 - last comment - 14:27, Monday 02 February 2015(16377)
Driftmonitor working at LHO.. fixed some bugs.. and added infrastructure for setting fixed thresholds
Rana and Travis updated a newer version of the drift monitor and added it to the sitemap at LHO, and I made some further changes:

I have fixed bugs in the MEDM screen (/opt/rtcds/userapps/release/sus/common/medm/SUS_DRIFT_MONITOR.adl), and now the buttons for updating individual suspensions work again. LLO, if you svn update the MEDM screen, please be aware that instances of "H1" in the code will need to be changed to "L1" to prevent horrible, epic failure. 

I've added a set of dictionaries to the drift monitor update script (/opt/rtcds/userapps/release/sus/common/script/driftmon_update.py) that allow for setting fixed threshold values by editing the code itself (example below). The current values are somewhat arbitrary guesses, so they require tuning. The changes have been committed to svn, and the code should be LLO-friendly without any modification. 

Example: To set fixed thresholds, open driftmon_update.py, and scroll down until you find the following (at line 115 at the time of this post):

########## TUNE THRESHOLDS HERE ###########
# yellow thresholds = mean +- yellow_factor * BOUND value
# red thresholds = mean +- red_factor * BOUND value


yellow_factor = 1
red_factor = 2

BOUND_MC1 = {'P' : 50, 'V' : 10, 'Y' : 15}
BOUND_MC2 = {'P' : 50, 'V' : 10, 'Y' : 5}
BOUND_MC3 = {'P' : 50, 'V' : 15 , 'Y' : 20}
.
.
.
and so on.... and edit the values corresponding to the suspensions and degrees of freedom you wish you tune. For instance, with the code above, if the script updates MC1 pitch and sets, say, 10uRad as the nominal value, then the code above will make the yellow alarm trip at <-40uRad and >60uRad (mean +- 50uRad), and the red alarm trip at <-90uRad and >110uRad (mean +- 2*50uRad).

 


Comments related to this report
thomas.abbott@LIGO.ORG - 14:27, Monday 02 February 2015 (16415)
I opened up the MEDM code for the driftmon, and changed all specific references to H1 to $(IFO), and now I believe it should run fine on either site. So please disregard my prior nonsense about having to change the MEDM code for use at LLO. Macros are awesome.
H1 SUS
thomas.shaffer@LIGO.ORG - posted 14:16, Friday 30 January 2015 - last comment - 10:37, Monday 02 February 2015(16376)
Updated GUARD_OVERVIEW and IM/TT medm screens

I updated the GUARD_OVERVIEW and the IM/TT medm screens to contain micro/mini Guardians for IM1, IM2, IM3, IM4, RM1, RM2, OM1, OM2, OM3. The scripts were already made available by Stuart Aston and Jameson Rollins at LLO see https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15772 and also https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=15585. The Guardian Nodes were not yet created though so I had to create those and figure out that they also had to be started.

Currently RM1, RM2, OM1, OM2, OM3 do not have any offset.snap files saved to them in userapps/sus/h1/burtfiles/ (hence the red border on the Guardian Minis in the overview screen shot).

Attached are the before and after of the GUARD_OVERVIEW.adl screens along with the new HAUX and one of the new HSSS IM screens.

Images attached to this report
Comments related to this report
jameson.rollins@LIGO.ORG - 10:37, Monday 02 February 2015 (16411)

The red boarder actually indicates an ERROR with the node.  If there's not actualy ERROR conditions in those nodes, then there might be a version incompatibility between the version of guardian in use and the indicator screen.

I'll help resovle this issue when I'm on site tomorrow.

Displaying reports 61301-61320 of 77278.Go to page Start 3062 3063 3064 3065 3066 3067 3068 3069 3070 End