509,747 active members
3,178 visitors online
Register for free
Login
IndustryArena Forum > CNC Electronics > Servo Motors / Drives > is it possible Clearpath servo's do not provide encoder feedback?
Page 2 of 3 123
Results 13 to 24 of 25
  1. #13
    Registered
    Join Date
    Apr 2018
    Posts
    13

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    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.

  2. #14
    Registered
    Join Date
    Aug 2009
    Posts
    226

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    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.
    Note that this is only true in an apples-to-apples comparison. Changing the system topology sometimes requires (or enables) a change in components; the effect of which can overwhelm the effect of the topology change (for example, going from an ATMega328 to an all FPGA setup). It also only applies to sequential digital setups; analog ones behave (and are analyzed) differently.

    Well, this post certainly ended up a lot longer than I expected. I hope it is even remotely as helpful as it is long.
    You should put it up on your website as a white paper. I think it would help eliminate a lot of confusion.


  3. #15
    Community Moderator Al_The_Man's Avatar
    Join Date
    Dec 2003
    Posts
    23196

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    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), ).
    Not quite true, There are many systems that have used the same method as I have often done with a Galil Motion controller, there is only ONE CPU involved, that in the Galil Card.
    The drives are simple torque mode, Transconductance amplifiers.
    The applications achieved with Galil Controllers are some that demand very stringent requirements, and for the typical CNC machining accuracy, more than adequate. IMO.
    Al.
    CNC, Mechatronics Integration and Custom Machine Design

    “Logic will get you from A to B. Imagination will take you everywhere.”
    Albert E.

  4. #16
    Registered
    Join Date
    Apr 2018
    Posts
    13

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Quote Originally Posted by Al_The_Man View Post
    Not quite true, There are many systems that have used the same method as I have often done with a Galil Motion controller, there is only ONE CPU involved, that in the Galil Card.
    The drives are simple torque mode, Transconductance amplifiers.
    The applications achieved with Galil Controllers are some that demand very stringent requirements, and for the typical CNC machining accuracy, more than adequate. IMO.
    Al.
    That’s a good point. I wasn’t thinking about an analog drive when I wrote that. Now that you’ve gotten me to think about this some more, I realize that instead of saying that one should avoid a “split-CPU” architecture, I should probably say that one should avoid a “split-loop” architecture in order to get maximum performance.

    Before I explain this, let me first say that I agree with your statement about Galil (and other reputable manufacturers) that sell servos that work with analog torque drives. I agree that this architecture is more than up to the task for quality CNC machining.

    I think it’s funny when people say that something “can’t work” in the face of it working perfectly well all around them; I don’t want it to look like I’m that guy. My comments are just about how certain architectural decisions can compromise and limit servo performance. So, with that said, back to “split loops”…

    Given the tightly interrelated nature of the three loops, they should not (for maximum performance) be split up and closed by different devices. One reason I mentioned earlier: if one CPU is closing all the loops, it has time-synchronized knowledge of the entire system at every moment. This allows for a whole host of algorithm enhancements.

    If the CPU is closing the position and velocity loops, but not the torque loop (whether the torque loop is closed by another CPU or by analog current loops), the position/velocity CPU will not know what’s going on in the torque loop.

    In fact, there really is no “torque loop” per se, in the analog torque amp architecture. The torque amplifier is more appropriately called a current amplifier (transconductance amplifiers, as you said). What you have in that kind of amp is really three separate current loops (for a 3-phase motor). Each loop is independently servoing to achieve the desired current for each motor phase.

    But all these loops are interconnected (through the motor), so a change made by one current loop servo affects the others. This is analogous to how two people showering in separate showers at the same time can “fight” with each other to get their desired water temperature. One turns up their hot water, and the other’s shower gets colder. It takes some time for them to iterate to their desired temperatures because they are connected to each other through the plumbing. They try to “servo” to their desired temperature, but while doing so they mess with the other person’s temperature, and vice versa.

    This kind of “fighting” in the motor slows down the torque response time (the time it takes for the commanded torque to be achieved). The slower response is not good for servo performance.

    But the servo’s job is quite a bit more difficult than my shower analogy would imply, because in the analogy each person has one stable water temperature they want. In a servo-controlled machine, the torque demand is constantly (and often rapidly) changing.

    Then on top of that, as the motor RPM increases (i.e.: the stator field spins faster), the alternating phase currents need to change more rapidly—even if the torque demand stays the same. But a finite time delay exists in all current loops, which causes a phase error, which gets proportionally bigger as the frequency of the phase currents increases. The phase error, in turn, causes a magnetic field misalignment. (Advancing the phase as speed increases is not an effective solution under dynamic conditions.)

    The effect of the magnetic field misalignment is that the torque requested by the main servo algorithm (the torque necessary to achieve the desired velocity and position) is not produced. Even under steady-state velocity and load conditions, the result of this progressive misalignment with respect to speed is a droop in the torque/speed curve. (And the energy that is lost to droop is converted to heat, which lowers the RMS torque available from the motor.)

    But more important than the steady-state torque reduction are the dynamic performance implications. The magnetic field misalignment effectively lowers the main servo algorithm’s gains, reducing the position/velocity bandwidth. This slows the dynamic response and increases tracking errors.

    If, instead of using an analog amp, you have a CPU handling the current loops, you can implement vector torque control (e.g., field-oriented control, space vector modulation, etc.). Vector torque control means the system is constantly servo controlling the collective vector of the three phases so that you are actually servo controlling torque rather than the three currents independently. This kind of a design, implemented well, has superior torque response time, and the response is independent of motor speed.

    And, now, if you are going to use a CPU to control torque, you really ought to use the same CPU that’s controlling position and velocity. No more split loops.

    Best regards,
    Warren

    PS: @_Britt: I agree with your “apples-to-apples” point. I should have said that. As for the white paper, there is some talk around here about creating a “motion control library” on our website, so maybe

  5. #17

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    First let me say that I have used the ClearPath SK system for one retrofit and found it to work very well and easy to set up. I would use it again in a similar installation. This was to replace step & direction servos in an semi-open loop system where the loop was closed at the drives.

    There are only two systems that I am familiar with that actually close all of the loops into a single CPU or at least on a single board, the Fanuc PulseCoder system, and the Galil 4000 series controllers when using the built in amps with Hall effect feedback. I'm sure there are others but I'm not familiar with them. In both of those cases, the motor commutation is done at the controller CPU level along with velocity, torque, and position control. So everything is done in one black box.

    From a system designer standpoint, the Fanuc system is useless to me in that it is difficult to program at best, and generally not user friendly. Not to mention everything is proprietary and expensive.

    The Galil system is flexible and very user friendly, almost like open source. But the built in amps that are available are limited in power to the point that for my applications are rarely practical.

    So that leaves me with some type of motion controller and a servo motor/drive combination where the drive is responsible for commutating the motor. This of course divorces the controller CPU from the motor commutation CPU. I have to count on the drive/motor combination doing what it's told to do.

    To throw another element into the mix, for most applications it is my preference to put the position feedback on the load rather than to rely on the mechanics of the system to position the load correctly through belts, screws, or gear systems. I am not talking about a dual loop system here, but rather the only position/velocity feedback to the controller comes from the load encoders. I couldn't care less what any installed motor encoders/tachs are doing, I'll let the drive handle that.

    The above is where the ClearPath system is a problem for me since I normally use analog control. I am aware of the available Analog Send Unit, but it only handles 0-10 V, with digitally switched direction, where I need +/- 10V for full functionality.

    But overall for the average user, the ClearPath systems are easy to install and a good value.
    Jim Dawson
    Sandy, Oregon, USA

  6. #18
    Member
    Join Date
    Jan 2005
    Posts
    10537

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Quote Originally Posted by Jim Dawson View Post
    But overall for the average user, the ClearPath systems are easy to install and a good value.
    "Good Value No"

    "Good for CNC No"

    "Hobby level CNC ok but too expensive for what you are getting"

    "Would I use them no, I have been to spoiled with real world Ac Servos / systems"

    There are many control systems that use +/- 10v just go looking, I know of several for Hobby users or OEMs that are excellent, I have used 5 different controls that can close the loop in the control that do a very good job but this is not for most Hobby user's and would serve them no purpose
    Mactec54

  7. #19
    Registered
    Join Date
    Apr 2018
    Posts
    13

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Quote Originally Posted by Jim Dawson View Post
    ...for most applications it is my preference to put the position feedback on the load rather than to rely on the mechanics of the system to position the load correctly through belts, screws, or gear systems. I am not talking about a dual loop system here, but rather the only position/velocity feedback to the controller comes from the load encoders.
    Hi Jim,

    I have a non-ClearPath related question.

    I’m curious what machines you have had good success with when closing the loop around the load/transmission (without using a tach or encoder on the motor for velocity feedback)? In my experience, that configuration can work well with stiff mechanics and very little backlash, but not typically so well in a system with gearboxes and belts (unless the belts are short and oversized in width, and the gearboxes are very high quality).

    Can you elaborate a little? Thanks.

    Best regards,
    Warren

  8. #20

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Quote Originally Posted by Teknic_Servo View Post
    Hi Jim,

    I have a non-ClearPath related question.

    I’m curious what machines you have had good success with when closing the loop around the load/transmission (without using a tach or encoder on the motor for velocity feedback)? In my experience, that configuration can work well with stiff mechanics and very little backlash, but not typically so well in a system with gearboxes and belts (unless the belts are short and oversized in width, and the gearboxes are very high quality).

    Can you elaborate a little? Thanks.

    Best regards,
    Warren

    Hi Warren,


    In my quote above, you are missing my last sentence: ''I couldn't care less what any installed motor encoders/tachs are doing, I'll let the drive handle that.'' That's important because I don't want to imply that there is no velocity control in two of the cases I'll explain below. I don't know what the DC drives would do without the tachs connected, never tried it.


    I can cite 3 examples that are or were in my shop. All are using the latest generation Galil products, Renishaw 1 micron linear scales, and my own CNC software. In all cases the loop is closed at the Galil controller.


    1) My BP clone mill. It started out life as a 2 axis machine, and I built the Z axis hardware myself. Equipped with the original Baldor DC servo motors and Servo Dynamics drives on the X and Y axis, belt connected to the ball screws, and the motor tachs are connected to the drives in the normal configuration. But a stepper motor on the Z axis, driving a gear train to run the quill. On all axes, I have 1 micron Renishaw magnetic scales.


    There is known 0.004'' backlash in the Y axis, the X axis is pretty tight with <0.001'' backlash. I can count on the machine holding +/- 0.0003'' or better in both axes when cutting a rectangular piece, but in all cases interpolating a round pocket comes out ovoid, it will be large 0.001'' when measured across the 10:00-04:00 position. The size of the pocket seems to make no difference.


    As said above the Z axis is driven by a 1200 oz/in NEMA 34 stepper, but I am using a rather expensive stepper drive that allows analog input. The only position/velocity feedback comes from the linear scale, there is no provision for closing the loop at the drive nor is there any encoder on the motor. I can count on the Z holding better than 0.0001''. In the case of the Z axis, the backlash is controlled by an air spring, so is zero in all operating modes. The spur gear train without the backlash control probably has > 0.020'' backlash. I have inadvertently had the air spring turned off and still held good depth tolerance when using a small end mill, but this is not the normal operating mode. I normally turn the air spring off when I want to use the Z in manual mode. Manual mode is accomplished by turning off the Z axis in the software, and flipping the lever to disengage the gear train. Useful for manually drilling hole patterns using the X/Y in CNC mode.


    2) 4x8 ft fixed gantry router. This machine has been retired, it was well past its useful life and I needed the floor space for the Haas mill. Many years ago I repowered it with 1200 oz/in NEMA 34 steppers. All connected by belt to the ball screws. The backlash on the X, Y, and Z axes was 0.010'', 0.016'', and 0.012'' respectively. The steppers were driven by the same analog input stepper drives as I am using on the mill Z axis. All axes were equipped with the same 1 micron Renishaw magnetic scales. I could count on that machine to hold better than +/- 0.002 on all axes, circular pockets were adequate for semi-precision fits in plastic parts. I could rapid the machine at 500 IPM and hit the target position to +/- 0.0005 per the DRO.


    3) A Shizuoka AN-S knee mill that came in for new controls. Was a basket case, with no controls at all. Now has SEM DC servo motors on all axes, all driven by Servo Dynamics drives. The motor tachs are connected to the drives. The Y and Z servos are belt connected to the ball screws, the X servo is direct coupled to the X ball screw. There is no known backlash in either the X or Y axes. The Z backlash has never been checked, but based on the few cuts that have been made with the machine, it seems to be OK. Again all axes are equipped with Renishaw 1 micron scales. We did a test cut on this machine, then took the part to local aerospace shop with a high end CMM. The finding was that there was no measurable deviation in either the outer rectangle or the circular pocket in the center. We did not check the depth. This machine is still sitting in my shop. It would be great if it were somewhere else.

    4) Not implemented yet. But will be adding a C axis to my CNC lathe spindle, in that case the servo motor will have encoder feedback to the drive because the drive requires it, but the loop will be closed at the controller via the existing spindle encoder. The drive will be commanded by a +/- 10V analog signal.


    I have been pretty successful at pulling this off, not sure others would have the same result because it does require some careful tuning to get it right. But once setup correctly, it's very stable. I haven't done anything with the tuning in a number of years on the mill. The other downside is the whole system is rather expensive compared to most hobby class systems, but still less than the real industrial class systems.


    Jim
    Jim Dawson
    Sandy, Oregon, USA

  9. #21
    Community Moderator Al_The_Man's Avatar
    Join Date
    Dec 2003
    Posts
    23196

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    The old original DC drives were velocity mode drives and used a tach for the 'inner' loop, the encoder was the 'outer' loop, the inner loop was always tuned first then the outer loop, now DC motors are rarely if ever, supplied with tachs, as the torque mode drive replaced them.
    Al.
    CNC, Mechatronics Integration and Custom Machine Design

    “Logic will get you from A to B. Imagination will take you everywhere.”
    Albert E.

  10. #22
    Registered
    Join Date
    Apr 2018
    Posts
    13

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Quote Originally Posted by Jim Dawson View Post
    In my quote above, you are missing my last sentence

    Hi Jim,

    Thanks for the detailed post. That’s exactly the kind of precise data I was looking for.

    I did read the last sentence of your paragraph, but I misunderstood it. I thought you had no inner velocity loop. That can be done, but it’s tricky and depends on very good mechanics and servo control.

    If you don’t mind, I have one more question. Can you describe the control of the Z-axis on the BP clone mill in a little more detail. Is it correct to assume that the analog input to the stepper drive is a velocity command? If so, then your velocity loop is around the load, correct? That is particularly interesting given the compliance of the air spring in the transmission. What are the specs on that? Does it provide a lot of force relative to the Z-axis mass? How was this axis to tune?

    Ok, I guess that’s five questions. Or, one question with five parts

    I appreciate your time on this. It’s always interesting to hear what other knowledgeable people are doing with their systems.

    Best regards,
    Warren

  11. #23

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    My pleasure to brag a bit.

    A couple of pictures here is worth at least several paragraphs of explanation.

    The black cable is connected to a 1 9/16 air cylinder on the other end. The machine end is connected to a special quill stop that I designed for this purpose, also has the mounting bracket for the reader head built in.

    The magnetic scale is mounted in place of the original scale.
    https://www.cnczone.com/forums/attac...d=431588&stc=1

    And the air cylinder on the back of the red mount bracket.
    https://www.cnczone.com/forums/attac...d=431594&stc=1

    Here is a close up of the original quill stop and the new one.
    https://www.cnczone.com/forums/attac...d=431590&stc=1

    The quill is driven by the gear train through the normal quill pinion. I just removed the original power feed hardware and replaced it with the gearbox I built.

    The idler gear is on a cam that allows it to be disengaged from the quill bull gear for manual use. Shown in the disengaged position. The motor (upper left) drives the the idler gear.
    https://www.cnczone.com/forums/attac...d=431592&stc=1

    Can you describe the control of the Z-axis on the BP clone mill in a little more detail. Is it correct to assume that the analog input to the stepper drive is a velocity command?
    Yes, a velocity command. I am using an Automation Direct SureStep drive. https://www.automationdirect.com/adc.../stp-drv-80100

    If so, then your velocity loop is around the load, correct?
    Yes, the feedback from the linear encoder is connected to the Galil DMC-1846 board, which also provides the +/- analog command signal.

    That is particularly interesting given the compliance of the air spring in the transmission. What are the specs on that?
    The cable/cylinder can exert > 100 lbs up pressure on the quill but I normally have at set for about 50 lbs. This is normally enough to overcome the down pressure exerted by any end mill I might use. The air spring cylinder is paralleled with a 5 gallon air tank to keep the pressure constant, not relying on the regulator to react as fast as the cylinder can move.

    Does it provide a lot of force relative to the Z-axis mass?
    The quill weighs around 25 lbs or so, so by setting the up force on the quill to about 2X the motor is forced to overcome about 25 lbs of force just to move the quill down. Now the question is what happens when the quill is moving up? Well it works just fine, just requires a little less motor torque to move up. The controller keeps the speed constant in either direction. I did have to reduce the motor torque, because I was afraid of breaking something. I only want a maximum of about 300 lbs of downforce possible, that's about what it takes to drive a sharp 1/2'' drill bit through mild steel under normal conditions. If everything goes horribly wrong, I do have a mechanical shear point built in to limit the down force to about 150% of maximum. I don't want to have to replace the quill pinion.

    How was this axis to tune?
    Very easy, only took about 10 minutes to dial it in. But due to the short travel, I only allow 60 IPM maximum, so running pretty slow. The total gear ratio is about 15:1 so the motor is only turning at about 900 rpm at maximum.
    Jim Dawson
    Sandy, Oregon, USA

  12. #24
    Registered
    Join Date
    Apr 2018
    Posts
    13

    Re: is it possible Clearpath servo's do not provide encoder feedback?

    Hi Jim,

    Very cool. The pictures are very helpful.

    A lot of controls PhDs will tell you that what you did will never work because of the lack of the stabilizing inner velocity loop

    Your design is very stiff (especially when driven “pretty slow”) and has essentially no backlash due to the air spring (and tank). Also, the mounting of the linear encoder read head is done well (very rigid and minimal cantilever). Nice work!

    Best regards,
    Warren

Page 2 of 3 123

Similar Threads

  1. Last One - 4'x6' Steel, Epoxy and ClearPath servo's
    By 1Jumper10 in forum CNC Wood Router Project Log
    Replies: 447
    Last Post: 06-01-2018, 11:11 PM
  2. HELP!!! Wiring a Clearpath servo to a C32S - DUAL PORT MULTIFUNCTION BOARD
    By 09milam in forum SmoothStepper USB Motion Control
    Replies: 6
    Last Post: 01-26-2017, 03:11 AM
  3. encoder feedback to drive vs feedback to drive and control
    By Deano7/11 in forum Servo Motors / Drives
    Replies: 12
    Last Post: 01-25-2015, 10:10 PM
  4. Baldor servo with resolver and encoder feedback???
    By Lucho24cr in forum Servo Motors / Drives
    Replies: 8
    Last Post: 03-07-2014, 02:09 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •