Re: Comments from expert PID programmers?

On 8/4/06, Jon Elson <elson@...> wrote:

>
> I have a couple problems with all this. In some machines, wear has
> caused friction to
> vary with position, in others, changes in the balance of overhanging
> tables does the
> same.

Good point, also maintenance schedules and lubrication, etc.

> The torsional spring in small leadscrews varies with the length between
> motor and nut. Some of this could severely affect a system that was finely tuned
> at some different position.

This, however can be built into the model fairly easily -- I did it in
Simulink pretty straightforwardly by making the spring constant a
function of the screw position.

> Finally, you have to account for intermittent and
> unexpected impacts from the cutting teeth of the machine. This is in no way a
> steady-state system, and any steady-state tuning will fall flat.

Right now I'm only considering things that a controller can know about
without input from a whole system predictive model (which will
eventually come, I'm sure, but not for a few years). The question I'd
have back is would a semi-dynamic system be thrown unstable by such
things? If the tool impacts are averaged, they could be modeled as a
constant force, maybe. If the positioning system is deeply married to
the overall control system, it'd know when the tool was going to hit
and be ready for it. Again, not soon, but perhaps not decades away
either.

> Second, backlash can't be "compensated", due to the finite time it takes the motor
> to get to the other side. if you don't know the amount of free play at that position,
> then the motor slams into the end of the backlash at high velocity, and you have a
> severe hammering. Even if the code knows the amount of backlash to be compensated
> out, the motor still has to accelerate like mad, and then brake so as to
> just nudge the
> machine from the other direction. Immediately after the nudge, it then
> has bumped the
> table in that direction, and may have to run to the other side to nudge
> it back. There's no
> free lunch here, no matter how much digital signal processing you throw
> at it, hardware can't
> be "in two places at the same time", unless the backlash is already very
> nearly zero.

This is absolutely true assuming a requirement for continuous motion
through a thrust reversal, but when I thought about a mill, I didn't
really see any requirement for dead-zone backlash to happen in zero
time, leaving the controller free to ease through the entire thing. So
if the controller knows the thrust reversal is coming, it can ramp the
speed down (even a very steep ramp should work), proceed across the
dead zone at a pre-determined safe speed, and hit the other side
gently, watching the current draw to know when it was there. Screw
torsion would actually help here to make a soft landing.

So what would happen if you were milling a circular channel for
example? That's four thrust reversals. If the milling head pause for a
couple of milliseconds at the 0, 90, 180, and 270 degree points, you'd
see a change in the finish where the milling head got to rotate freely
for a while -- a smooth spot in a field of little tool marks.

But it would be accurate, and the results would still be better than
no compensation. So I think this effect might lead to people wanting
zero-backlash for speed and finish considerations, but not really
needing it to make accurate parts.

The only other way I've come up with to do it required two screws and
two motors on each axis, which killed any cost advantage, so I
rejected that a long time ago.

Frankly, though, I don't think dead-zone backlash compensation is
biggest worry, but the screw torsion backlash, which lends nicely to
computational solutions.