Hello,
I am a senior in mechanical engineering, for my senior project I designed and built a custom 2 axis CNC Rod Bender. I chose to use clearpath motors because of their ease of use, cost and minimalist wiring. I am currently having a problem with the motors losing position. From the tests I have ran, after bending 5 rods I sent the machine home and the position was off by .002", on the axis that does most of the bending. I have done a lot of research on clearpaths HLFB but and have got the signal to work, ie, I can see +5v when the motors are in position. However I do not know how to integrate this signal into Mach 4, or if it is even possible. My end goal would be for mach to wait after a move for the clearpath HLFB In Position Signal to be true, before initiating another move. Is this possible? Any help and or feedback is greatly appreciated.

Hi,
I am a bit bemused, Clearpath's are AC servos and like any AC servo there is a 'following error window', commonly certain number of encoder counts.

If the servo's actual position (ie encoder reading) differs from the current commanded position by more than the aforementioned 'error window'
the servo will immediately fault, with an appropriate error signal.

I know Clearpath's have only one or two fault signal outputs and only a handful of internal fault conditions that can be ascribed a fault output,
but following error is almost certainly one of them. My Delta servos have up to 8 outputs, two of them analogue the others digital. That allows
a much MUCH wider range of internal fault conditions to be signalled with each fault condition handled in its own way.

The servo will ideally ALWAYS be within the error window and thus having a 'move complete' or 'in final position' signal is superfluous.

What you need to do is calculate an appropriate error window, program the drive with that value and ascribe the fault output (HFLB?)
to the position error.

In most cases if a servo gets out of step with commanded position the machine will Estop. Maybe that's what you wish, but it doesn't have to be
that way. You could have the HFLB signal monitored such that the next movement instruction (Gcode) will wait until HFLB is active. With any sort of luck
the servo will remain within the error window and therefore the signal will be permanently active and the machine movement will be continuous.

What model Clearpath? Can you post the manual?

Given that Clearpaths have such few wires entering the servo/drive there is a very low limit on IO, it's the price you pay for simplicity.
More regular servos with separate drives offer MUCH more flexibility with respect to IO.

Craig

Did you run the Clearpath auto tune once your mechanics were setup, to get the servo tuned to YOUR setup? It works pretty slick as long as you have some room in your mechanics for them to move a bit to auto tune and determine how to act with YOUR mechanics. You shouldn't need any functions in Mach to determine when they are in position, that's what they do, move to a position, move to another position, move again, ad nauseam. I know nothing about a tube bender, but I'd guess it just moves at a speed to a position, done, but even if more complicated, surely not as complicated as 3D milling 100 blocks of gcode per second, and MY ClearPath's do that all day. You might also want to look at your Mach4 speed and acceleration.

And.....IF these are ClearPath SDSK fractional HP, they're DC, not that it matters.

Hi,

IF these are ClearPath SDSK fractional HP, they're DC, not that it matters.

The power supply input is DC but the electronics makes a rotating magnetic field in three radially symetric windings
to cause a permanent magnetized rotor to turn. In the modern terminology that is an AC servo.
BLDC is a broadly similar idea but the winding currents are not SINUSOIDAL, and is sinusoidal winding currents that
distinguish AC servos.

Craig

The servo will ideally ALWAYS be within the error window and thus having a 'move complete' or 'in final position' signal is superfluous.

I do a lot of non-CNC motion control systems using some high end servos for work. It is actually quite common to incorporate an "in position" bit to wait for the axis to accurately locate itself before triggering the next move. Often your position error tolerance (before fault) is opened wider than your desired accuracy for each move. Giving the axis time to finish a move allows the servo system to correct for any lag in the response.

It is important to include a position timeout in these cases. If the axis were to jam, it would be programmatically stuck waiting for it to complete the move. A maximum move timeout would stop motion in this case.

Did you run the Clearpath auto tune once your mechanics were setup, to get the servo tuned to YOUR setup?

This is totally right here. It even should be tuned under load if possible.

One last thing. On machines, mechanical problems are the source of servo troubles probably 60% of the time. Make sure you don't have lash in the drive train or the machine is flexing or deforming under load.

Josh,

The error could be mechanical in how you are moving the tube.
If you are using a roller to push it the roller could be slipping some.
If you are grabbing it that could also be slipping.
Like Thosj posted earlier you might need to slow down your acceleration.

Bill

Thank you for all of the comments guys. I did tune the motors under load with initial set up. My ideal goal of posting to this forum was to accomplish exactly what Craig said, "You could have the HFLB signal monitored such that the next movement instruction (Gcode) will wait until HFLB is active. " I would love any guidance as to how to accomplish this in Mach4. The mechanics on my system are rugged, and accurate. I am using a 20mm ballscrew and 34mm linear rails, all of the other components being precisely CNC machined. Mechanical errors are possible, however in my case I believe I have minimized the potential for these errors. I don't know if this is the case, but what I believe is happening is the X axis, when loaded, because it is bending the part is taking longer than Mach expects to get to position, and Mach does not wait for the motor, so it just moves on to the next line of code. I have configured the HLFB of the clearpath motors to go high when they are within +- 10 encoder counts, which is plenty accurate enough for the application. I just do not know how to integrate that signal into Mach, and to have Mach wait after a line of G code to see that signal, before continuing. Any help is greatly appreciated, and thanks again for all of the help thus far.

If Mach is moving to the next line of G-code before the previous move finishes there are two things to investigate.

If you have Constant Velocity enabled, this is normal. The trajectory planner is blending the moves in corners.

The other possibility is that you have the acceleration in Mach set higher than the motor can actually produce
and the Clearpath is still processing motion after the step pulses from Mach have been finished and Mach is
ready to process the next line of G-code. If you set your acceleration in Mach to more closely track what the
motor is capable of producing, Mach will alter the step pulse stream to not get as far ahead of what the motor
can actually do.

Hi,
you have said:

accomplish exactly what Craig said, "You could have the HFLB signal monitored such that the next movement instruction (Gcode) will wait until HFLB is active.

And then said:

I have configured the HLFB of the clearpath motors to go high when they are within +- 10 encoder counts, which is plenty accurate enough for the application

If the later is true then the former must also be. If HLEB errors out because it gotten 10 encoder counts out of step with the commanded then  the next line
of code won't execute....its in error state. If its NOT in error state, ie the actual position is within 10 counts of commanded the there is no need to wait
to execute the next line, its already in position….that's what the following error window means.

My Allen Bradley servo has two parameters related to this question, the following error window, and the zero error window.

The first, following error, means exactly as the Clearpath's do, if the actual position deviates more than the programmed amount of counts
from the commanded position then the servo faults. The default is 20 counts of an 8000 count encoder.

The zero error widow is a programmable number of counts where the drive will cease to attempt to further reduce the error. The default is 4 counts.
If the actual position is within 4 counts of the commanded position the drive ceases to apply corrections. This helps to prevent 'servo dither'.
It is also what Mike (mcardoso) was talking about. With a following error up to 20 counts but a zero error window of only 4 counts, if you wait for the servo
to achieve zero error (ie within 4 counts) before moving to the next instruction that would be more accurate than relying on the servo being within
20 counts.

To my knowledge Clearpaths don't have that feature, in the quest for simplicity a number of features universally common among other brands
of AC servos have been dropped.

If you deem 'within 10 encoder counts' to be accurate enough then you don't need the complication of a waiting before executing the next line of code.

Craig

Hi joshwalsh7,

I am an engineer at Teknic and ran across your post. I don’t have much familiarity with Mach, so I can’t comment on integrating the HLFB signal, but maybe I can give you a little insight on how to debug the problem you’re having.

As mcardoso said, the majority of mispositioning problems in servo-driven systems are mechanical. The rest are either electrical (noise or intermittent wiring) or software (sending the axis somewhere other than where you meant to send it). The first step to troubleshoot this problem is to figure out whether the problem is mechanical, electrical, or software.

Given that most mispositioning problems are mechanical, let’s start there. Not knowing your exact mechanical system makes it a little difficult for me to pick the optimum approach, but a good start is to see if the motor shaft itself is returning to the correct spot. Because you expressed your error as a linear amount (0.002 inches), as opposed to angular (e.g., degrees), I’m guessing that the drift you measured is relative to the mechanics not the motor shaft. To troubleshoot, we will want to measure what the motor shaft itself is doing.

One way you might be able to do this is to make a mark with a Sharpie marker on the tip of the motor shaft and make a second mark on something that doesn’t move (e.g., the front flange of the motor) that lines up with the first mark. If that’s not possible, figure out a way to point something directly at the mark on the shaft, like the tip of a dial indicator. (If you don’t know what I mean by a dial indicator, you can see one being used in this ClearPath video: https://youtu.be/-LubKmpB5-8?t=251 .)

Now run your axis enough times to be confident that you would see the “drift” in the mechanics and then see if the motor shaft is in the correct position. If it is, you can be pretty confident that you have mechanical slip somewhere in your mechanics. Troubleshooting the cause of the slippage is highly dependent on your particular design, but the first thing I usually look for is the use of set screws; they’re the single biggest cause of mechanical slip.

Barring any unusual servo configuration settings (e.g., torque foldback at the end of move, or a non-zero position deadband), any servo that uses a position integrator will always go to the position that it is told to go, or it will shut down. (Even with an end-of-move torque foldback or deadband, the error would not accumulate.) So, if the shaft isn’t in the position you expect and the motor drive hasn’t shut down, then you can be sure the motor is being (unintentionally) told to go to the incorrect position.

This can happen in a number of ways, for example: 1) your step signals might have high frequency electrical noise that is perceived to be extra steps (in either or both directions). This is not likely a problem with ClearPath because of its optically isolated and filtered inputs. 2) Intermittent wiring might cause the loss of steps (especially if the control cable is moving or being flexed during motion). 3) If the position drift is imperceptible on any given move, but slowly increases with each move, you might have a timing issue when you change directions. If the direction polarity change is too close to the start of steps, you might get a couple of steps in the wrong direction that can accumulate over time. 4) The software, especially if you’re doing math to determine the move length (as opposed to always sending a fixed integer number of steps), may be rounding in a way that leads to an incorrect position.

Describing how to troubleshoot every one of these possibilities is not practical for this post, but one hint is to see if you can tell whether the drift is repeatable (the same amount of error for each move, accumulating over time), or random. Items 1 and 2 above would tend to be random, while 3 and 4 would tend to be more consistent on each move.

Finally, regarding the use of HLFB (High Level FeedBack): Any following error you might have during a move will not accumulate into a static error that persists when the motion stops. Following error (aka, “tracking error”) is transient. Assuming your servo uses a non-zero position loop integrator (almost always true), and you don’t have a position deadband (ClearPath never uses a deadband; it has an anti-hunt/anti-dither algorithm that does not require a deadband), you will not end up with a static position error even if you send a new move before the previous move has settled. So, using HLFB to know when the move has settled will not solve your position drift problem. Although that’s not to say that connecting HLFB isn’t useful for other reasons.

HLFB (configured to show you whether you are tracking within your desired window) is useful to know if you’re pushing the servo past its limits (e.g., acceleration is too high, mechanics are binding, speed is too high for the bus voltage being used, etc.) or the servo has shut down. In a point-to-point application, you might use HLFB to make sure an axis is within its desired position tolerance before doing something on another axis. For example, before making a Z-axis move to place an IC on a circuit board, you would want to make sure the X and Y axes are settled in their correct positions. The ClearPath manual describes a number of ways to configure and use the HLFB signal.

Hope this helps.

Best regards,
Warren