Re: [CAD_CAM_EDM_DRO] Servo systems

Jeff Barlow wrote:

> I'll start with the position verses velocity issue. I'm becoming more
> convinced that this whole velocity thing is mostly a red herring. We're
> not controlling motor speed we're controlling torque.

Well, we control torque TO control speed!

> We're somewhat
> interested in feed rate, but it's a rather low precision parameter.
> We're mostly trying to put the cutter in right spot at all times.

But, to make corrections of small position errors, we need to make
small adjustments in speed, without the high speed feedback to see
the small changes in position through the encoder.

> Please humor me while I indulge in a little exercise in which I attempt
> to start this all over with a clean piece of paper. Let's say we have a
> smart machine that can tell time, that always knows what the
> instantaneous position of the cutter should be verses what it really is,
> and that can control the instantaneous torque applied to the feed screw
> of each axis. That should be all we need.
>
> Well, here's where that ugly little bandwidth issue pops up. The above
> is "all we need" only if it's fast enough. If it reacts too slowly to
> position errors we get ugly, lumpy parts. It's pretty clear that a PC is
> way too slow for this. However, a PC has many other attributes that
> justify it's inclusion in the system.

The PC may not be too slow, but I was working with standard interfaces,
as EMC and most other servo motion control systems are designed for.

> A PC is, for instance, good at the math required to handle coordinated
> motion and to keep the acceleration rates reasonable. This stuff could
> be done with a whole mess of opamps (remember analog computers?), but we
> would end up with way too many trimpots. It's too ugly to even
> contemplate.

Well, I've already done it. The principal op amps are only 3 per channel.
There are others that are involved in signal level shifting, PWM pulse
generation, etc. Yes, there are a number of trimpots, but you do need them.

<snip>

> Let's go back into the PC a moment. I assume it's interpreting G-code,
> that's mostly position information. I also assume it's reading position
> feedback from an encoder. It then seems most strait forward to output a
> position command to the servo amp. But when I look at EMC I find it
> pumping out velocity commands.
>
> The only good reason I see for this is that conventional servo amps all
> seem to want velocity commands.

Yes, partly.

> (This makes the Geckos unconventional
> servo amps, I suppose.) Someone, somewhere originally conceived the
> servo amp as a closed loop motor speed controller rather than a position
> controller. So, is this all just one of those silly "thinking inside the
> box" foul ups?

Yes, partly, again!

> Well, no. There is this other messy bit with continuous verses discrete
> output sensors. It seems the readily available continuous sensors are DC
> tachs. Unfortunately, they tell us velocity rather than position. The
> readily available position sensors are relative encoders. Being
> discrete, though, they don't tell us quite what we want to know, when we
> want to know it.
>
> This leaves me stuck with either accepting stepwise, notchy motion and
> hunting (dithering), or the rather inelegant expedient of using both
> position and velocity sensors.

Actually, a number of CNC manufacturers have already gotten rid of
the DC tachs! They do it by putting a $60 DSP chip in the servo amp,
driving either a 'brushless DC motor' (more accurately a 3-phase
permanent magnet motor) or a true 3-phase induction motor, and putting
a very high resolution shaft encoder on the motor. These things do
the calculations anywhere from 30 Khz to over 100 KHz and output
drive signals to the motor. Unless you get incredibly lucky at the
junkyard, don't even ask what one of these AC servo drives (motor
and amplifier/control) costs!

Yes, the velocity feedback servo definitely gets rid of the nasty
dithering!

Jon