bram.slagmolen@LIGO.ORG - posted 15:14, Wednesday 22 August 2012 (3942)
SNAP files
[Jeff G., Bram]
Made new safe.snap files for ISCEY, ETMY, TMSY and ITMY.
[Jeff G., Bram]
Made new safe.snap files for ISCEY, ETMY, TMSY and ITMY.
The H1 suspensions on HAM2 are currently broadcasting a constant "0" as the watchdog state to other FrontEnds on the Dolphin network via an IPC library part. This value satisfies the HAM-ISI Simulink model condition for a "0" input in order to prevent the triggering of the "DACKILL" functionality. To further complicate the issue, the error signal from the receiving IPC part on the HAM-ISI model is currently reading out a non-zero error, meaning their is a communication issue on the Dolphin network. A bypass on the receiving model ("h1isiham2") in the form of a constant "0" for the communication error will enable the functionality of actuation from the HAM-ISI user model.
The true watchdog signal from the SUS models will be broadcast as soon as the Dolphin network communication issue is resolved.
Ability to log out a user out and not have the previous users info saved, so I can log him out and log myself in without clearing cookies. This is not Jeff Garcia. Also, I'd like to be able to add captions to attached files.
The logout issue is a known limitation with the LIGO.ORG authentication on shared workstations. You need to completely close/kill the browser, or open a different browser (not just a different browser window). The authentication is not handled by the application, it is handled by the LSC auth project login server (login.ligo.org). Clicking aLOG log-out button does in fact clear all state in the application associated with your session. The issue is that the aLOG does not have a way to affect the state of login.ligo.org. So this is a known issue, it will be fixed at some point. The benefit in account and password management of using the LIGO.ORG credentials appears (by far) to outweigh the inconvenience of having to kill the browser when you work at a shared workstation.
The first of your requests has been a request since last summer, see LHO aLOG 1000. I know Jonathan Hanks is working on this.
We had a timing glitch at EY which required a restart of all EY front ends. I took the opportunity to install the new h2tcsetmy model for the ring heater.
I did a manual burt restore of the safe.snap files and found problems with
I'll fix the ones marked *
I restored ISCEY, ETMY and TMSY to 3am, 22 August 2012.
I have attached 2 plots:
LHO_ISI_ITMY_Calibration_Check_Stage_1_Sensors_201208022.fig shows the calibrated transfer function from the Y drive to CPS, L4C and T240 on ITMY. Calibration is OK. LHO_ISI_ITMY_Calibration_Check_Super_Sensor_201208022.fig shows the contribution of each sensor in the stage 1 250mHz blend in the Y direction. The calibrated TFs are slightly different in the 2 figures due to the introduction of the calibration correction gain to improve the blend (amplitude - phase).
After Robert's presentation on magnetic coupling today at the Systems meeting, I wanted to double check that the calibration in place were the final numbers that Thomas and I had calculated, having remembered that the incorrect numbers were stored in the safe.snap, and were restored incorrectly a few weeks ago. When there is down time in the cavity commissioning: please turn off the suspension and grab a new safe.snap. ETMY's numbers are confirmed to be correct.
HAM 3 ISI
Ok, I could not help myself. It all looked fine, so I engaged the Trilliums on the ISI's. Attached are the blend screens, showing what trillium blends are engaged (due to the great work by Vincent on organising the scripting behind the buttons!).
The RefCav still drops and relocks (as for the arm), but I am sure we can make a spectrum in between the drop spikes. It is runnig as of the time of this entry.
Advised not to enter the LVEA otherwise the Trillium will trip, and not sure if the ISI will trip as a whole or drops to damping only.
Earlier this evening I kept the arm locked, but we unsuccess full in generating a proper spectrum. This was because the RefCav kept dropping lock every ~10 min or so, see the first attachement of the StripTool.
I did manage to get a spectrum (only 8 ave in a <10 min stretch), and it is nice to see the noise above 1 Hz dropping due to the work on the RefCav. In the other hand we have not made anyhead way at the lower frequencies.
To that end I tried to engage the Trilliums on the ISI's, which I did but then got trumped by the 10 min lock treches. I was worried to keep the ISI running with the Trilliums overnight, so I reverted back to running with the L4C's overnight.
When writing this entry, the cavity is still locked, but has the ~10 min lock loss after which itself brings into lock. This is sort of an hiddious autolocker:)
Oeps, just noticed the units in the spectrum are missing. They are [nm/rtHz].
[Daniel, Alberto,Bram] 17 August 2012
We found a 221 kHz resonance in the laser PZT. We modified the PZT notch filter in the TTSFF, by changing C47 from 910 pf to a 1000 pf and a 68 pf parallel to each other. With the variable capacitor C46 we managed to set the notch frequency to 219 kHz. Although we should see a -23dB depth, we only measured -10dB. In the end this seemed to be ok.
Attached are plots of dust counts > .5 microns in particles per cubic foot.
I spent several hours in the optics lab to diagnose the FSS trouble that we've been experiencing lately. I've found two failure modes though there may be more. One was fixed and the other was not.
1) EO monitor slowly creeps up due to 14.4 kHz oscillation building up.
Fixed by rebalancing the PZT-EOM crossover. (Fast gain was 592 or something like that in the morning, now it is 815).
In this mode, FSS still appears to be locked and the REFCAV transmission looks OK, but if you lock the arm your arm transmission slowly degrades, and after a while it becomes impossible to lock the arm.
When you look at the EO RMS monitor and the PZT fast monitor on the oscilloscope, EO monitor creeps up very slowly though you wouldn't notice anything in the PZT, so you would think that this is some really high frequency stuff.
However, it turns out that this is almost entirely due to 14.4kHz oscillation slowly building up. PZT signal has lower frequency crap so 14.4kHz is not that apparent on the oscillo.
Attached shows the spectrum of the common path test point in the FSS box in bad and normal state.
2) Fast glitch in PZT.
Not fixed.
This is distinctively different from the first one in that there is a big fast glitch observed in the PZT signal first. ("Fast" just means that it looks instantaneous on the oscilloscope that is set to its slowest setting, so it could be 100Hz or 100kHz.)
Sometimes the PZT can take it and the signal goes back to normal after a while. Sometimes the PZT cannot, and the refcav loses lock. It looks like the refcav can relock itself in this mode even if the lock is lost.
EOM monitor doesn't show anything until refcav loses lock.
Even though the glitch itself seems to be fast, what seems like a transient response of the servo is very slow (slower than 1Hz).
I wanted to see the glitch on the analyzer in real time, but somehow it happens only when I'm not looking at the screen. We need a good young scientist who can sit in front of the analyzer without blinking for an hour.
All awtpman processes were restarted with the latest code.
New sus models were installed for MC1, MC3, PRM and PR3 on h1sush2a.
The crash of h1susim model was tracked to a missing ipcRfm=1 flag on h1iopsush2b. In the process we imported local modified files from LLO for:
and I imported l1susim.mdl to make the h1susim.mdl but reverted the ADC channel changes made on the l1 model.
I changed H1's SITEMAP.adl to add a second SUS pull down for the IM medm screens (copied the links from LLO).
For anyone new to the IM optics naming, here is a conversion table from old to new names
| SM1 | IM1 |
| PMMT1 | IM2 |
| PMMT2 | IM3 |
| SM2 | IM4 |
ISI models for HAM2 and HAM3 were changed to read out IPC error rates into EPICS channels. We are seeing errors on watchdog IPC channels but not on OPLEV QUAD channels which is confusing. This investigation will continue tomorrow.
Following the thunderstorm, all LVEA front ends had timing errors and h2pemeyaux was frozen. I rebuillt all the cornerstation models against RCG2.5.1 and tested that the IOP watchdog still worked between h2susb478 (ITMY), h2susb78 (FMY) and h2seib8. Then Vincent made his model changes which convert EPICS comms to Dolphin IPC and verfied that RCG2.5.1 has fixed the Dolphin error he saw last week with RCG2.5.
h2pemeyaux required a power cycle to bring it back.
All H2 awgtpman processes were upgraded to the latest version.
The new ring heater code on h2tcsetmy upgrade was deferred until tomorrow to not impact on OAT work.
h1isiham2.mdl was modified to apply a constant at the error input of the HAM2_PAYLOAD block (see attached picture). The constant value is 0. It corresponds to the Dolphin communication error value for the state of SUS model running
Modifications were commited to the SVN. The model was re-compiled, installed, and re-started.
This modification of h1isiham2.mdl will have to be reversed when rcg is updated on site (planned for 08/28/2012).
The modifications applied to SUS's models will need to be reversed when suspensions are installed on the ISI.