In an effort to eliminate the need to connect and disconnect shutter cables during vent we have moved the shutter logic controler to the rack from the table. Also replaced the BNC cables with Yellow BNC cables so they can be easily identified. See attachment.
Krishna,
Jenna and I had noticed that L4C 7 didn't appear to be working. L4C is close to the c-BRS, so it would have been good for comparison. In order to test if it was the instrument or the electronics, I temporarily swapped the cables with those of L4C 8 going in to the SUS rack at the LVEA. Now L4C "7" appears to be working and L4C "8" is not, indicating that the problem must be on the instrument side (or the pre-amp, I guess?). I'll swap it back in the afternoon.
Cables replaced in original configuration.
After looking at a different working L4C output (5), I think I was wrong about the instrument being faulty. It looks like the L4C was working when I swapped the cables, suggesting that the problem must be on the electronics side.
Posted below is a 45 day trend of the TCS laser power compared to operating temperature. There is a drop in power and temperature on 07/19/16 (aLOG #28506). During the HAM6 vent the RF driver was replaced (aLOG 28837) but was never tested due to lack of a beam. After the vent TCS-Y came back at ~16W with a temp of 22.
Dear Colleagues,
As of now, LLO is closed until further notice due to widespread flooding in the area that prevents access, including emergency access. I expect we will be able to reopen on Monday.
Any personnel or visitors on site now should immediately leave, taking US-190. Explicit permission from either myself or Richard Oram is now required to be on site.
More details will follow, but I did not want this message delayed. As always, liaisons should be in touch with your visitors to convey this message.
Joe
Joseph A. Giaime, Observatory Head, LIGO Livingston (Caltech); Professor of Physics & Astronomy (LSU).
phone at LIGO: +1 225 686-3169.
SEI: All back to normal after vent SUS: All Ok CDS: Looking into several read-back issues. Will need to do a restart of NDS1 this morning. PSL: OK. Looking into the low power from the TCS-Y laser. VAC: No report FMC: No report Relocking and commissioning work today.
I have taken camera images of the OMC R and ASAIR beam. This was primarily to compare the beam quality before and after the OMC swap. However, I did not find any obvious or significant change in the beam shapes. See the attached and compare them to the ones in 28718. Also the data is attached as well.
Stefan and Sheila working on shutter control logic. I helped resolve problems with h1ecatc1. Had to restart EPICS IOC and copy updated PLC2 to target. 23:32 UTC Gerardo to HAM6 area to check on vacuum equipment 23:39 UTC Gerardo back 03:05 UTC Joe to Y2-5 to watch meteor shower with telescope 04:30 UTC Stefan and Sheila done working on shutter control logic. Kiwamu starting work. 06:17 UTC Kiwamu to end X to investigate green laser electronics 07:00 UTC Kiwamu back I was able to get the Y arm green power to around 1 with LOCKED_NO_SLOW_NO_WFS, but if I put it on INITIAL_ALIGNMENT it would start to be driven away. Kiwamu was investigating the X arm.
Patrick, Kiwamu,
We are unable to engage the QPD servo for the X green injection beam. It seems to be an issue with the PZTs. We are leaving this issue until tomorrow.
Also, the readback of the POPX whitening settings don't match to the requested. This also needs to be fixed.
For the QPD loop issue -- after a through investigation today, it tuend out that it was not the PZTs but it was the QPD signals that were not functioninng. I drove to EX again today and found that the whitening chassis for this particular signal was physically switched off. So I switched it on by latching the switch to the on position on the back side of the chasis. The QPD servo now runs. Also, during the investigation I confirmed that the pzt mirros were functioning by sending some sinusoidal excitation and looking at the beam spots on the table.
After CO2Y was powered on today, we noticed that the laser power was as low as 16 W which should be nominally 60-ish W. See the attached. This is the one with the RF driver recently swapped (28837). Needs more investigation.
Jason is aware of this and plans to look at it Friday.
... why we did all this testing single bounce, and didn't try to lock anything:
There was a 7.2 quake, includiong some stron aftershocks, gently rocking the planet for the last 3h...
Sheila, Stefan,
We debugged Daniel's Beckhoff based AS port protection logic (more on that in Sheila's alog) and updated the guardian wrapper code to work with it.
MEDM screen description (figure 1):
AS Trigger PD (top left): Is the trigger PD (ASC-AS_C_SUM), as seen by Beckhoff within alowable power limits (i.e. there is power on the PD, but also not too much)
AS Trigger Logic (bottom left): Control of the fast trigger logic - feeds into the fast shutter and into the PZT shutter. (Note: manually closing this trigger actually fires the fast shutter.)
Fast Shutter (top middle): Control of the fast shutter (Note: manually closing the shutter here closes the fast shutter SLOWLY.)
PZT Shutter (bottom mddle): Readbacks for the PZT shutter.
Protection (right): Logic and readback for the shutter status and testing.
The protection implements Daniels ECR E1600248 testing. More on that in SHeila's alog.
Note that the Beckhoff code cannot check the light on PDs downstream of the shutter. We indend to add a check of the downstream diodes into the FAST_SHUTTER guardian.
FAST_SHUTTER guardian:
This guardian is intended to implement the rest of ECR E1600248. Currently, it checks whether the AS_PORT_PROTECTION needs a test (Beckhoff readback), runs that test by poking Beckhoff if needed, and verifies that all the light levels are adequate before going to READY.
If any of the conditions are not met, it stops in SHUTTER_FAILURE and waits for human action.
The ISC_LOCK guardian will be updated to require the FAST_SHUTTER guardian to be ready before proceeding to full lock.
Items of ECR E1600248 still to be implemented:
1) Automatic check on lock-loss that the shutter worked as intended. If not, command PROTECTION_AS into Fault, and raise audio warning. This part however can only be implemented when seeing real lock-losses. So we intend to initially require a human to look at every lock-loss - the corresponding medm button is implemented - see alog 29001.
2) Augment the FAST_SHUTTER guardian to monitor the photodiode levels during the Beckhoff testing, and require that the downstream light is cut off and doesn't come back.
Sheila, Patrick, Stefan, Jenne
We made several changes today both in Beckhoff and the FAST_SHUTTER guardian the course of checking the bechoff code that tests the fast shutter.
First,we spent some time on the beckhoff code that Daniel wrote that is intended to be used as a periodic check (to be run at the next lockloss once it has been 48 hours since it has been run.) The state machine which is run if someone clicks on the run button here
We had to make several changes to the original code to get this going, the current version which we have tested several times is committed as rev 3067:
As we made these changes we had several unexplained difficulties with beckhoff restarts.
This is intended to be integrated into guardian, so next we we decided to separate the two functions of the FAST_SHUTTER guardian as Jenne had written it into two different nodes, one which will be managed by ISC_LOCK and tests the fast shutter after DRMI has locked and one which will not be managed by ISC_LOCK but will check that the fast shutter has triggered after a lockloss with sigiificant power in the arms. Separating these two things makes it significantly easier to write both in the way we want. The FAST_SHUTTER guardian is currrently tested and is the one which manages the beckhoff tests. The tested version is revision 14023.
We triggered the fst shutter a couple of times by lowering the threshold (i.e. ensuring that the alanog electronics fires the shutter), and wee verified that we didn't see any bounce after 60ms to 100ms (as loged before in alog 28958 ).
Attached are plots for one trigger, on different time scales.
[Jenne, Stefan, Peter, TJ]
We now have a new guardian node, FAST_SHUTTER, to monitor the function of the fast shutter. So far this does not interact with the PZT shutter.
Attached is the guardian graph of how it works for now.
So far, this is not incorporated into the main ISC_LOCK guardian. However, ISC_LOCK Down should probably request Fast_Shutter's Down. Somewhere around DRMI_LOCKED we should have the ISC_Lock guardian request Ready from the FastShutter guardain. We shouldn't be able to continue locking unless the FastShutter says that it's Ready. Somewhere like DC Readout, we should put the FastShutter guardian in IFO_Locked.
We hope to be able to test the functionality of this new guardian tomorrow, after ISCT6 is put back in place.
I noticed that an uknown script constantly "opens" (i.e., unlatches) the trigger logic for the AS port protection shutters. This is probbaly not a good idea, since it can confuse an operator. If we need the auto-unlatch feature, it should be added to the shutter control in a transparent way.
The intended design of this shutter controller, (called a trigger reset controller in the beckhoff) is to reset itself.
[Corey, Betsy, Fil, Peter, Calum, Stefan, Koji]
Summary
- The ISC portion of the HAM6 vent work has been completed.
- Shield isolation of the in-vacuum cables was confirmed.
- The fast shutter was reinstalled on the table after some modifications.
=> Ready for the SEI mass balancing and other exiting procedures. OMC PZT HV is still on. Remeber to turn it off before pumping down.
Some details
- Shield isolation: It is always confusing to check the shiels isolation on HAM6 because of several reasons.
We initially had several cables shorting to the chamber but all of them but one happened at the slack of the cables right inside of the flange. The last one happened on the DB25 cable before it climb up to the vertical wall of the ISI.
- The fast shutter modification / reinstallation
(Photos are supposed to come later.)
Photos From Yesterday's Fast Shutter Work
Photos are on Resourcespace here:
https://ligoimages.mit.edu/?c=1705
Cable Grounding Check
(Corey, Fil, Koji)
Documents of interest:
We went through as many of the ISC/SUS cables as we could, which is mainly all the DB25 connectors (most were on a single flange, D6). The non D6 cables [i.e. SUS OMC & WFS Heads] were checked at the CDS rack (east of HAM6) & the SUS rack (south west of HAM6). We did not check the RF WFS cables at D5 (not sure how to make check on these connectors, and Koji was worried about disconnecting the connectors since it could make things worse. We also did not check SEI since those cables were not touched and are nicely clamped & out of the way.
Some notes:
OMC Cables (D6: F1, F2, & F3): These cables all go to a harness on the OMC breadboard. Their sheilds are all tied to each other. Since we checked these cables at the flange, You must disconnect all three cables at the same time. Then you can do the ground loop check (otherwise, if you do one at a time, you will trick yourself into seeing ground loops, but this is because their sheilds are all connected).
For the Picomotor cables, I thought Koji said we should disconnect the cable from the picomotor and then check for grounding, but I can't remember if that is really necessary.
Bird's Nest!: We found some shorts. When one finds a short, the job is to go in chamber and then "wiggle" the cable in question until you no longer see the short. I believe we were able to do this in-chamber right next to the D6 flange. This is where there is a "bird's nest" of ISC cables (unfortunate...I reckon we could clean this up by carefully clamping ISC cables down to HAM6's Stage0.).
At any rate, whenver one fixes a cable with a ground loop, one must then re-check all cables! This is because all these cables are in this "bird's nest". And if you remedied one by moving it around, you don't know whether you made things worse for a neighboring cable in the "nest".
At the end of the day, we were happy with our ground loop checks for these cables.
OH, a To Do Item:
At the D6 Flange, it was easier for Fil to plug/unplug cables when he removed some protective bars were removed from the flange protector. At the nearest convenience, those bars should get re-installed.
Re the To Do Item--removal of the 'protective bars' aka strain relief, to make it easier to unplug cables. These should be replaced and returned to relieving strain by the remover. There is plenty of instances where this has not been done and I expect is the SOP, sadly. The job is always so much easier if you don't have to return to it later, after you've remembered it.
> For the Picomotor cables, I thought Koji said we should disconnect the cable from the picomotor and then check for grounding,
> but I can't remember if that is really necessary.
No. It turned out that the picomotors have no shields at the mighty mouse connectors and have no shorting the the table.
HAM6 CC wafer placement - it is now back in the same place as the last one was pulled from.