I changed the IMC locking thresholds because the incident laser power was increased from 300 mW to 1W.

• Boost trigger was increased from 200 to 800 counts.
• The LSC low pass filter trigger was increased to 3000 counts.

It's locking fine.
 

Chris, Kiwamu, Sheila

On friday night, we added IPC receive parts to the h1susprm and h1suspr2 models for ISC-L, ASC_PIT, and ASC_YAW.  

There were already place holders in the model and IPC send parts in the LSC and ASC models , and everything went smoothly.

Since Kiwamu had issues locking the power recycling cavity using M3 actuation of PRM, I ran a quick dtt tf on middle and lowest stage of PRM in one dof (L) to check for any actuation issues. Both stages look ok (cf attachements), so I'm not sure where the problem could come from.

J. Kissel, J. Batch, H. Radkins, H. Paris

We discovered this morning that HAM2&HAM3 ISIs and HPIs (run on the h1seih23 [computer /  I/O chassis]) were not sending drive signals out to the chambers even though 
- Drive was requested
- The ISI & HPI overview screens indicated the ability to drive (Watchdogs all green, master switch on, "you can drive" border all green)
- The user model FEC state words were all green
- The user model GDS_TP DAC bits were all green

It turns out the only indication of badness is on the FEC STATE WORD of the IOP (in this case H1:FEC-53_STATE_WORD) -- the 8th bit (or 7th if you count from 0), marked "WD" on the CDS_OVERVIEW screen, which is a mislabeled bit representing the "DAC ENABLE" function, which can be triggered by several things other than watchdogs. A minute trend of this bit shows that it has been triggered since Dec 15th 2013 12:51 PST, 2013-12-15 20:51 UTC, 1071175876

Hugo informs me that this symptom has been seen before (I'm sure there are aLOGs, but they'd be written by four different people, each, like me, unsure of how to explain the problem exactly, and probably tagging it with different tasks or use different buzzwords), but the cause is unknown.

Jim had initially suspected the the IOP's FIFO buffer had somehow been emptied, which would cause this bit to go bad, but after looking at the front-end's log, by doing
controls@opsws3:~ 0$ ssh h1seih23
controls@h1seih23:~ 0$ dmesg
where he expected to see some error from the h1iopseih23 process indicating this fact, but no obvious error was reported.

As with all problems like this, we rebooted all front end processes and it cleared the problem and actuation ability has been restored, but the root cause remains a mystery.

@DetChar: can you take a look? If anything just to narrow down exactly when the IOP bit failed *this time*, but maybe get a long history of he channel to see how often this happens, if it only happens on this front end or if it happens on other front ends, etc. etc.

@SEI: Y'all should include the STATE WORD for the user model and the IOP on your overview screen, and include this DAC ENABLE bit in your logic for computing the "you can drive" border.

I removed the two beam splitters on the PSL table installed for the faraday isolation measurement, so that we can use more power to search for the POP beam.  After removing both there was no noticable change in alingment on irises on the PSL, so I did not adjust the alingment at all.  I also rotated the half wave plate which will soon be in the motorized stage, so that there is now 0.95W incident on the bottom periscope mirror.  These powers were measured with the PD300-3W power meter head with the filter on. 

This means there is 0.76mW transmitted through the bottom periscope mirror (measured with filter off) , and 59uW transmitted by IO AB BS1.  I powered up the PD that was placed after IO_AB_M12, which was saturated with this power so I moved it to the location of IO_AB_PD2 in the drawing, where there are 16uW incident on it now, resulting in -4.96V.  With the beam blocked this PD has a 60mV offset.  This is a PDA55. 

I also removed the lens, PD, beamsplitter and beam dumps that were used with the two beamsplitters for the farday measurement, I put all the components in the IO cabinet in the anteroom.  This unblocked the PATH from IO_MB_WG1, this path seems to be aligned onto  IO_AB_PD1 already.

I also unblocked the ALS path.  

J. Kissel

Though folks found a temporary solution that worked for the time being while I was off-site last week (see LHO aLOG 8894 and LHO aLOGs 8901), I wanted to try sixteen more ways arranging signals in the h1susim.mdl and/or h1sushtts.mdl front-end simulink models to get what I want out of the calibrated, Cartesian ISI GS-13 signals projected to each optic's EULER basis. Still no dice. Gosh darn it.

I attach to pages of pdf. These are cartoon mimicry of the top level of a given suspension type's front-end Simulink model. I drew the cartoon so you can see a simplified view of the important parts for this discussion, and you can see into the subsystem blocks.

Pg 1 -- a cartoon of what every other suspension type (which only have one optic per model) has. Note, that here, goto/from tags and bus creators/selectors are used going straight from the IPC blocks at the top level, and skipping down two levels (both of which are separate library parts) to a cdsFilt bank. We've been told that skipping levels like this shouldn't work. But it has and does, in this configuration.

Pg 2 -- a cartoon of what I *want* to do with the HSSS, which have many suspensions per model. Here, I send the GS13 signals into a (non-library) subsystem named after the suspension type (HTTS or IM), and calibrate the GS13s once. Yes, I skip a level, but if pg 1 works, so should this. Also, the subsystem in the (HTTS or IM) block has an underscore in the block name -- trying to preserve the channel name format across sus types -- so maybe this is fooling the RCG. From there, the calibrated signal is sent up and out to the top level again, sent to the common HSSS_MASTER block renamed to reflect each of the optics in the model.

As drawn, the model doesn't compile, complaining that just about every bus selectors is not connected.

Where you see roman numerals in double square braces, e.g. [[ii]], I've tried inserting 
- dummy epicsOutputs
- Simulink gains of 1.0
- Test points
- Terminators and Grounds
and can only get it to compile in something equivalent to the temporary configuration where the IPC is fed directly to the HSSS_MASTER.mdl block. 

Very frustrating.

Dan has repaired the h1ldasgw1 disk system, I have just restarted h1fw1. It has been writing frames for about 20 mins with no errors.

BSC 9 cleanroom turned off at 12:48.  

[ChrisW, Stefan, Sheila, Kiwamu]

The power recycled half Michelson with ITMY, so-called PRY, was locked.

It is not so stable at this moment but it could stay locked for more than 10 seconds.

Alignment pf PR2 and PR3:

As advertised yesterday, indeed we were close to a good alignment. Although we got confused by the BS camera, we managed to find the fringe by steering PR2 with PR3 continuousely scaning in yaw by AWG at 0.3 Hz. The vertical alignment looked OK from the beggning and we had to mainly tweak yaw. Afte we found it, we simply maximized the amplitude of the REFLAIR_A_RF9 signals. Note that the spot motion looked quiet today as all the ISIs were on.

Locking settings:

sensor = REFLAIR_A_RF9_I (whose phase was adjusted to be 10.0 deg)

actuator = PR2

details = see the screenshot below

Mysteries and issues to be solved:

• Why PRM doesn't grab a fringe ?
  • Stefan measured the actuator to osem TF at M3 and the result was suspiciousely flat from DC to 10 Hz. Probably something is wrong.
• Turning off the ITMY ISI made the lock more stable.
  • ISI needs to be checked and tuned.

Just prior to this evening's DAQ restart at 21:04, h1fw1 froze up again with disk issues at 21:01. Similar to this morning's problem, the file system appears to exist but files cannot be fully formed.

I tried at remote reset of h1ldasgw1, but that did not proceed. Chris went into the MSR and looked at h1ldasgw1's console, it had gotten stuck in the shutdown sequence with disk issues (not surprisingly). He power cycled the Sun box using the front panel button and it did reboot. I was able to log in remotely but could not get the QFS/SAMFS file system to mount. I got the error

root@h1ldasgw1:~# mount /cds-h1-frames

mount_samfs: Configuring file system

mount_samfs: Enabling the sam-fsd service.

mount_samfs: Adding service tags.

mount_samfs: Filesystem "cds-h1-frames" not found.: No such file or directory

so unfortunately we will have to limp along with just h1fw0 for this evening. Since h1nds1 is the default NDS, for archived data the control room will have to use h1nds0 instead.

Powering the illuminator on BS (LVEA ) – Richland
End Y transitioned to LASER HAZARD (Fiber welding work) – Doug
Guardian IMC autolocker now running (see alog # 8942) - Jameson
Restart of h1fw1 – Dave
DNS Server work -  James

I have changed the default nds server back to h1nds1.  This will be effective with new shells or processes.  

(Alexa, Daniel)

With the gain setting at 0dB for the external PD:

Transimpedance = 2kOhm

Ext PD Monitor = 1.28V

Beckhoff readback = 5.17V (there is a 4x gain between the monitor and controls output)

If the external PD is a silicon diode (responsitivty = .25A/W), this implies that we have 2.6mW on the diode. Alternatively, if we believe that we have ~1mW on the diode as referenced in alog, then the responsitivty of the diode is closer to .64A/W, which resembles that of an in-gas diode. The former is more likely.  **** Next time someone is in the PSL, can you please measure the power into the diode?

Meanwhile, I also confirmed that the gain setting on the ALS fiber distribution chassis is as expected. At the ext. PD input, I read -5.0V. Placing 100kOhm resistor at the input provides 50uA of current. Thus, one expects to read V=(50uA)(2kOhm) = 100mW at the ext PD monitor, which I verified. This is consistent with the test report for this chassis, which confirmed 3.13V at 30dB with 50uA. The factor for 30dB gives a factor of 31.26 in V.

Conclusion: ALS fiber distribution is okay. Diode is different than expected or we have more power ...

The first new Guardian daemons are now running!

The IMC is now fully under guardian control.  The guardian components are (given by their full guardian identifier):

• ISC_IMC
  • /opt/rtcds/userapps/release/ioo/common/guardian/ISC_IMC.py
  • handles H1:IMC- channels
• SUS_MC2
  • /opt/rtcds/userapps/release/sus/common/guardian/SUS_MC2.py
  • handles H1:SUS-MC2 channels.  Currently this is inheriting from the generic SUS module (/opt/rtcds/userapps/release/sus/common/guardian/SUS.py), and adding additional control states on top.
• IFO_IMC
  • /opt/rtcds/userapps/release/sys/common/guardian/IFO_IMC.py
  • IMC manager that controls both ISC_IMC and SUS_MC2 guardians

The paths listed are the fulls paths to the guardian system description modules that are being executed for each guardian process.  Given a system identifier FOO, guardian looks for a python module named FOO.py in the common/guardian subdirectories of the various relevant subsystems in the userapps path.

The IFO_IMC manager is the top level control.  It instructs SUS_MC2 and ISC_IMC to go to their ACQUIRE states if the IMC is not locked, and then transitions SUS_MC2 to turn on boost filters after ISC_IMC guardian reports that the IMC lock has been achieved.  If ISC_IMC looses lock, IFO_IMC sees this and moves SUS_MC2 and ISC_IMC back to their ACQUIRE states.

MEDM interface

The primary interface for controlling the processes is their medm screens, which are accessible from the "GRD" menu in the sitemap:

The REQUEST button selects the requested state of the system.  The MODE button selects the operational mode of the guardian process.  EXEC indicates that it is executing guardian code.  The STATUS reflects the guardian process status.  In this case, the IFO_IMC guardian is executing the RUN method of the LOCKED state.

The buttons at the upper right allow for displaying the log of the daemon, displaying the current system graph, and editing the underlying system module code.

guardian daemon controls

All three guardian processes are running under the new guardian control infrastructure on h1guardian0:

controls@operator1:~ 0$ guardctrl list
IFO_IMC * run: IFO_IMC: (pid 8739) 7805s, want down; run: log: (pid 13060) 78412s
ISC_IMC * run: ISC_IMC: (pid 6400) 9332s, want down; run: log: (pid 1346) 66758s
SUS_MC2 * run: SUS_MC2: (pid 2208) 66732s, want down; run: log: (pid 2050) 66737s
SUS_SR2 * run: SUS_SR2: (pid 32679) 96154s, want down; run: log: (pid 23722) 230173s
controls@operator1:~ 0$ 

The guardctrl command line interface can be used to start/stop/restart the daemon process, as well as create new ones as needed.

TODO

Some immediate todo task for the next week:

• The rest of the IMC suspensions (at least MC1 and MC3, and maybe others?) need to be brought under the control of IFO_IMC.  These should be ready to go now
• The base SUS module needs to be improved to properly handle watchdog trips, and other potential critical deviations of the suspensions.
• Add HAM2 ISI under IFO_IMC.  This depends on status of the ISI code, which may be ready next week.
• Add GRD MEDM overview
• Add GRD channels to frames

There are also an ever-growing list of guardian bugs (not a bad thing at this point, since it means the system is actually being used now) that I will start filling in in the new guardian bugzilla (thanks Jonathan).

As noted in alog6341, the gain on the Dual PD Amp board was set to 30dB (photo 1). I have reduced the gain to 10dB (photo 2). However, I still see saturation at 10V in the external PD monitor. Tomorrow I will try reducing the gain to 0dB.