question on closed loop vs open loop (servo systems)

disclaimer:
I'm not picking on the Gecko drives, they were just a good example (and I was looking at using them)

----background:

I'm working on converting a manual Series 1 Bridgeport to CNC. I plan to use a PC running EMC/Linux for control. I already have the ballscrews installed and I have the mechanical aspect mostly under control. I'm still undecided on Z the axis setup, but I've got a good idea for what I'm doing with the X and Y axes.

I like to think that I have a basic understanding of circuits, electronics and control systems, but I'm still somewhat unsure of the electronics aspect of the conversion.

----

I had decided to use a servo system for my conversion.
I was looking at doing a PC -> breakout board -> Gecko drive -> servo motor setup.

----confusion:

In my research, I've found that a lot of motor drives take "step/direction" input. This makes sense to me for use with stepper motors, which being open loop do not give feedback to the controller.
(and step/direction is an obvious input format)


However, I see that the Gecko servo drives, (and others) take step/direction" input as well. With these servo drives, the encoder feedback is sent straight to the motor drive. From my quick read of the Gecko manual, the only input to the PC is the err/res channel.
(if connected? I got the impression that this was optional)


I'm confused by this.


My thinking is that, despite using servos, a PC/Gecko/servo system won't be any different than a stepper system from the PC (controller) point of view. The computer will output a step/direction, which the Gecko will send to the motor. The PC won't receive any F/B and will be running as a open loop. It seems that having the encoder feedback to the drive will eliminate a(the?) major advantage of servo motors being feedback systems.

Yes, it looks like the servo drives will be implementing localized closed loop control over their respective axes (for their individual steps). Since the axes are not linked I believe they can come out of sync, leading to elliptical error when cutting circles. I'd think that the way to correct this would be to collect all the F/B in the controller and compare the two axes doing the circle to each other and the circle vector... or go really slow, in tiny steps to insure that there is no overshoot/fall-behind... which is how you'd run a stepper motor system. (?)

From the controller's point of view, isn't the only difference between a stepper and servo system using this style of servo drive that the servo drive can notify the controller (through the err/res channel) when the servo misses a "step" (or several...) and is no longer on course, allowing for the controller to kill the program?

----question:

Am I thinking this through correctly?

I will be doing more research, but are there hobby level/DIY servo drive setups that combine the F/B at the controller level?
("3 axis closed loop", vs "open loop over top of 3 independent closed loop axes")

I want to say that a PC running 3 Gecko servo drives is still an open loop system, though with localized closed loop control on the individual axes. Is that correct?
How much difference will having a localized closed loop controller on each axis make vs just using a stepper motor system?

Thanks for your assistance.

Quote:

---

Originally Posted by boonie

I will be doing more research, but are there hobby level/DIY servo drive setups that combine the F/B at the controller level?
("3 axis closed loop", vs "open loop over top of 3 independent closed loop axes")
.

---

One DIY route is to use a motion card like Galil www.galilmc.com , they come up on ebay all the time.
There are also demo video's on the Galil site, Camsoft use these cards to run their CNC software.
The cards close the loop in the controller for all axis.
Al.

EMC will accept encoder signals directly, probably the best option if you want to go that way is to get something like a Pluto-p card, which EMC has drivers for, and use the Pluto to output PWM to a simple H-Bridge driver, this way the PC takes care of the PID, following error, and with the drives disabled you can turn the wheels and watch the DRO update onscreen.

I am in the process of doing just this on my router, but I am a little way off just yet, too many things getting in the way. Got the screen to update position but still have to make the drivers.

Russell

Quote:

---

Originally Posted by boonie

Yes, it looks like the servo drives will be implementing localized closed loop control over their respective axes (for their individual steps). Since the axes are not linked I believe they can come out of sync, leading to elliptical error when cutting circles. I'd think that the way to correct this would be to collect all the F/B in the controller and compare the two axes doing the circle to each other and the circle vector... or go really slow, in tiny steps to insure that there is no overshoot/fall-behind... which is how you'd run a stepper motor system. (?)

From the controller's point of view, isn't the only difference between a stepper and servo system using this style of servo drive that the servo drive can notify the controller (through the err/res channel) when the servo misses a "step" (or several...) and is no longer on course, allowing for the controller to kill the program?

----question:

Am I thinking this through correctly?

---

Closed loop is closed loop. Trying to subdivide it into different stratas and then to specify that only one type is "TRUE" closed loop is not honesty. The step and direction servo drives are very similar in operation to other kinds of servos, the main difference is that the electrical connection between the drive and the controller system is public and open to inspection. Other servo systems rely on black boxes and technical jargon to keep public inspection and comment from affecting opinions. They are also much more difficult to tune and trouble shoot.

There is a misconception that servo control loops are somehow inaccurate. They are not, they are required to fault at a preset error value. The resolution of a servo system can and should be designed to be at least an order of magnitude more precise than the target machine. For example if a controller faults when it is out of position by 125 steps, the resolution of the system is designed so that 125 steps is less than the expected error of the machine. A Bridgeport in good condition can sometimes hold a .002 inch tolerance. If you set .0005 inch as your max deviation from commanded position, any servo fault will be considerably more accurate than the machine can accomplish. At that point your oval circles can likely be attributed to the usual suspects, mechanical backlash and end play.

Fred Smith - IMService
http://www.cadcamcadcam.com

I'm naturally inclined towards servo systems that close the loop in the controller, but for our purposes, closing the loop in a Gecko is a good enough solution.

The systems I use all close the loop in the controller, the advantages I see are electronic gearing and Cam follower etc, also 'scope motion waveform display for tuning.
Al.

those are some big advantages. EMC has a scope that is very useful.

I'd have to say no to "Am I thinking this through correctly?".:-)

What does "closed-loop" mean?

1) Get the difference between commanded position and the actual position.
2) Amplify and filter this difference, call it the position error.
3) Feed this position error to an amplifier so the motor moves towards command position.
4) Repeat steps (1) through (3).

That's all there is to it; command position input, encoder feedback of actual position, the motor driven so that the difference is kept at a zero. Nowhere is it required that the feedback loop include the computer.

In the old days when electronic circuits were built entirely of transistors, diodes, resistors and capacitors (no logic ICs, no op-amp or comparator ICs then), steps (1) and (2) represented a considerable financial investment. Then as now, the motor amplifier was considered expendable to some degree. It was always stressed (high volts, high amps) and prone to releasing the magic smoke if misused. Your investment was kept safe in a separate control box, it got the encoder signals, it communicated with the potentially expendable amplifier via a +/-10 VDC torque command link.

Fast forwards to today. Electronics is dirt cheap. What took whole boards full of transistors, diodes, resistors and capacitors (steps 1 and 2) is now done with $1.98 worth of ICs and a few resistors and capacitors. The real expense today is in the previously expendable amplifier. Now you can combine the PID controller (steps 1 and 2) with the amplifier, dispense with the +/-10 VDC link and call the result a servodrive. Functionally it is identical but it is cheaper and more reliable because now your servo is not distributed at two locations anymore.

The old way was around for a very long time, long enough of a time to give people the impression a combined controller and amplifier (called a servodrive) is not as accurate or not even a servo only because it's not spread out at two different physical locations.

Anecdotally, our pick-and-place machines are "no expenses spared" industrial capital equipment. They have more lasers and servomotors (>12) than you can shake a stick at. There is also computer in each one that orchestrates the whole shebang. Guess what; each and every servodrive has the encoders going back to the servodrives only. The computer commands these drives via a step and direction interface. That is the way things are done now.

Mariss

I want to thank everyone for the help again, you've helped clear some of this up for me. I'm still undecided on what I will be doing, but I'll probably be back with more questions or results of my refit as I work on it.

Mariss, out of curiosity, what brand pick&place machines are you using?

Quote:

---

Originally Posted by Mariss Freimanis

Anecdotally, our pick-and-place machines are "no expenses spared" industrial capital equipment. They have more lasers and servomotors (>12) than you can shake a stick at. There is also computer in each one that orchestrates the whole shebang. Guess what; each and every servodrive has the encoders going back to the servodrives only. The computer commands these drives via a step and direction interface. That is the way things are done now.

---

It's interesting that modern pro equipment seems to use the step/dir protocol between the trajectory controller and the servodrive, and let the servodrive close the loop.
Apparently the advantage of feed-forward terms in a PID loop is not that important (i.e. load fluctuations from changing cutting conditions are much greater than from inertia of machine?)

I would still think that there is an advantage to wiring the encoder signals back to the trajectory controller so that the following error can be monitored. This would be helpful for tuning the max accel/vel of the machine as well as for e-stop.
I could also imagine that you could watch the loading rates on spindle/servos and tune the roughing cycle of a program to use a reasonable 70-80% of the machine's capability.

AW

The trajectory controller does read an encoder. The servos are dual-loop; an interior loop rotary encoder on the motor is read by the drive, the exterior loop linear encoder is read by the controller. The rotary encoder PID servos the motor, the linear encoder reads the axis position directly to null out transmission errors (2.34" or 60mm wide toothed belt). Feed-forward compensation is probably used in the exterior feedback loop.

Mariss

What happens when you are running Mach3 or EMC and the computer locks up during a rapid? I could see the PCI card in the computer continuosly outputting its +10V during a lockup and the amplifier happily zipping the Z axis down into the work causing untold havoc while the locked up computer ignores the encoder counts coming from the motor.

Not saying that a Gecko drive can't fail, but they are much simplier and running firmware not software (or maybe not even firmwire...I seem to remember them being digital logic and analog). I don't think I have ever heard of a Gecko bluescreening...

Quote:

---

Originally Posted by andy55

I would still think that there is an advantage to wiring the encoder signals back to the trajectory controller so that the following error can be monitored. This would be helpful for tuning the max accel/vel of the machine as well as for e-stop.
I could also imagine that you could watch the loading rates on spindle/servos and tune the roughing cycle of a program to use a reasonable 70-80% of the machine's capability.

AW

---

Andy,
Many servo amps have dedicated output for monitoring details like following error. I've seen analog outputs for that purpose. It is safer because failure won't make crazy servos.

boonie,

We have 2 Juki machines and are buying a 3rd one. FS-730 (Zevatech label) and a KE-750L. Both are 3-head machines (about 3 part placements per second).

Mariss

Quote:

---

Originally Posted by KTP

What happens when you are running Mach3 or EMC and the computer locks up during a rapid? I could see the PCI card in the computer continuosly outputting its +10V during a lockup and the amplifier happily zipping the Z axis down into the work causing untold havoc while the locked up computer ignores the encoder counts coming from the motor.

Not saying that a Gecko drive can't fail, but they are much simpler and running firmware not software (or maybe not even firmwire...I seem to remember them being digital logic and analog). I don't think I have ever heard of a Gecko bluescreening...

---

EMC is not all that likely to lock up. In fact, you can have linux crash and the real-time stuff still work -- that actually happened at a demo at the EMC workshop a couple of years ago. A big machine where crashing is a problem better have limit switches that depower the amps. Can't speak to Mach3. Linux is far better than Windows in this regard. I have an open loop unstable machine that hasn't crashed since I moved the control from Windows to real-time Linux. 7 years worth.

[QUOTE=unterhaus;363769] A big machine where crashing is a problem better have limit switches that depower the amps. QUOTE]\

I am really not trying to pick on you, but how do the limit switches help when you are approaching the workpiece with a 4lb facemill spinning at 1000rpm, the computer crashes and the motors moving the facemill into the workpiece for 5 inches until a limit is hit? Hell, they wouldn't even get to the limit switches before the facemill has sent it's 8 carbide inserts flying across the room embedding them in the wall in a pretty pattern.

I guess you could manually move the mechanical limit switches on your mill every time you machine a part so that the switch trips 0.1 inches past where your lowest or farthest cut is supposed to be. Maybe a 2nd 3 axis cnc system that moves the limit switches around would work :)

Not sure why I'm supposed to feel attacked.

from my observations of machine tools, it seems that most machine tool designers assume that lockups will not happen. With EMC, I think it's so rare that I'm certainly willing to risk it. I think if I was designing a machine tool for sale, I'd probably put a watchdog timer in there that would cut the power if the computer locks up. This is trivial to do in EMC if you have the hardware. There must be some issue with step/direction runaways, because there is the analog/mechanical equivalent of a watchdog built into most high-end breakout boards.

I think my amps would fault out if your scenario happened due to high current. The system design certainly is a lot harder if the machine is powerful enough that this kind of problem is really serious. A lot of the machines that people around here are using will survive a lockup just fine.

Quote:

---

Originally Posted by KTP

I am really not trying to pick on you, but how do the limit switches help when you are approaching the workpiece with a 4lb facemill spinning at 1000rpm, the computer crashes and the motors moving the facemill into the workpiece for 5 inches until a limit is hit? Hell, they wouldn't even get to the limit switches before the facemill has sent it's 8 carbide inserts flying across the room embedding them in the wall in a pretty pattern.
I guess you could manually move the mechanical limit switches on your mill every time you machine a part so that the switch trips 0.1 inches past where your lowest or farthest cut is supposed to be. Maybe a 2nd 3 axis cnc system that moves the limit switches around would work :)

---

How is this run-away scenario different for step/dir and for closed-loop-EMC ??

If you can imagine EMC locking up and outputting full voltage/current command to the amps then surely it is as likely that EMC or Mach will lock up in a way that produces maximum step rate in some direction on a step/dir output machine.

Limit switches are needed. So are current limits in the amps. The watchdog idea is probably useful too.
These should all trigger an E-stop of the machine (power removed from servodrives etc).

If you are closing the loop in the PC using EMC you have the additional choice of looking at the velocity/torque command, and can produce an E-stop if/when that reaches the maximum limit (+10/-10 or whatever). That would potentially be faster than waiting for the current to rise and the servodrive current limit to trip?

AW

No, a Step/Dir system is not going to run away by generating pulses, can't happen. Step and direction is perfect for windows, because Bill Gates will occasionally take over your computer for a little too long, and there will be no steps, but you get no unwanted motion either. It works fine with EMC too.


The idea was that the computer froze, so all the advantages of having closed loop in the computer went away. As I mentioned, this is quite unlikely with EMC, because EMC uses RT Linux, which actually runs linux as a task. Linux rarely crashes, but even if it did, the RT kernel underneath will usually still be running.


If someone asks me which is better, step/dir or servos, I will usually say that it depends on what better means. If you can live with steppers, Step/Dir is probably better because your project will get done much sooner. Step/dir brushed servos have some obvious probIems if you don't take care of the broken encoder wire problem. I also think that analog control has some obvious advantages if you can put up with the complexity. It would be better still to have some kind of digital communication of the command, but since there are no standards, that's problematic.

Something must be broken with the forum software, it doesn't show capital letters unless it feels like it.

Most 'real' hardware is going to have watchdog circuit to know when the computer locks up. The mesa card has code in the fpga that checks to see if the computer has comunicated with it - if it has not it sets its outputs to default.

Actally - the servo pluto firmware also has watchdog code.

sam