Originally Posted by
fenn
while the previous posts are all quite correct, they leave out some important points that should help clear up some misconceptions around this issue. i'm going to elaborate on unterhaus' "theoretical issue" around the use of step/dir signalling to run a motor in closed loop.
(skip this paragraph if you know how PID works)
when a servo motor is commanded to go to a certain position, nothing would happen if it weren't for the PID controller. let's say we are at 0 and want to move to 1 inch. first the motion planner commands "1" and the motor is still. The difference between commanded and actual position (following error) is 1 inch. This is multiplied by the P value, (which was set to say 500 by the machine builder) and then output through a digital-to-analog converter, which usually has somewhere around 10 bits of resolution. This high-resolution signal is amplified and converted into high current to actually put torque on the motor. Now the motor picks up speed and it's cruising along at a good rate. We're at 0.5" now and still have 0.5" to go. P is still adding 250 whatsits to our torque command but we want to slow down before we overshoot the 1" mark - the torque command should be negative! This is where the D term comes in - it slows down the motor by reversing the torque command when we are going too fast. If P and D aren't both set properly, the motor will be sluggish or will oscillate wildly and overshoot the endpoint. Even if P and D are set right, the torque command must faithfully represent their wishes to the motor amplifier, or you get the same problems.
Now, stepper motors by comparison have a very simple control scheme - if you aren't there yet, take another step. While a microstepping drive can have a position resolution approaching that of a low end servo, its control resolution is still far inferior. Let's say you had a 10x microstepping stepper (2000 steps/rev) with a 250 line encoder (1000 counts/rev) and you are behind by one encoder count, or two steps. The driver's options are: take one step, take two steps, take three steps, etc. If you take one step, you advance the counter one position in the stepper drive, which changes the currents in the coils a little bit, and gives a tiny amount of torque to the motor, which would be enough to move the motor to the desired position eventually, but it won't get there as fast as the motor is capable of doing. If you take two steps it advances the balance-point a little more, and you get a little more torque. Now as soon as you try to take three steps the balance point ends up overshooting the goal point, so you have to take a whole lot of steps backwards all of a sudden once you want to start slowing down. Essentially what you have is a two-bit torque command with a lot of delay built in. This delay is what really hurts the concept.
It takes a certain amount of time to send those step signals. If you're using cheap (free) parallel port hardware with a maximum step rate of, say 50KHz, (a generous value, and ignoring jitter, latency, and other nasties) then taking 3 steps forward will take 60 microseconds, and taking 6 steps backwards will take another 120 microseconds. We're starting to get into the range of frequencies where our not-so-rapidly changing magnetic fields will actually move the motor backwards and forwards, so there is a limit here in how far you can advance or retard the balance point in order to get more or less torque. This makes for a sluggish control that also tends to overshoot. And we still haven't gotten to the main problem.
The big problem is that PID doesn't work for steppers. In a servo system, when your 2" endmill hits a large chunk of cast iron, the following error increases and the drive pumps out more current to compensate. This puts more torque on the motor and gets it back on track. If we have a stepper with an encoder, when the endmill hits the chunk of cast iron it puts a torque on the stepper that is higher than the torque that holds it at the balance point and it falls back into the previous "well" a full 10 microsteps in the wrong direction! The following error builds up, and in response the drive commands an extra three steps to increase torque. But a stepper loses torque as it speeds up (due to coil inductance and eddy currents in the iron from the 200 magnetic poles), so the torque pushing back on the motor is already higher than the torque that would cause it to accelerate forward, so it continues on at the same speed. You've just lost a full step but can't do anything about it!
To be fair, there are some things you could do: 1) slow down the commanded feedrate so it appears to the drive that it's accelerating relative to the commanded position. this should work using something like realtime "adaptive feed" but it has to work fast, your other axes have to decelerate suddenly to stay synchronized, and i've never heard of anyone doing this before 2) add a "boost current" signal to the stepper drive to give the motor more torque for a brief period to recover steps. unfortunately, most drives don't come with this option. also, you might damage the motor's magnets by pushing too much current through it at once, since high performance steppers generally run right on the edge.
Although closed loop control of steppers may theoretically be possible, all these problems combined with the fact that you will end up needing specialized hardware anyway means that you should just buy the right stuff to begin with.
The different approach that mariss was talking about is to send a torque or velocity command to a specialized motor driver instead of step/direction. If you go that far, you might as well just design your drive for real AC servo's with a reasonable number of magnetic poles in the first place, and leave the steppers alone.
I for one would really like to see some inexpensive AC servo drives on the market...
*glances over at the pile of sanyo denki's*