[Jenne, JeffK]
We discovered a bug in the guardian code that was modified today, that ended up with us locking at the August spot positions rather than our goal of the July positions. Since we really do want to go to the July positions, I have prepared the guardian to do so, although there is also a backup plan in there so that if it doesn't work, the operator can revert and just lock at the July positions. This should only be necessary in case of lockloss tonight, as commissioners will address this more fully in the morning. But, if we lose lock, we'd (Jeff, Keita, and I) like the operators to try locking at least once with the new code.
The new version of ISC_LOCK's ENGAGE_SOFT_LOOPS now has 12(!) counter steps. Half of these are convergence checkers, so we can probably clean this up at some point, but for now I've just extended the methodology that we'd been using.
To use this code, if we lose lock, the operator will need to load ISC_LOCK.
If this code does not work ("not work" will likely look like power buildups falling low, and then lockloss), open up lscparams.py Try at least once, maybe twice if it looked like it almost worked. Comment out lines 249 through line 287 in lscparams.py. Uncomment lines 289 through line 332. Load ISC_LOCK. This replaces positionA, positionB, and FullPower all with the August positions, so should effectively be the same as we've been doing the last several lock acquisitions.
lscparams.py can be found by: >>> cd /opt/rtcds/userapps/release/isc/h1/guardian/ Or, the edit button from the guardian screens often brings it up automatically.
If there is an error in ISC_LOCK and it's not an obvious thing that you're able to diagnose and fix, you can revert to the recent version from the svn (both lscparams.py and ISC_LOCK.py). You can also call me at any time tonight, and I'll help.