Re: [CAD_CAM_EDM_DRO] Servo systems (was: re:cleaning, lovejoy, black box tach....)

Jon, all,

Ok, I think this is starting to become more clear to me. One source of
confusion for me has been that we seem to keep talking about several
related, but separate, issues at once. Three of them are: Loop
bandwidth, position verses velocity feedback, and continuous verses
discrete output sensors. Lumping all this together muddles my little
brain, so I need to parse it up into bite size chunks.

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. 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.

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.

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.

So, we partition the system into slow stuff and fast stuff, trying to
minimize the amount of fast stuff to keep costs down. The slow stuff
goes into the PC and we put the fast stuff into some little black boxes
that we'll call servo amps. (I know, it's not too original).

The interface from a servo amp to a motor is too boring to talk about,
so I won't. The other two interfaces to the servo amp are where it seems
to get messy. To me, at least, the most natural parameter to use for
these command and feedback inputs is position. Imagine my surprise and
dismay when I found folks using velocity.

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. (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?

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.

Wait, this just in, there is hope after all! See:
http://www.egroups.com/files/CAD_CAM_EDM_DRO/CIRCUITS/INTEROPLATING+G320.pdf

I do tend to ramble on and on, don't I? While my primary intent here was
to be autodidactic, I hope I've also posed provocative enough questions
so that we may enlighten and entertain a few other list members. If I'm
just being pedantic and boring, I trust someone will tell me to shut up.

Jeff

On Wed, 29 Nov 2000 23:52:34 -0600, Jon wrote:

>
>
>Jeff Barlow wrote:
>
>>
>> When you say: "The current command comes from the velocity error
>> (integrated by an op-amp with a feedback capacitor)", I think "yes, but,
>> that's really position error then, isn't it?". This whole velocity deal
>> starts to seem kind of artificial to me. Am I missing something here?
>
>I didn't state that clearly enough. Writing things from the outside in,
>rather than the inside out : The position error is used to modify the
>velocity command sent to the servo amp. The difference between
>actual velocity read by the tach and commanded velocity is used to
>chenge the torque command. This needs to be integrated (another name
>for negative AC feedback) due to the mass of the drive system.
>So, although this (integrated) error actually DOES work out to
>be (roughly) proportional to the position error, due to the source
>that it comes from, it is not truly position error. The reason is if
>the machine hits a bump, the velocity servo detects it and compensates
>before the CNC control even gets to see the change. That's because
>the velocity loop is inside the position loop, the bandwidths involved,
>and the (doubly) discrete nature of position reports from the encoder.
>
>Jon
>