Date: Fri, 10 Aug 2007 09:29:31 -0700
From: Russell E Owen
Subject: Re: 2.5m obslog 20070809 (MJD 54322)
At 3:07 AM -0600 2007-08-10, Steph Snedden wrote:
>During the afternoon, French called up Russell who then called Craig so
>we could work on the TCC problem noted in last night's log.  Recall that
>commanded slews would accelerate, go about halfway to the destination,
>decelerate, stop, errors would accumulate and then the axis would
>abort. It turns out that the new TCC acceleration and jerk parameters
>were set to work optimally with the 3.5m, and those values don't work
>with the 2.5m.  When Russell increased the accel/jerk by a factor of ten
>(I think that's what he said), then all our slews completed normally. We
>tested slews succesfully in all three axes.
The motion parameters (velocity, acceleration and jerk limits from
tdat:axelim.dat) were unchanged with the new TCC code (they were not
from the 3.5m telescope). However, the old TCC code had severe limits
on how short each segment of a move could be and on how short an
overall slew could be. The modern TCC greatly optimized these
calculations to permit faster slews. In essence, the old TCC limited
jerk time to about 1 second, eve if the jerk limit in tdat:axelim.dat
was faster.
Unfortunately this optimization tickled an exotic but completely
reproducible MCP bug: if motion segments are too short, the MCP
decides to slew half the requested distance. Then when tracking
commands start coming it, the MCP realizes it is in the wrong
location and goes out of closed loop.
The solution was to modify tdat:axelim.dat so that the jerk time was
1 second (jerk = acceleration / 1 second) for all three axes.
I will file a PR against the MCP. I hope that eventually the MCP can
be fixed or replaced (perhaps with the new axes controllers going on
the 3.5m soon). The bug is quite disturbing -- I have no idea where
the limit is, nor am I entirely confident that we always avoid it.
-- Russell