Re: pic-servo & EMC

> From: Andrew Werby <drewid@...>
>
>[So if the Servo-to-go card is "dumb", is the Pic-Servo "dumber"? Or are
>they functionally equivalent? I suppose a "smart" card would be one with a
>DSP on board? ]

The PIC chip is actually smarter, since it has on-chip PID capability
(we'll get to the PID thing in a bit). Using the PIC, the only thing
for the software to do is tell the PIC where the motor needs to be
driven to. There are drawbacks to that, but at least the PIC lets
just about any CPU handle servo control.

>[Is this the analog control output referred to above which actually moves
>the motors, or something else?]

Hmmm, this might be a good time to give a simple primer on PID...
(what follows is NOT a completely accurate description, it's
intended to shed a little light on control theory in a way that
makes sense to folks without a few years of boring math under
their belts. It's off the top of my head to boot, so don't expect
much ;)

PID stands for Proportional, Integral, and Derivative. These terms
are actual values that get plugged into a generic motion control
algorithim. PID is a 'closed loop' control method. That means that
there is a feedback path (in our case, the path is the encoders
attached to the DRO board or PIC chip) from the end of the process
(the motor shaft) back to the controller. By comparision, a stepper
system is typically 'open loop'. The controller sends step commands
to the stepper driver, and just assumes the stepper can follow them.
This is why it is VERY important to design stepper systems that don't
stall or lose counts. The controller has no idea what's happening
at the motor.

OK, so what actually happens in a PID controller? First, the
controller is told to move the motor to a new position. The
controller responds by comparing the current position to the new one,
and sending a command to the motor driver. The magnitude and
direction of the command is determined by the PID values. Here's how
it works:

The current position is fed into a 'comparator' which sends the result
(the difference) along to the next step of the loop.

The difference is multiplied by the Proportional gain value, and the
result is stored as the 'command'. So, if the difference, or position
error, is large, the command will also be large.

The Integral portion is sort of the same, except it has memory. It
looks at the size of the difference, as well as how long that
difference has been there. If the motor is being held off the target
position for some time, the Integral gain will force the motor to
work harder to hit the target. The best example of this is, you
guessed it, machine tools. As the cutter begins to contact the work,
the motor will start to fall behind the target position due to the
increased resistance at the cutter. The Integral portion of the
controller says "Hey, for the last 3 seconds we've been 200 counts
behind the target! Increase the command!" And so the Integral gain
adds a little more to our command output.

As the motor approaches the target, we need to reduce the command so
that we don't 'overshoot'. This is where Differential comes in. It
is looking at the rate that the motor is approaching the target and
if it's too fast, it will *subtract* from the command. This effect
is often referred to as 'damping' since it is used to damp out
oscillations and overshoot.

The command that results from all this is converted into a voltage
or current and sent to a motor driver, or servo amplifier. The way
it gets converted varies, but that kind of detail is not important to
what we're doing. Then the whole process starts all over back at the
front of the loop.

PID is less than perfect. It obviously requires *some* error to be
present before anything can happen. If there's no error, then the
net command is zero (not entirely true, but close enough). To get
around that, there are some tricks. Most common is 'feed-forward',
which attempts to predict the future path of the motor and tries to
compensate by tweaking the command value. This usually works pretty
well, but not always.

So why am I babbling on about this? Well, it's the PID loop that is
being executed, constantly, inside the PIC chip and in the EMC
program. PID is the number one reason that HSM's will have a hard
time making the leap from steppers to servos. Determining what
particular values to use for the P, I, and D gains is a tricky thing
to do, and changes for every machine. There is no way to determine
them mathematically, and the estimation methods require a lot of
training and experience. Now, you can sit down and plug in some
random numbers, and there are simple procedures to find some good
ballpark numbers, but using bad numbers can result in injury or
broken machines. Imagine one axis of your machine going unstable,
oscillating rapidly about the target position. Imagine it running
just fine unloaded, but having it go unstable right as the tool hits
steel. Not pretty.

If we try to make servo control available to the DIYers, we may want
to write a simple, conservative auto-tune program to help folks over
the initial setup troublespots.

Whew, my fingers are tired!

>[While it's the cheapest thing I've come across that has "servo" in the
>name, it sounds like actually using it with EMC is a long way off- or is
>this all really simple stuff that these guys are going to be able to
>implement quickly so people like me can just "point and shoot"? What, if
>anything, is actually supported presently, that I can just buy and hook up
>to my servo mill? Learning to use Linux is going to be hard enough for me-
>writing all this code is going to have to wait for another lifetime...]

If we design and build our own I/O boards, this could be far cheaper
than the PICServo solution. The DRO board is halfway there, all it
needs is DAC output to get the job done. The more expensive part is
the servos and amps. Plain-jane PMDC motors don't often work well as
servos, due to cogging and wear and tear on the brushes. The surplus
houses are going to be our saving grace, if we ever get to that point.

Some input from the EMC team is needed to determine how far off this
might be. I don't know how much coding needs to be done to support
a dumb I/O card. The PICServos would require a bit of extra work,
and also throws away a good chunk of the code that's already there.

-Tom Kulaga