Turret not arriving on position
to change the turret dac zero velocity offset
160112: turret not
arriving on position
170219: turret not arriving on position
We have had problems with the turret timing
out waiting to be on position. The turret positioning sequences
When cima sets up a receiver:
- it sends the turret to the position and then calls
turwaitpos() to wait for the turret to be in
- 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.
If the turret times out, cima log file has:
2017-Feb-19 03:16:12 LOG4 got_cormsg: From
DATATAKING: waiting for turret position:26.64
2017-Feb-19 03:16:53 ERROR end_wait_seconds:
ERROR timed out while waiting for configuring IF/LO path!
2017-Feb-19 03:16:53 LOG1 task_failed:
Task 'waiting on configuring IF/LO path' failed!
When timeouts occur, they have been traced to the zero velocity
offset of the turret dac, It drifts over time until it is outside
the allowable region. This drift can take days.. So we need
to monitor this value daily.. and update the dac before it gets
too far out..
not arriving on position.
On 12jan16 the turret failed to arrive on
position. The final position was greater than .1 degrees from
the requested position.
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
- 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
- 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
- The error continued to degrade through nov and dec15.
- It's interesting to note that when moving to a new turret
- 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
- 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
- Once this was done, the turret came rapidly to the requested
position .. to within .005 degrees.
- If the turret doesn't come within .1 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...
processing: x101/160112/turerryr.pro, turerryrmon.pro
170219 turret not arriving on position.
Timeline of the problem:
- 23:30 a power dip occurred. The system wasreset and the
- 01:38 observation finished. Tsysall run and completes
- 01:40 next observer tries to run. Has trouble when
turret does not get within .1 degree of the requested
- 09:00 luis and phil change the zero velocity offset
from 57 to 80 counts, and the turret now reaches the correct
The plots shows the turret
position and the (Actual - requested) position for feb 1 to 19
2017. (.ps) (.pdf)
- Each page has 2 days of data.
- upper frame: turret position
- 2nd frame (actual - reqeusted) turret position (in deg),.
- The red horizontal lines are the +/- .1 deg turret on
- We first thought that the power dip caused a problem with the
turret. Looking at the data for the month of feb17, you can see
that the error was slowly increasing for about 11 days.
- things were ok until 08feb17 when the actual -req error
started to increase
- on 18feb17 it was getting close to -.1 deg.
We should monitor this error. When it starts to increase, the
zero velocity offset should be recomputed.