Hi all,

I saw this post and thought I’d try to clarify some topics about ClearPath servo motor systems that seem to cause a lot of questions. Disclosure: I’m an engineer at Teknic, and involved in ClearPath’s design.

*** Encoder resolution ***
ClearPath servo motors (less than 1 hp) have a 12,800 count per rev optical encoder. This provides a repeatability of 0.028 degrees. (ClearPath motors of 1 hp or more have a 64,000 count per rev optical encoder which provides 0.006 degrees of repeatability.)

For technical reasons beyond the scope of this post, we limit the command resolution to 2x the encoder resolution. Command resolution is the smallest increment that the motor can be commanded to move, i.e., 0.056 degrees for the smaller motors (with repeatability of 2x better than that). This means, for example, that if you have a fractional hp ClearPath motor connected to a 5 turn per inch ballscrew, you can command moves as small as 0.00003 inches.

This command resolution is well beyond the capability of most mechanical systems, and is sufficient for almost all CNC applications. (With some ClearPath models you can save about 15% by opting for a lower command resolution—but still get the same 12,800 count/rev encoder resolution—and you would still achieve 0.0002 inches of linear resolution in the above ballscrew example.)

During ClearPath’s development, we looked at using a 16-bit magnetic encoder because it was actually much cheaper than the optical encoders we were looking at (and the one we ultimately chose), but we decided against it for several reasons. The native resolution of these magnetic encoders is actually very low; in other words, they must significantly interpolate the magnetic signal to get their stated resolution.

For example, it’s not uncommon for a magnetic encoder to use a 2-pole magnet, which means it natively generates only one sinewave per revolution. The motor position is estimated based on the output amplitude of the hall-effect sensors that measure the magnetic field strength of the magnet as it rotates.

You can imagine the difficulty of accurately dividing one sinewave into 65,536 parts (16 bits) in the face of errors such as run-out, noise, offset, short- and long-term drift, sensor hysteresis, non-linearities, temperature effects, etc. Even though we could have compensated in firmware for some of these errors, the ultimate accuracy of the encoder would have been only about 0.1 degree (1 part in 3,600). Because of the extreme interpolation, the accuracy of magnetic encoders is nowhere close to their stated resolution (the accuracy is typically 15-20x worse than the resolution). This situation is even more pronounced with a 20-bit magnetic encoder.

These magnetic encoders also have a serial output rather than a direct high-speed output right from the sensor. This means that the servo algorithm has to wait for position updates (typically about 100 microseconds) rather than getting continuous feedback. This delay in the position (and velocity) update means that the servo is always using somewhat stale position and velocity data (e.g., at 3,000 RPM, you would have a positional change of 327 counts before the servo knows anything has changed). As you can imagine, accurate and timely encoder data is crucially important to the quality of servo performance.

Considering these disadvantages, we decided that the cost savings of using a magnetic encoder were not worth the performance degradation. And the resolution of the optical encoder is more than sufficient.

*** Encoder Noise ***
It is true, as Mactec54 and Al_The_Man state, that it is very possible to wire a modern, well-designed servo to get a system that is free from noise problems. You must, of course, use appropriate cable (suitable for the peak encoder signal frequency—which increases with encoder resolution) and proper grounding/shielding techniques. Even then, and even for experienced engineers, some applications can still be very challenging (e.g., plasma cutters).

Keeping the encoder signals safely inside the motor eliminates any possibility of them becoming corrupted. There is also the benefit of not having to make or buy the motor/encoder cables. And since ClearPath does not need a motor phase cable or encoder cable, there is no possibility of this wiring (or its connector pins) degrading and failing over time (which is especially common in applications where the cables move). So, no matter what your skill and experience, and no matter what your application is, you won’t have noise problems with ClearPath’s encoder. (And all the signals that connect the outside world to ClearPath are optically isolated and digitally filtered for excellent noise immunity.)

Some people, when they see that the encoder signals are contained within ClearPath, will ask “Can I really have a ‘true’ closed-loop system without feeding the encoder signals to my CNC controller?” The answer is emphatically yes, so let me explain in detail. (Bear with me on the length of my explanation; there is a lot to discuss.)

*** Closing the Loop and Coordinated Motion ***
First a little background for the people with less servo experience: What do we mean by “closing the loop”? In a positioning application (e.g., a CNC machine) we mean measuring the difference between the desired values and the actual values of torque, velocity and position; and rapidly adjusting the torque so that these differences are minimized as quickly as possible.

As you may have gathered from this, there are three loops that get closed: the torque loop, the velocity loop, and the position loop. (The position loop is usually closed around the motor shaft position, although some systems also close a loop around the load position by feeding signals from a linear encoder into the servo system. I’ll discuss this “dual-loop” architecture later on in this post.) So “closing the loop” actually means closing all three loops (or four loops for dual-loop systems).

Some people mistakenly believe that to have multi-axis coordination you must have a central controller that is connected to the encoder feedback from all the individual axes. Although routing the encoder signals from each axis to the CNC controller can have some limited value (explained later), it is positively not necessary for fully closed-loop, coordinated, multi-axis control.

The coordination of a multi-axis system is almost always accomplished by coordinating the commands sent to each axis from the CNC controller. The servo control, i.e., closing the loop(s), is done on an individual axis basis, rarely by an algorithm that looks at the multi-axis feedback as a vector. (This is especially true of motion systems with orthogonal axes where there is relatively little force transmitted from one axis into the other.) Each axis in the vast majority of state-of-the-art, servo controlled motion systems is designed and tuned to accurately follow its individual command. If all axes accurately follow their individual but coordinated commands, the motion will be precisely coordinated.

It is possible to servo control a multi-axis vector of torque, velocity and position, but this is rarely done because of the complexity that would be required in the control algorithm (at a minimum, it requires cross-coupled gains for each combination of interacting axes). And that doesn’t mention the difficulty of tuning such an algorithm. Finally, and most important, if a single axis is unable to accurately follow its individual command, it’s very unlikely it could respond any better to the multi-axis vector feedback. (This is because, except in unusual or contrived cases, the bandwidth required to servo control the multi-axis vector is no less than the bandwidth required by the individual axes.)

All that said, if the controller was able to see that one or more axes were not accurately tracking their commands, and if this problem was the result of an excessive feed rate, the controller could reduce the feed rate to improve position tracking. Such a supervisory loop by the CNC controller does not, however, require routing the encoder signals to the controller. This loop can be more easily accomplished by sending a high-level “in-range” signal from each servo axis to the controller to tell it when the position tracking is no longer within an acceptable range. (Similarly, a “shutdown” signal could also be routed to the controller to inform it of more significant issues.)

Hopefully it is clear that in order to have a fully closed-loop, coordinated multi-axis system, it is not necessary to route the encoder signals to the CNC controller. But if your controller can close the position loop for each axis, why not give it the encoder data in order to let it do so (aside from the noise/wiring implications discussed earlier)?

Well, if you use your CNC controller to close the position loop, this means you will have more than one CPU involved in closing the servo loops (the position loop closed by the CNC controller, and the velocity/torque loops closed by the servo drive). But because the three servo loops are tightly interrelated (i.e., any change in one means a change in the others), you want the tightest possible synchronization between them. In other words, you want the absolute minimum delay between the time the servo reads the encoder position and the time the torque changes at the motor shaft (affecting the velocity to compensate for any position error).

If the CPU that reads the encoder position has to communicate to another CPU that is controlling the velocity and torque, there will be a time lag that will hurt performance. This can be proven mathematically and empirically.

In addition, by splitting the three loops between two different CPUs, you are giving up some opportunities to improve performance. In ClearPath, because one CPU is closing all the loops, it has complete and time-synchronized knowledge of the system at every moment. This means it can, as one example, dynamically modulate the position loop integration rate based on its knowledge of what is simultaneously happening in the velocity and torque loops. This is one reason ClearPath can handle very large inertia mismatches.

You might wonder why such a split-CPU architecture even exists. The answer is historical. When I joined Teknic in the early ‘90s, the state-of-the-art microprocessors were not powerful enough to individually handle the math required to close all three loops at a reasonable update rate. So this older architecture was required. But around that time, Texas Instruments introduced a DSP that was powerful enough to handle all the loop calculations. Teknic introduced a product in 1994 that utilized this DSP to close all the loops in one device, and the performance was exceptional.

As an aside, Teknic does sell drives that accept velocity and torque commands, allowing the position loop to be closed by another CPU. But these same drives, running in our “normal” mode (all three loops closed by the drive), always perform better by a wide margin. The only customers we have who use our drives in the split-CPU mode are OEMs who need to do so for legacy reasons.

So, are there any good reasons for sending the raw encoder data to the CNC controller? Maybe. I’ll touch briefly on the most common reasons:

Dual Loop – As I stated earlier, most servos close the position loop around the motor shaft position. But for some applications, where very high precision is required, you may want to know the position of the load itself in order to remove inaccuracies in the mechanics. Teknic makes some servo drive models that are capable of accepting two encoder inputs for this purpose, and there are some CNC controllers that can function in this way.

Realize however that dual-loop systems do not allow you to use cheaper or less accurate mechanics just because you are monitoring the load position. On the contrary, an analysis of the transfer function of such a system will show that a dual-loop system requires excellent mechanics, or else its dynamic performance will be quite poor or unstable. And if you split the motor and load position loops between two CPUs, you will have all of the “split-CPU” problems discussed earlier.

Analog control – Some people still use older servo drives that take an analog velocity command, and which cannot accept a position command. In this case, it is necessary to have the CNC close the position loop, although for reasons stated earlier, this is a lower performance system (not to mention the noise and drift problems of analog systems). This architecture is only recommended nowadays if you must use an older analog-style drive.

Reduced need to home – If you only send a high-level “OK” status bit to the CNC, and an axis shuts down due to a crash or some other exception, the controller will no longer know the position of the axis. This means you must re-home the axis. If the controller had the encoder data, it would still know where the axis was. Of course, it’s unlikely that you could just continue working on the same piece after a crash or other shutdown, but once you fixed whatever problem caused the shutdown, you could restart without homing. Assuming your system doesn’t often have catastrophic problems while running, the time you save occasionally re-homing will be minimal. And, it might be offset by the increased odds of system failure due to noise, or cable/connector issues related to the extra encoder wiring.

Well, this post certainly ended up a lot longer than I expected. I hope it is even remotely as helpful as it is long.

Best regards
Warren G.