I think one reason why servo manufacturers are leaning towards smarter systems with auxiliary feedback is because they can finally do it ecomonically. Once one does it, the others have to follow. If what you claim about the cost of doing this for motion controllers was true, that cost would be inherent in these new servos, and they clearly aren't that much more expensive.

There's an ever increasing requirement for accuracy in CNC machines, and this allows them to achieve greater market penetration. They're also well placed to include that encoder within their system and improve the overall performance. That's much easier to do from inside the Servo Amplifier than outside.
Presumably this will mean that fewer motion control suppliers will feel the need to supply closed loop options. It's a pity, but it's probably inevitable.

I don't accept the idea that adding a big FPGA to the board is going to multiply the cost by the figures you're quoting though. Those are just companies who know full well that they can currently charge almost what they like. It bears little resemblance to the cost of making the boards. Look at the KFLOP motion controller as an example of how cheaply this can be done. The number of gates you can get on an FPGA boggles the mind for the price they are.

I think I'll just design my own compensation board when I get a bit of time. I've already schemed out a strategy that ought to work with my existing drives and the ESS. You can buy development boards for less than £100 which ought to be more than capable of doing the job. It doesn't need that high processing speed and you don't need many pins.

Starting from scratch now, I'd buy AC Servos that do the job, but it's not economical for me to do that now. It will obviously take a bit of time to design something, but I enjoy that sort of project, and the cost is really small. The existing motors and drives are matched, so I really don't want to change the motors. I'm not sure the motors could be driven by other amplifiers either.

I very much doubt that you'll achieve lost motion of better than 20mictrons with your system. You have to look at all of the contributors to that. Those include the elasticity of the 'threaded' part of the ball screws, the balls in the nut itself, the thrust bearings and mounts regardless of how stiff you think your machine is. To be honest, the machine stiffness isn't a huge factor in the lost motion, it's mainly present in the actuating parts.

We used to have a Ball Bar to check our machines. Those had linear bearings and used very rigid precision ground leadscrews. It didn't take much to move the table, but we never saw less than 20 microns lost motion, whatever we tried. People imagine their machines are much better than they turn out to be when they actually measure them. If you ever get the chance, try it. You'll be disappointed by what you see.

What I've described by way of the behaviour of the Mach4 software implementation of backlash compensation, shows a bug, not what you can get with a software solution. It's clearly not implemented correctly, at least when it's single stepping.

I don't know from where this came, but you are NOT correct about this.  I feel I must address this because this is how bad information starts circulating. 

[rant]
There is NOTHING in Mach 4 that implements backlash compensation.  What you described as a "bug" is precisely WHY we don't do backlash compensation.  Because it is a kludge!  (Hint: it is implemented in the motion controller, not Mach 4)  It is not a perfect solution and it never can be.  What you are wanting can NEVER be accomplished with "backlash compensation" with only one encoder on the motor/drive/screw. 

There are only two ways to help overcome the problem. One is to apply a load thats always on one direction so there's no load reversal on the leadscrew. This is used on some Contact Lens turning lathes. It's not appropriate for large machines though. The other is to directly measure the table position with some kind of Linear Encoder.

So why are you calling it a bug when it is clearly a compromise?  It isn't a bug.  It is a feature that doesn't work they way you want/wish.  Right?  I mean, to be honest, you plainly point out the two ways to solve this problem.  And I completely agree.  This so called backlash compensation isn't one of the two ways to solve this. 
[/rant]

The rest of this post/thread is is for other people that might be reading who may not understand where the motion/PID loop is closed.

1.  Mach never closes the PID loop.  It can't, as Windows is not a real-time application.

2.  No controller that outputs step and direction is going to close the PID/motion loop.  Not even a Galil in stepper mode closes the PID loop. 

3.  The PID motion loop can be closed on the motion controller (which is always a real-time device).  A Galil or DSPMC controlling analog servos is an example of this.

4.  This PID loop can be closed on the servo drive.  (newest way)  Striplar's servo drives are an example of this.

So #4 above, step/dir, digital control, position mode, or what ever any servo manufacturer calls it today really makes things nice by closing the PID loop in the servo drive.  If the ESS or equivalent controller tells the servo to go 5 steps, the PID loop in the servo drive makes sure that the motor hits its' numbers.  So why would ESS ever want to close the PID loop?  How could a controller like ESS close a PID loop with a digital input servo drive that also has a PID loop?  There can be only one PID.  (Kind of sounds like the Highlander movie, right?)  So implementing dynamic position correction based on feedback from (again) a single encoder will never happen with a servo drive that ALSO has to have a PID loop to implement a step/dir control interface.

Some common methods of backlash/motion system flex compensation:

A.  Galil has a feature called step and correct.  And several other motion controllers that work with Mach have talked about implementing it.  This is where the motion plan says go from point A to point B but the stage never makes it to B because of the inherent flex in the motion system.  So once the motion controller gets to point B on the motor encoder, it then looks to the load encoder to see if it made it.  And if not, the motion controller issues more steps to to the servo drive to try and get it there.  So at the end of the move:

1. step once
2. did we make it?  If no, go to 1,

Sounds good, right?  But this step and correct takes TIME at the END of the move to implement.  It works really well for single axis/stage applications.  However, what if the movement is in combination with another axis/stage to interpolate a hole?  Now we are back to the problems of so called "backlash compensation" with a single encoder on the load.  Only worse because nothing happens until the end the move.  Sure enough, your interpolated hole will be oval.  But the table would have stopped at that correct place.  Big whoop.  Did we solve the problem?  I don't think so.

B.  Then there is the so called backlash compensation that we all know and hate, which is actually a derivative of the machine in one direction only paradigm.  Only with a twist.  It relies on a lash in/lash out computation based on direction.  So you have to establish a direction first.  Usually, this is done by homing the axis.  When you back off the switch, the lash is taken out in the direction opposite the switch.  So from that point on, the lash is taken out or put back in based on the direction of travel.  But guess what?  Taking the lash in or out doesn't happen instantly.  It takes time.  Which is why I consider it a huge compromise.  Not to mention the fact that it doesn't/can't take into account differing load situations with may increase or decrease the "lash" (really motion system flex) depending on the table position/condition.  What you get is striplar's complaint about single stepping in tenths of a thousands not "feeling"/marching/incrementing correctly.  A static preset "compensation" amount is NEVER going to be perfect because the motion system is NEVER perfect.  If it were, we would not be having this conversation.  This static compensation method is good (relatively) for machines with flex/backlash in the range of .004" - .006".  But we could never work in "tenths" on such a machine. 

C.  Then we can take this static compensation one step further by "mapping" the flex of the motion system based on the measured lash at any give position.  This certainly gets better results, but it is tedious (at best) to fully and precisely "map" a table or screw.  Most people simply do not have access to the equipment to do it correctly.  Again, this is a static compensation method, albeit more granular, that can't account for changing load or table conditions.

So we should really only consider a dynamic solution to fully eliminate the 11 micron (or 4 tenths) flex of a machine like striplar's. 

I can certainly understand wanting software that costs $200.00 to fix a hardware problem that can potentially cost $5K or more to fix.  Who wouldn't?  We joke about that all of the time.  Our saying is "Fixing hardware in software since 2011".    So for the many that read this, it is important to understand the difference between a dream and reality.  But that isn't always easy todo because there always seems to be lot of grey area between the two.

Steve

Hi Steve,
I'm sorry that you find this upsetting, but I'm merely pointing out a problem that can be improved upon. You may call it a 'feature', I call it a bug, because it introduces errors that make it worse than not having the feature turned on in some circumstances.

Fact:- Your Control Configuration page for each motor has a Backlash (Units) dialog box in it. I think it's reasonable to conclude that you intend to use this figure to improve the accuracy of the machine. A reasonable person would likely call this Backlash Compensation.

The problem is with the implementation.. I agree that it's not the best answer to the problem, but it's the only one that most people can use. It's also cheap. I don't accept that this is can't be done better than it currently is. I know you hate this with a passion, but it can and should work better in my opinion, because at the moment, it doesn't take up the slack, even when it's got all the time in the world to do it, ie in Single Step mode.

Since I don't have access to your code, I can't see what's been done. Personally I don't think it's that hard to do better. All you need is to output additional pulses interleaved with the usual ones. This can be done in real time and doesn't have to be completed instantly. Maybe you do this already. There are compromises with that solution too, but the end result is that after a short period of time the backlash count can be decremented to zero, resulting in the controller outputting the necessary counts. If the direction reverses before the counts have been completely output for that direction, you just start taking up the slack in the opposite direction. Sure, that's not ideal, but the system would have to be working flat out for that to happen, and there will always be following errors in that situation anyway, and you won't see it.

Whatever happens, you should always end up with the full amount of compensation added after a sustained change in direction. The clearly doesn't happen at the moment, at least in Single Step mode.

Nobody is expecting magic solutions. I'm well aware of the limitations of realtime control systems, I've been involved with them for almost 40 years and have designed them. I work with embedded systems as well as electronics and power amplifiers, am also a graduate Mechanical Engineer. I know what's possible and what isn't.

Roger

Hi,

Starting from scratch now, I'd buy AC Servos that do the job, but it's not economical for me to do that now.

Yes, I understand, I have no intention of replacing my servos with later model ones either.

I very much doubt that you'll achieve lost motion of better than 20mictrons with your system.

I do better than that with my mini-mill and my new mill is 10 times the rigidity. The manufacturers (THK) spec
of the screw stiffness is 1100N/um. Naturally the overall machine will be much less but I'll be disappointed if I get much less than
FEA predicts, that is 45N/um in all axes.

I think I'll just design my own compensation board when I get a bit of time. I've already schemed out a strategy that ought to work with my existing drives and the ESS. You can buy development boards for less than £100 which ought to be more than capable of doing the job. It doesn't need that high processing speed and you don't need many pins.

I understand that sentiment and have done similar things in the past just because it was interesting and a good hobby project. I'd have a hard time trying to
justify the investment in time to my boss however.

I think one reason why servo manufacturers are leaning towards smarter systems with auxiliary feedback is because they can finally do it ecomonically. Once one does it, the others have to follow.

Yes, than can do it economically, and because the design paradigm is shifting ever towards distributed motion control servo drives now, effectively, have to have this feature for the increased
accuracy demanded of them.

That's much easier to do from inside the Servo Amplifier than outside.

This I very much agree with. I would add that a manufacturer of a servo motor is the BEST placed to design a feedback control system to best exploit his devices performance.
General purpose feedback controllers are always up against the fact that they are general purpose....and can never be as focussed as a servo manufacturer.
As an example, I have a second hand 1.8kW Allen Bradley servo I use as a spindle motor. Amongst the parameters built into the drive is a piecewise linear approximation
of the magnetic saturation curve of the servo. Have you ever come across a motion controller that attempts to model the magnetic non-linearity of a servo?

Craig

Roger,

I'm sorry that you find this upsetting

1. I'm not upset.

2. You made some assumptions and labeled something a Mach bug when Mach doesn't even implement backlash compensation.  The backlash entry field on the motor tuning is simply a storage location for motion controllers to have a one stop shop to go to for pertinent motor information.  It keeps them from having to look in two different places.  Now, I agree that a reasonable person might confer or assume that Mach is implementing the backlash.  That is why I spoke up on the issue.  To make it clear.  So now knowing that Mach has ZERO backlash compensation code in it, are you still going to call it a Mach bug?  Is anyone reading this going to make the same assumption and call it a Mach bug?  I think not.  And THAT was my goal.  Nothing else. 

This is also exactly analogous to rigid tapping or lathe threading.  Mach has G code for those functions.  But does the motion controller support it?  If a person didn't do his research, they may assume (there is that word again) that Mach in combination with ANY motion controller is capable of doing these operations.  If the motion controller does a crappy job at implementing the threading op (not that any do), it that considered a Mach bug?  I would think not. 

Since I don't have access to your code, I can't see what's been done.

3. Again, there is ZERO backlash compensation code in Mach.  This is what I wanted to make clear.  I'm not even sure if ESS implements any backlash compensation code.  You will have to ask them about it.  So I'm not going to call what they may or may not do a bug either. 

4.  Mach 4 now has the concept of movement filters (For a couple of years now?  I can't remember).  This is how the surface mapping plugin works.  We put this in to handle kinematics at some point and some OEMs use it for different purposes too.  But it could also be used to implement backlash compensation, either single value or table based mapping.  Get in touch with Todd and get setup with a developer key if you think you can build a better mousetrap.  I'll be your biggest fan! 

Steve

Roger,

Quote from: striplar on March 31, 2021, 05:32:28 PM

I'm sorry that you find this upsetting

1. I'm not upset.

2. You made some assumptions and labeled something a Mach bug when Mach doesn't even implement backlash compensation.  The backlash entry field on the motor tuning is simply a storage location for motion controllers to have a one stop shop to go to for pertinent motor information.  It keeps them from having to look in two different places.  Now, I agree that a reasonable person might confer or assume that Mach is implementing the backlash.  That is why I spoke up on the issue.  To make it clear.  So now knowing that Mach has ZERO backlash compensation code in it, are you still going to call it a Mach bug?  Is anyone reading this going to make the same assumption and call it a Mach bug?  I think not.  And THAT was my goal.  Nothing else. 

This is also exactly analogous to rigid tapping or lathe threading.  Mach has G code for those functions.  But does the motion controller support it?  If a person didn't do his research, they may assume (there is that word again) that Mach in combination with ANY motion controller is capable of doing these operations.  If the motion controller does a crappy job at implementing the threading op (not that any do), it that considered a Mach bug?  I would think not. 

Quote from: striplar on March 31, 2021, 05:32:28 PM

Since I don't have access to your code, I can't see what's been done.

3. Again, there is ZERO backlash compensation code in Mach.  This is what I wanted to make clear.  I'm not even sure if ESS implements any backlash compensation code.  You will have to ask them about it.  So I'm not going to call what they may or may not do a bug either. 

4.  Mach 4 now has the concept of movement filters (For a couple of years now?  I can't remember).  This is how the surface mapping plugin works.  We put this in to handle kinematics at some point and some OEMs use it for different purposes too.  But it could also be used to implement backlash compensation, either single value or table based mapping.  Get in touch with Todd and get setup with a developer key if you think you can build a better mousetrap.  I'll be your biggest fan! 

Steve

Hi Steve,
Well, when someone rants, that's usually a pretty good sign that they're agitated.

This is the problem when you have two separate design teams providing a system ie Mach4 and Warp. It's not at all obvious where the responsibility for any particular element of a system lies. Am I right in thinking that Mach3 implemented backlash compensation in software?

No, now that I know you don't have any code, it's clearly not a Mach4 bug, even if it's a system bug. However, it's pretty misleading the way it is, I'm sure I'm not the only one who thinks it's a feature of Mach4.

I can assure you that the ESS is implementing backlash compensation. Going back over my past posts to the Warp9 forum, I can see that my discussion about this some years ago was with them, so I'd clearly forgotten that. I'll address the issues with them, because whatever has changed since my previous versions has been catastrophic for Single Stepping.

Well, when someone rants, that's usually a pretty good sign that they're agitated.

My rant was purely to clear up a misconception.  Being one of the authors of the Mach 4 software, I am in a unique position to do that because nobody else can claim to have a better understanding of what is under the Mach 4 hood.  And I simply don't mind explaining it from time to time.   

I have several such rants on different subjects.  Clearly, the backlash issue is one.  Another is the total misuse of constant velocity.  Still another is the myth that a 2000 line look ahead is needed.  And my total and unforgiving hatred of the Cycle Stop button.  Software e-stops.  Machines without limit switches.  Not checking the return codes of the API function calls, etc...

None of these get me really upset.  Well...  with the possible exception of the Cycle Stop button.    But I will get on a soapbox and rant all day about them if I feel the need. 

Am I right in thinking that Mach3 implemented backlash compensation in software?

In Mach3, Art did implement it with the parallel port.  I'm not sure if ESS did or what other external motion controllers did.  I'm certain that the Galil plugin didn't implement it.  So it was pretty much just like Mach 4 where it depended on the motion controller and was not universal.

Way back in the beginning, we actually tried implementing backlash compensation in Mach 4 to make it universal no matter what motion controller was used.  But I was never happy with it.  It still depended on the motion plugin being preprogrammed in a specific way so it was never a true application layer solution.  I considered it a kludge back then and nobody has been able to convince me otherwise up to this point.  Hell, the tool pressure can push the system back into the lash!  So what then?  Tighten the gibs up to create massive drag?  Yuck!  Having built and commissioned numerous machines with the dual encoder feedback, I just don't accept anything less. 

But I'm an analog servo guy from way back and I'm not fond of steppers either.  I can't count the number of servo systems I have tuned.  So maybe I'm just guilty of being a motion system snob?  I dunno...  I'm JUST now warming up to the position controlled (step/dir, digital or whatever) servo drives.  For a long while, only Yaskawa could do them right.  Now everyone else seems to do a decent job of it.  But I still look at these drives without load feedback with a bit of contempt as they just don't seem measure up. 

But back to the KFLOP, I sure do wish there was a KFLOP plugin for Mach4.  I always liked that controller.  Probably because it is capable of controlling analog servo drives.   

Steve

Hi Steve,
I appreciate you taking the time to clear up some of these issues. When you're on the inside, it's easy to imagine that people on the outside have a similar picture of the overall system to you. I too have my pet peeves.

I thought I'd remembered Mach3 having software backlash compensation, that's why I thought Mach4 had it. That coupled with Backlash having a placeholder in the Mach4 configuration. If you have no intention of implementing anything like that, wouldn't it be a good idea to remove the box altogether and get the plugins to add it instead? That way it would be obvious where the responsibility for the implementation lays?

I'm curious about the Cycle Stop button, I presume you mean just the one on the screen set that says Stop? Can you explain what the issue is with that, because being able to stop the machine during machining is vital. Many times you just want to abandon what you're doing, and that's the obvious way to do it.

I completely agree that software backlash compensation isn't great, but it's a lot better than none at all. Making it general purpose is much more challenging than for a specific machine though. Most finish machining doesn't involve large cutting forces, so I don't think  the machine climb milling and pulling the table is a significant issue. It certainly isn't on my machine.

Steppers have come a long way in the past few years, and I agree that they're much more palatable now. They've finally addressed the sing song noise they make too, as well as providing encoder feedback. AC Servos are still miles better in my opinion. I designed a DC Servo amplifier for our old PCB drilling machines way back. They are 100V with 40A peak, and there are still some out these in the wild 20 years on. Those can drill 3 x 0.7mm holes per second on a 0.1"  grid though a stack of 4 x 1.6mm circuit boards using 80,000RPM air bearing spindles. Happy days. It's all obsolete now. They're using Linear motors, Linear feedback and 250,000RPM spindles. It boggles the mind. Accel and decel ramps are what those applications are all about, so you can get the fastest possible point to point time. When you're drilling thousands of 0.3mm holes, you have to get a move on!

I'll bully KFLOP and see if I get anywhere. So far there's been no response from their Forum, so I don't know how active the company is any more.

So just to clarify one last point. All these problems I'm seeing with Single Stepping getting out of sync with the current program line, and issues with it taken about a second to stop are likely all to be ESS issues?

Roger

I've just had a reply from the Warp9 forum about this Single Step and backlash compensation issue as follows...

"Hi,

Mach4 3804 Hobby Installer

ESS 231 is in this list.

Before you upgrade, it is always a great idea to make a copy of your ENTIRE Mach4Hobby folder, because you can then revert back to that backup copy if something goes wrong...

I just looked at my code change log, and I have not touched anything with back lash comp since 231. I just compared the two code bases, and other than cleaning up commented out code, and adding in some extra diagnostic/reporting information NEAR the backlash code, I have not touched anything WRT backlash comp.

My guess is that somewhere between 4612 and 3804, which is an eternity in Mach4 dev time, something changed in Mach4 with respect to single stepping. On pressing Cycle Start again, it then executes the previous block. It then remains out of sync with the program for the rest of the Single Stepping. That really makes it sound like a Mach4 issue.

My initial guess is that if you go back to 3804 and 231, everything will work fine, and then if you use the 270/272 plugin things will still work fine for you (other than my pop up about Mach being too old).

At that point it would be interesting to see if you could narrow down the range to where Mach4 started to mess up with the single stepping, or be able to provide a video which can repeatable show a short GCode messing up in one version and not the other.

Andrew"

So the question is, who do I go to for help?

Now I'm confused as to what you are calling single stepping.  Single Block?

Steve