Problem(s) Encountered:

Telescope wouldn't stop slewing, instead oscillating in RA around the desired position until we pressed the  stop  button, which also stopped tracking.  Eric had us restart the TCS control system and adjust a bolt on the back of the telescope which seemed to solve the issue.  Occasionally had double stars in the e-w direction, possibly still indicating an issue with the RA drive/bearing (also had lots of extended PSFs from wind). Couldn't guide for more than 5-10 minutes before losing the guide star.  After reacquiring guide, the telescope often had moved a few arcseconds, ruining mask alignment.

Specific problem with the oalign.py script - the boxes drawn from the .oms file are flipped in in the y-axis compared to those displayed in the image.  The rotator angle offset in the solution also appears to have the wrong sign (although hard to tell as we often lost guiding between acquisition images).

Solution:

I think as the telescope drive components worked themselves back into comfortable placement, the system went through some hiccups.  This seems justifiable as the telescope has been performing well since then.
The guiding issues may stem from improper calibration settings.  A calibration routine was performed, resulting in x- & y-speed numbers that were a factor of 10 off from the documented values (x=-7.8, y=-7.3).  Wind was also obviously a factor.
I cannot speak to the issue with oalign.py, but perhaps the author of the code could?

Revision re: softwarte alignment issue:

As for oalign.py, my own solution is to use my own code, osctrtask.py, instead. [Thorstensen]

I have occasionally seen the sign flip thing in oalign.py, but have not been able to track it down. The solution is easy, namely to put a factor of -1 in the code that reports the offset. I think I have done this fix, and removed it, and done it again, about a half dozen times over the last ten years. As that implies, something else must be going on. Options include switching the order of marking the boxes and stars, nefarious observers fixing the code themselves, changes in now the CCD is installed onto OSMOS over the years, I am losing it, and possibly gremlins. To test if the code has changed, you can re-download it from the OSMOS website. 

http://www.astronomy.ohio-state.edu/MDM/OSMOS/#multiacq

Tests of the other hypotheses are harder to design. [Martini]

I have a version of oalign.py in /data/hiltner/wagner that has the -1 flip removed in the code.  Line 789 but I left Paul’s comment in so I could find it again.  But I can’t be sure or don’t remember if it is just in the portion of the code that works with only the -l option on the command line. That is the option I use.   Line 789 is the only place in the code where gdx is calculated and that is where I fixed it.   I needed to remove the -1 to get oalign.py to work consistently for me some years ago.  It is what I use now and it works.  I can tell right away after my first acquisition if I have the wrong code.  It’s possible that others copied my code to other directories and used it.  I just checked and my version seems to be in /data/hiltner and on the home account of mdm24ws1.  I wonder if there might be a problem in oms?  [Wagner]