• it sends the turret to the position and then calls turwaitpos()  to wait for the turret to be in position. 
• The routine is called from within setupall().proc
• see /home/online/Tcl/Proc/pnt/turwaitpos.proc
  
• By default this routine declares the turret to be on position when it is within .1 turret degrees of the requested position.
• The turret plate scale is .45 asecs great circles on the sky for each turret degree.
• turwaitpos() times out in 200 seconds..
  
• I'm not sure if cima times out before this.

    This is a similar to problems we had back in aug14. At that time i thought the problem  was from the backlash board being misadjusted.. but  it turned out to be a problem with the zero velocity offset of the dac that drives the motor amplifier (in velocity mode).

    To find out when this problem started i went back through the turret log files and plotted the turret position and the different (actual - requested turret position):

• The plots show:
• top frame turret position vs hour of day.
• 2nd frame: Actual - Requested turret position vs hour of day.
• The red lines show the limit of +/- .1 degrees when cima thinks the turret is on position.
• 3rd,bottom frames: same info as 1,2.. except a different day.
• The errors should be small when the turret is sitting at one position (while it is moving, the error will be large).
  
• plots of turret position and position offset for 1st day of each month for 2015 (.ps) (.pdf)
• each day has info from the first day of two months.
• You can see that the errors were small on 01nov15 and then large on 01dec15.
  
• The daily plots for nov15 show when the errors increased.
• plots of turret position and position offset for each day of nov15 (.pdf)
• each page has the position and position error for two days.
• the turret was not moving 151109 to 151115
• this was when we had problems with the main contactor being driven incorrectly by some digital outputs.
• when the turret started moving again on 151116, the turret error had increased to up to .05 degrees.
• They probably put a new dac in the turret during the 09-15th testing.
• The error continued to degrade through nov and dec15.
• It's interesting to note that when moving to a new turret position
• the turret would move at 3deg/sec and then arrive at a position (that would be off by some error)
• It would then creep toward the correct position over a few hours.
• The PID loop integrator must be working very slowly...
  
• On 12jan16 the error had gotten so large that it no longer arrived at the .1 degree threshold of turwaitpos().
• I used the procedure (found here)   to update the zero velocity offset for the dac.
  
• Once this was done, the turret came rapidly to the requested position .. to within .005 degrees.

Summary:

• If the turret doesn't come within .01 degrees of the requested position, you need to update the zero velocity offset (see procedure)
• The PID loop does a very slow (hours) approach to the correct position when there is a zero velocity error in the dac.
• This is probably a bug in the code...
  

home_~phil