kyle.ryan@LIGO.ORG - posted 16:03, Thursday 24 April 2014 (11564)
~1515 hrs. local -> "Burped" unpumped volume seen by PT246B into adjacent RGA volume
Days Activities
Went through the Operator check of saturations with HEPI this afternoon. The HEPI Saturation Counters which I had to reset were:
HAM2, HAM4, ITMx(BSC3), ITMy(BSC1), ETMx(BSC9), ETMy(BSC10)
A pressure sensor at MY had been MAJOR Alarming the last few days, but this is due to it being worked on. It will be displaying values of a higher pressure for a month or so while it is valved out and being worked on. To prevent getting alarms from this, we've bumped up the MAJOR alarm setting to 1x10^-6 (originally it would alarm at 5.11x10-8).
Since the Vacuum computer was really slow, Dave ssh-ed into the computer (still was slow) & did the following:
vacuum@control0:~$ caget HVE-MY:Y5_246BTORR.HIHI
HVE-MY:Y5_246BTORR.HIHI 5.11e-08
vacuum@control0:~$ caput HVE-MY:Y5_246BTORR.HIHI 1.00e-06
Old : HVE-MY:Y5_246BTORR.HIHI 5.11e-08
New : HVE-MY:Y5_246BTORR.HIHI 1e-06
We must revert the alarm setting when the VAC work is complete.
Baking will continue for as long as a few weeks
HEPI safe.snap files had the wrong ..._L4C_THRESH_MAX values recorded, as pointed out by Dave yesterday. Those safe.snap files are now fixed. The new versions are committed under the SVN -r7796.
Details are attached.
The Apollo crew was unable to get wrenches to the large clamp bolts which retract the bellows of the chamber's west side 60" flange. We needed to remove the Feedtrhu protection shroud and the cabling attached to the feedthru. So the WHAM6 isi interface electronics were powered down.
model restarts logged for Wed 23/Apr/2014
2014_04_23 08:46 h1nds1
2014_04_23 08:53 h1fw1
2014_04_23 09:03 h1broadcast0
2014_04_23 10:02 h1asc
2014_04_23 11:06 h1susmc2
2014_04_23 11:29 h1susprm
2014_04_23 11:38 h1sussrm
2014_04_23 11:52 h1susmc1
2014_04_23 12:01 h1susmc3
2014_04_23 12:11 h1suspr2
2014_04_23 12:18 h1sussr2
2014_04_23 12:58 h1suspr3
2014_04_23 13:08 h1sussr3
2014_04_23 13:16 h1broadcast0
2014_04_23 13:16 h1dc0
2014_04_23 13:16 h1fw0
2014_04_23 13:16 h1fw1
2014_04_23 13:16 h1nds0
2014_04_23 13:16 h1nds1
no unexpected restarts.
815-828
mike, daniel, stefan, aiden, terry, bubba, margot, ski, matt h, jason, patrick, hugh, jeff, jodi, andres, corey, richard, pablo, david H, jimW, thomas, filiberto
While the Gate Valves were closed and we were Laser Safe, I installed a pair of aLIGO Camera Housings on the Spool where the ITMx cameras will be.
Additional Notes:
Lexan covers were already installed on these viewports.
Checked out unused viewports: VP1 & VP4 (see attached map). Line of sight looks good for both of these viewports. I installed camera housings and kept them on both of these viewports.
Currently VP5 has the sole ITM camera.
Pictures of this work are located here.
Re-did measurements from yesterday. Daniel brought up point about green light leaking into IR measurements and vice versa. So addressed this.
IR Laser Light: Look At filters to attenuate IR
Here we wanted to see which filter was best for viewing the GREEN light, so we wanted the filter which passed green & cut out IR. With the Prometheus laser we used its IR light. To make sure there was no Green light, we dropped in a Hoya R72 filter (to remove any Green light from laser). Then we looked at the filters I bought . So this is what we had:
The BP550 is OK, but Daniel says the OD of this filter may be low and we should look for a Schott glass filter (order of 4mm thick, similar to our old iLIGO glasses). Either that or we can see what a couple of the BP 550s filters look like in series.
GREEN Laser Light: Look At filters to attenuate Green
Here we want to see which filter is best for viewing IR light, so we want a filter which passes IR & attenuates Green. With the Prometheus laser we had green light. To make sure there is no IR light leaking in, we dropped an iLIGO goggle in the beam path as a filter.
LP 920 may be good...maybe have two in series?
So the plan is this.
For Green-viewing camera, we will actually use a 4mm thick KG5 Schott filter (these are on order from UQG Optics in the UK).
For the IR-viewing camera, we actually want to try the LP 550 from the entry above (the LP920 & Hoya R72 will show IR light, but we won't see much else). Since we have one of the LP550s, we can test out this filter now. Want to make sure we can easily install this on the Rainbow zoom lens (without disturbing alignment). If we like it, we can order more of these guys.
Alexa, Stefan - With the y-arm o.k. (the remaining glitches were actually bleeding in from x-arm locking), we realigned the x-arm. - Note: we need to switch back to a better camera view for the x-arm transmitted light. The current one does not provide a lot of information because a) it is completely saturated and b) it is in a guoy phase that is not very sensitive to TMS alignment. - Once we had both arms aligned and locking fairly reliable, we looked at the DIFF electronics: - First we found 3 switches on the VCO and FDD that were left off. - Next we noticed that the DIFF beat note was only -32dBm - we verified the EPICS read-back with the scope. - So we hooked up the scope on ISCT1, but right then an earthquake struck and knocked out every ISI on site. Thus we went home.
The earthquake was reported as a 6.7 94km S of Port Hardy, Canada (Vancouver Island), at 2014-04-23 20:10:13 UTC-07:00
Today we were able to lock the y arm for a significant period of time. Here are some settings:
PDH REFL Servo Board:
I took a few measurements:
Note: Stefan has since changed the input gain to -13dB and the fast gain to 6dB. The overall UGF and loop shape is the same. See alog 11547
I created a script, createCSD in sys/common/scripts, that sets up all required files and code for implementing a new instance of the control state definition. I also improved the makeMEDMfromOUTXML.py somewhat when dealing with sub-states. createCSD takes the following three inputs: createCSD SYSTEM systemhome snapfile SYSTEM has to be the capital version of the system name, i.e H1ISCEX or H1ECATX1PLC2 systemhome is the system subdirectory name in userapps, i.e. something like als, isc, isi, lsc, omc, pem, psl snapfile is the initial snapshot setting that will be enforced. If not specified, the default safe.snap will be used It uses a burt snap file to create a very simple xml file with no states. Running this xml file will simply continously enforce that snapshot file. Any further modifications can then be done manually in the xml file. Using this I stood up CSD-Guardians for H1ISCEY and H1ECATY1PLC2. I also manually created the same states for H1ISCEY as we have for H1ISCEX, so H1ISCEY is ready to be used. I haven't done the manual edits for H1ECATY1PLC2. I left H1ISCEX, H1ECATY1PLC2 and H1ISCEY running in OP. H1ECATY1PLC2 was left with the Guardian paused.
Alexa, Pablo, Keita, Stefan We noticed that H1:ALS-Y_VCO_TUNEMON and H1:ALS-Y_VCO_FREQUENCY were only reacting to half the range of the drive from the common mode board (H1:ALS-Y_REFL_SERVO_FASTMON). We thus swapped the EX VCO ( D0900605 , S1200562 ) with a H2 spare ( S1200566 ). This fixed the issue. Next we noticed that the PDH signal doesn't bring the arm power to a maximum. With a H1:ALS-Y_REFL_SERVO_IN1GAIN of -13dB, and an H1:ALS-Y_REFL_SERVO_COMOFS of -4.75V we get the maximum build-up, about 1750 counts of H1:ALS-C_DIFF_A_LF_OUT_DQ. With a misaligned ITM Keita and Alexa verified that it is not an RFAM effect. We still see transients in the arm build-up.
Jim and I have been investigating DAQ issues with HEPI ETMY which started over the weekend. Brian noticed that HPI ETMY's L4C Sat Counter started looking like the WD threshold, and was also counting down from 89k to 30k which it should no longer need to do.
We are unsure about the details, but it appears that when Jeff restarted h1hpietmy at 15:02PDT Saturday afternoon , the old INI file was archived but the newer file was used. It would appear that the INI Checksum the FE sends to the DAQ was calculated from the archived file, so DAQ did not show a 0x2000 error for this model. At a later time of 18:50PDT Saturday Jeff restarted the DAQ, at which point the FE DAQ status went to 0x2000 and the data in the DAQ was mixed up (resulting in a WD threshold being named the Sat Count). When I pressed the "DAQ RELOAD" button for HPI ETMY monday morning at 10:24PDT the FE and DAQ synced up and the DAQ data became good again.
When the model was restarted on Sauturday it read the safe.snap file which set the WD threshold level high, hence the ramping back down to 30,000. The safe.snap is being corrected by Brian and Hugo.
I had to "DAQ RELOAD" h1hpibs on monday as well, so it could have the same issues over the weekend.
We suspect the fact that the make-install and model restart occured very close to each other may be a possible cause of the INI file mismatch, but this is pure speculation.
If commissioners suspect any DAQ issues with h1hpietmy and h1hpibs we should restart the models.
J. Kissel I've modified all HAM SUS front end code to receive dither alignment signals from the ASC front end. Currently, however, the sending channels have dummy constants as input at the top level of the h1asc model, because there's work internal to the ASC library block that needs doing. I leave the ASC model changes in the very capable hands of the ISC team. Thankfully, recovery was easy from these changes went much more smoothly than Monday's. We had no guardian machine failures or IOP DAC FIFO errors, and the MC REFL path stayed put. As such, once we went back to laser hazard, the IMC popped right back into business. Obviously, everything went smoothly because plenty of relevant parties were here on site. #sarcasm I have not yet begun to make the necessary MEDM screen modifications (which is how I was able to get through the changes so fast). I'll begin doing so in a bit and post shots later. I also have not committed any of the changed library parts mentioned below, because I'm not sure yet how LLO would like to roll out these past few days of changes. However, all top level models have been committed, since they don't affect LLO. Details ----------------- Of the list of front end models mentioned this morning, I got through h1asc SUS top-level models: h1susprm h1suspr2 h1suspr3 h1sussrm h1sussr2 h1sussr3 h1susmc1 h1susmc2 h1susmc3 SUS library parts: FOUROSEM_STAGE_MASTER FOUROSEM_STAGE_MASTER_OPLEV SIXOSEM_T_STAGE_MASTER HLTS_MASTER HSTS_MASTER MC_MASTER Though the IMC models do not receive dither, they use the HSTS_MASTER and MC_MASTER parts, so the dither inputs had to be terminated at the top level. Minor mod, but still a mod. I've also added place-holder IPC receivers to the top level of all BS, and all QUAD models, but they're terminated at the top level, since I've not yet made changes to the QUAD or BSFM library parts. I attach lots of screenshots of the affected simulink models, to show how I've implemented the path.
OK, 1e-6 wasn't good enough (Kyle started baking out RGA components today & this shot up the pressure on this sensor). John said I could up the Alarm setting to 1e-05, and if it alarms here, then the VAC crew will just power OFF the sensor.