Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: striplar on March 30, 2021, 05:00:25 AM
-
My system is as follows...
Mach4 which currently uses an Ethernet Smoothstepper to drive the AC Servos.
SureServo AC Servos resolving to 1 micron up to 3000mm/min using differential Step/Direction inputs.
I'm currently using Mach 4 with backlash compensation, but want to get away from that.
My machine has Newall Linear scales fitted on all three axes but I've never been able to use them. It seems crazy to have them and not to be able to take advantage of the additional accuracy they will offer. However, the only options I've seen so far are outrageously expensive, but KFLOP may just provide the answer.
So the key questions are these...
1) Can I use the 1 micron Linear scales with the KFLOP controller?
2) Will it output the necessary Step/Direction outputs?
3) Will it cope with the very high resolution at 3000mm/min, and is there enough bandwidth on the USB2 connector so service that?
4) What breakout boards do you have to enable the unit to be hooked up to my existing wiring?
5) My spindle uses an analog 0-10V output. Do you have a way of connecting that up?
6) Is there a plugin for this motion controller?
I've posted a similar set of questions to KFLOP, but I'd like to hear what people on this side of the implementation have to say about it.
Any help would be very much appreciated.
-
I do not believe there is a Mach 4 plugin for the KFLOP. I don't know why they haven't made one, as they had one for Mach 3. I really like the features of the KFLOP. I thought it was one of the better Mach 3 controllers.
The best thing to deal with backlash is to just not have backlash. Fixing hardware with software is always a compromise.
The second best method for dealing with backlash is dual feedback where you have an encoder on the load and one on the motor. The Galil motion controllers are capable of doing this. Also, some of the newer servo drives can do this as well and it is seamless. However, there are some limitations and conditions that apply. Such as the load encoder can't have more resolution than the motor encoder. On my machine, I have a Galil and motors with a resolution of 12700 counts per inch. So if I wanted to use the dual feedback capabilities of the Galil, I would need a table/load scale with a resolution LESS than 12700 counts per inch. Say 10240 counts per inch. But in any case, BOTH feedback encoders need to be above 10000 counts per inch in order to have .0001" resolution. So you have to work within those parameters or you have to change something. For instance, you may need to increase the resolution of the motor encoder, etc...
If I couldn't get rid of backlash with preload or new screws, I would do the new servo drive that has the dual feedback capability. As I said, it is seamless. Much easier than tuning an analog servo controller.
What you do need to watch out for is trying to control a machine at one resolution and use feed back at another resolution. In other words, the step counts is the resolution that WILL control the machine on any digital servo drive. In later Mach builds, we do have auxiliary encoder support that can be used as feedback for the DROs and tool path and the aux encoders can have a different resolution than the step count. However, this gives you nothing in regards to a resolution increase and will not solve any backlash issues. Say you motor encoders are 5 micron and the table scales are 1 micron. In that scenario, you still have a 5 micron machine.
The ESS is certainly capable of providing auxiliary encoder feedback.
So do your research and figure out exactly what you are trying to accomplish. Higher resolution or backlash elimination?
Steve
-
Thanks for that, I'll ask them to produce a plugin and see what they say.
My backlash is very small compared to most milling machines with dovetail slides. I have precision ground leadscrews that are very large for the size of the machine, and that means I can run with +/-11microns of backlash
However, that's not very good if you're trying to machine precision items.
I have very little confidence that the software it correctly implementing the backlash compensation. If I single step back and forth between two points say 10mm apart, the display shows less than 10mm travel, which is clearly wrong. because it needs to be more than 10mm to compensate for the lost motion. Whether it gets it right when it's running in continuous mode is hard to check. Single stepping doesn't work correctly any more, it does some weird move instead of the first X/Y position, and then remains one step behind for the rest of the program. All of this really needs fixing urgently. I thought it worked fine with my previous Mach4 version, but it's definitely wrong now. whether these bugs are related is hard to tell.
My goal is to use my Linear scales because they should make a huge improvement in the accuracy and virtually eliminate any backlash issues. My whole system has 1 micron resolution. The AC Servos are 1 micron, as are the Linear scales. It's a digital setup with Step & Direction inputs to the AC Servos, so there's no analog tuning. This ought to be easy to achieve if I can only find a reasonably priced motion controller. I thought I'd found that with the KFLOP unit, but that doesn't seem to be supported.
It just seems crazy to have Linear scales and not be able to take advantage of them.
I looked at the the Galil motion controllers but they're way too expensive. They also aren't packaged very conveniently if you have four axes plus a spindle output. That pushes you into their larger unit because they use an axis for the spindle. To be honest, I wan't that keen on the attitude of their sales representative either.
So in short, I want to take advantage of my 1 micron Linear encoders to achieve the resolution that the system has the potential for. It would also take me away from what I think is a pretty questionable software backlash implementation.
I've attached a couple of pictures to give you some idea of what I'm machining.
-
striplar,
You might look at the Vital Systems controllers.
They can use a secondary encoder input.
Bill
-
Thanks for that Bill, I'll take a look.
-
What you described is what the compromise of software backlash compensation gives you.
So your end goal is backlash elimination. To do that with dual feedback, you will need to go to lower than a micro resolution on you motor encoder and keep the micron scales on the load. And go with one of the two following options:
1. Galil with analog control (requires servo drives that are capable of analog control, obviously).
2. Servo drives (and possibly new motors) that will take dual encoder feedback.
No step/dir output controller will give you dual loop control simply because that needs to happen where the PID loop is closed. This would be your servo drives, presently, as it is not done on the ESS.
Here is a short synopsis from Galil on the subject:
https://www.galil.com/news/dmc-programming-feedback-devices/dual-loop-mode-hints-galil-motion-controllers
Like it or not, you want big boy accuracy, so you might have to step up to the price range of a Galil. I don't know of any other controller that will give you what you want. Maybe the Vital Systems DSPMC? You would have to ask them and see. But I think that controller is deprecated now. Otherwise, can you preload your ball screws?
Steve
-
Hi,
to my knowledge KFlop does not have a Mach4 plugin.
The Mach4 controllers that can 'close the loop' are the Hicon Integra (with suitable but costly activations) and the CSMIO/A which
has a buggy Mach4 plugin. Note that both of these are analogue output. You would need analogue servo amps/servos or analogue input servo
drives with encoder rotary feedback, typically DC servos.
There is a third alternative. Most of the better AC servo manufacturers produce models of servos and drives that in addition to the rotary encoder
required to enact 'Field Oriented Control' have an additional encoder input about which you can close a position loop, with say a linear scale.
I'm using B2 series Delta servos for my new build mill. They have a 160,000cpr encoder. The later model and slightly more expensive A2 series
have a 1,280,000 cpr rotary encoder AND a second encoder input channel for closing the position loop.
With A2 series servos you could carry on using the ESS but actually close the position about your linear scales without any additional hardware other than
the servos and drives.
https://www.fasttobuy.com/delta-750w-075kw-a2-series-servo-system-drive-motor-asda20721f-ecmac10807ps-new_p27765.html (https://www.fasttobuy.com/delta-750w-075kw-a2-series-servo-system-drive-motor-asda20721f-ecmac10807ps-new_p27765.html)
Revise my earlier estimate. I was sure that when I bought my 750W B2 series servos/drvive/cable they were $460USD per kit and the A2 series were another $50USD each.
The link prices 750W A2 kits at $725USD, rather more than they were a year or so ago. I note also that the 750W B2 series are listed at $438USD....so they have come down
a little.
https://www.fasttobuy.com/flange-80mm-239nm-ac-motor-driver-kits-with-3m-cable-220v-075kw-cnc-servo-motor-for-cnc-router_p28084.html (https://www.fasttobuy.com/flange-80mm-239nm-ac-motor-driver-kits-with-3m-cable-220v-075kw-cnc-servo-motor-for-cnc-router_p28084.html)
Craig
-
What you described is what the compromise of software backlash compensation gives you.
So your end goal is backlash elimination. To do that with dual feedback, you will need to go to lower than a micro resolution on you motor encoder and keep the micron scales on the load. And go with one of the two following options:
1. Galil with analog control (requires servo drives that are capable of analog control, obviously).
2. Servo drives (and possibly new motors) that will take dual encoder feedback.
No step/dir output controller will give you dual loop control simply because that needs to happen where the PID loop is closed. This would be your servo drives, presently, as it is not done on the ESS.
Here is a short synopsis from Galil on the subject:
https://www.galil.com/news/dmc-programming-feedback-devices/dual-loop-mode-hints-galil-motion-controllers
Like it or not, you want big boy accuracy, so you might have to step up to the price range of a Galil. I don't know of any other controller that will give you what you want. Maybe the Vital Systems DSPMC? You would have to ask them and see. But I think that controller is deprecated now. Otherwise, can you preload your ball screws?
Steve
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 think I can use an analog input for the SureServo amplifiers, so I'm pretty sure this will work with Galil
The ball leadscrews are self contained items with substantial preload built into them. The term 'backlash' isn't really what we're dealing with in CNC systems, it's just lost motion due to the inherent flexibility of all of the actuating components taking up the strain against whatever loads there are. It's impossible to improve on what I have through any mechanical means. I've been involved in the CNC industry for 35 years and been involved in machine and controller design. 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.
I'll certainly look into the DSPMC, that might do what I want.
-
Hi,
to my knowledge KFlop does not have a Mach4 plugin.
The Mach4 controllers that can 'close the loop' are the Hicon Integra (with suitable but costly activations) and the CSMIO/A which
has a buggy Mach4 plugin. Note that both of these are analogue output. You would need analogue servo amps/servos or analogue input servo
drives with encoder rotary feedback, typically DC servos.
There is a third alternative. Most of the better AC servo manufacturers produce models of servos and drives that in addition to the rotary encoder
required to enact 'Field Oriented Control' have an additional encoder input about which you can close a position loop, with say a linear scale.
I'm using B2 series Delta servos for my new build mill. They have a 160,000cpr encoder. The later model and slightly more expensive A2 series
have a 1,280,000 cpr rotary encoder AND a second encoder input channel for closing the position loop.
With A2 series servos you could carry on using the ESS but actually close the position about your linear scales without any additional hardware other than
the servos and drives.
https://www.fasttobuy.com/delta-750w-075kw-a2-series-servo-system-drive-motor-asda20721f-ecmac10807ps-new_p27765.html (https://www.fasttobuy.com/delta-750w-075kw-a2-series-servo-system-drive-motor-asda20721f-ecmac10807ps-new_p27765.html)
Revise my earlier estimate. I was sure that when I bought my 750W B2 series servos/drvive/cable they were $460USD per kit and the A2 series were another $50USD each.
The link prices 750W A2 kits at $725USD, rather more than they were a year or so ago. I note also that the 750W B2 series are listed at $438USD....so they have come down
a little.
https://www.fasttobuy.com/flange-80mm-239nm-ac-motor-driver-kits-with-3m-cable-220v-075kw-cnc-servo-motor-for-cnc-router_p28084.html (https://www.fasttobuy.com/flange-80mm-239nm-ac-motor-driver-kits-with-3m-cable-220v-075kw-cnc-servo-motor-for-cnc-router_p28084.html)
Craig
Thanks for that. Unfortunately my AC Servos don't have an additional encoder input to close the loop from an auxiliary input. They were very expensive and do a superb job though, so it's not really cost effective to change them to accommodate a deficiency in the motion controller. It's a pity that the ESS doesn't implement closed look control.
I'll take a look at those motion controllers and see what these more modern drives look like.
I suspect I'll end up designing my own system in the end. It can't be that hard to take the counts coming from the ESS and a Linear encoder and introduce additional correcting counts to the AC Servo to reduce the error using a small FPGA. We're not talking about huge errors here, just 22 counts in a complete reversal. It's an interesting little project when I'm not quite so busy.
Roger
-
Hi,
really cost effective to change them to accommodate a deficiency in the motion controller.
I don't regard the motion controller, in your case the ESS as deficient. The trend is with motion controllers is that they are becoming simpler
and simpler, so much so that with Ethercat, and similar distributed motion control protocols, the central motion controller disappears altogether.
Servos, or rather servo drives, are becoming ever smarter and are responsible for their own motion control.
Why do you suppose that all the leading servo manufacturers have, in their top models only, these secondary encoder channels? It's not because they
expect OEM machine builders to use deficient motion controllers.
It's a pity that the ESS doesn't implement closed look control.
Personally I'm damn glad that it does not, as the complexity and cost go through the roof. The Hicon is $1200, the CSMIO/A is 600Euro and the Galill
about $2000 for three axis. Verses an ESS for $180. You do the maths.
Thus you could buy three Delta A2 servos and drives for about the same as a Galill. When I bought my 750w B2 series a year ago, the 750W A2 series
servos were $530USD, and I'm confident I could find them still at this price if I searched around which would make three servos and drives cost competitive
with a Hicon (including the activations required for closed loop servos).
They were very expensive and do a superb job though
At the time I bought my B2 series I did not understand the advantage that the A2 series had, namely the secondary encoder channel, and so did not
consider the extra as justified. It was only later that I realized the advantage, yet I have no intention of replacing by B2's, they do a superb job
as is, just as you have found with your servos. I do not have linear scales, nor do I intend on getting them. I use 32mm diameter double-nut
C5 grade BNFN THK ballscrews and I anticipate vanishingly small flexure with either the ballscrews or the hundreds of kilos of cast iron into
which they are mounted.
If you want to close the position loop around your linear scales to accommodate lost motion then the most cost effective solution is load sensing
servo/drives such as the Delta A2 series. I have no doubt you could still sell your existing servos for a pretty penny and defray at least half the cost.
Craig
-
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,
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
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
-
Now I'm confused as to what you are calling single stepping. Single Block?
Steve
Sorry, yes, I mean pressing Cycle Start when the Single Block radio button is lit. We call it Single Stepping in our industry.
-
Well, I don't know why that would affect anything having to do with backlash. All Mach does is provide the trajectory plan to get from the start position to the end position of the move. The plan should never change just like the distance between your door and your mailbox never changes. How you get from your door to your mailbox is the motion controller's job.
As to Cycle Stop. I don't like it because it is not recoverable. My YASNAC control that was on my Matsuura mill had Cycle Start, Reset, Feed Hold, and an e-stop button. If I wanted to stop the machine and walk away for a bit, I hit feed hold. On my YASNAC control, Feed Hold was a yellow button. On most Fanucs, it is a red button but it is labeled "Feed Hold". I kind of like the red button because most people associate red with stop. Neither has a Cycle Stop button. When I converted my mill from YASNAC to Mach 4, it still has no Cycle Stop Button. Not on the panel and not on the screen. I believe this is correct for for most milling applications. I'm not a lathe or grinder guy, so I just don't know. But a Cycle Stop button has been a Mach feature for nearly 25 years now and people just expect it to be there, for better or worse. Worse, IMHO.
But anyway, pressing cycle stop USED to be semi-recoverable on Mach 3. But with Mach 4 and its' MACRO B, better cutter comp, and more advanced Fanuc compatible interpreter, Cycle Stop is just not recoverable. Especially if you are using cutter comp. You need to use "Run From Here" to restore the state of the machine to restart. If you don't use cutter comp or Macro B, you may be able to get away with just pressing Cycle Start. But your mileage may vary.
Steve
-
Ok, but on Single Block, I'm getting it doing a phantom move instead of the first X/Y move. Mach4 moves on to the next block, but the DROs shows what actually happened, ie a short random move. It's only when the next Single Block is executed that it actually performs the move, but now it's out of step by one block.
Do you think this is because the ESS isn't processing the whole move? It looks to me like there's some kind of setup move going on to deal with the Backlash Compensation. Unfortunately I won't be able to experiment with any of this until this large job it finished.
I've found by accident that Cycle Stop seems to be recoverable, but I didn't expect it to be. Personally, as long as it doesn't lose count, that's all that matters. I don't see why anyone should expect to be able to continue. You've asked it to stop after all. Personally, I think you'd be justified in setting a flag that prevents you from continuing after a Cycle Stop. You could force the user to restart using the tools provided. Maybe there are some situations where it's easy to recover, and in those situations you wouldn't force a restart.
Cycle Stop takes a long time to respond now, and that's changed too. Is that something that Mach4 is doing, or is this another thing the ESS is doing?
Restarting part way through a program is a bit of an adventure though, I try to avoid doing it. For some reason it always starts at the block before the one you select, so you have to be wary. I'm not sure why it does that.
-
Rob has an ESS machine at the shop that has backlash that he said he could test with. You could try disabling the backlash comp on the ESS and see if there is still a strange movement with Single Block.
I have it on good authority that Cycle Stop will cancel cutter comp and trying to recover from that just by hitting Cycle Start will be disastrous.
Cycle Stop used to stop things rather abruptly. And people complained about it which made me want to ask why they were pressing cycles stop in the first place, hence my rant. So... I added a setting that basically does a feed hold before the stop. THAT takes time. It also made cycle stop more recoverable, unfortunately (for me). :) So check your settings on the general tab and untick that setting. Cycle Stop should be pretty instant that way. Oh, and abrupt, crude, rude, and obnoxious. The way it was meant to be. If that happens quickly, then we know it was the feed hold portion taking so long. If so, check that the ESS motion buffer isn't exceptionally large, that will affect how long Feed Hold takes.
Typically, with Mach 4 and a decent PC, you can run motion buffers as small as 30 milliseconds, which to us humans, seems instant. Anything under 100 milliseconds for most people, actually. But even the people with the fastest sense of time considers 50 milliseconds instant. Just to give you an idea on where a good buffer depth is.
I have never seen an issue when using Run From Here. I'm get it tested again though.
Steve
-
Running trying that on Rob's machine would be a big help. I've just got a reply from Warp9 and his machine clearly works correctly with backlash compensation during Single Block.
That makes good sense about cutter compensation being cancelled. You can't expect to pick up from that because you don't know the calculated intersections to know where you've come from. Can't you disable the Cycle Start when that situation occurs so they can't do it? You know when Cutter Compensation is turned on. The same goes for any other situation you know it can't recover from. That way you cover your back.
I don't use cutter compensation, the CAM does all of that, and that's probably why I can carry on.
Ok, I'll uncheck that setting for the feed hold, that's not the way I want it to work.
I need a decent size of ESS buffer to stop it hesitating when running at speed. With 1 micron resolution, that's a lot of data. I've noticed it pausing during some moves too, so it seems that something else might be wrong.
I'm beginning to wonder if my install is somehow corrupted. Is there any way to completely purge Mach from the Registry and wipe it totally for a fresh install?
When this big job is out of the way, I'll have a really good look at all of this.
Roger
-
Roger,
There is nothing in the registry save for the installation directory. And I doubt you have a corrupted install. It is way more likely that your Ethernet card is not doing the job.
A lot of the onboard Ethernet devices are built asymmetrically. Meaning they are better at downloading than uploading and thus have large receive buffers and small transmit buffers. Look at the device properties for the Ethernet device and see if you can increase the transmit buffers. Also, turn off anything that is like "interrupt moderation" or "green Ethernet". If you can't increase the transmit buffers equal to the receive buffers, get an new Ethernet card.
The resolution of your encoders really doesn't affect the data stream. The Mach planner divides the trajectory plans into many time slices. Each time slice has a planned number of steps that have to be executed in that time. Most Controllers use a time slice (or cycle time) of 1 millisecond. So a 2 micron resolution might move 1 step in 1 millisecond but a 1 micron resolution may move 2 steps in 1 millisecond. So it is the resolution of time, not the resolution of position that affects the data stream. For example, a cycle time of half a millisecond will stream twice the data than that of a cycle tome of 1 millisecond.
Most motion controllers settle on 1 millisecond cycle times as it is a good all around number and is granular enough that the no faceting is detected at high speeds and is capable enough of running very smooth low speeds. The ESS uses a 1 millisecond cycle time. An interesting thing that we can derive from that and your machine's resolution is that your 1 micron resolution allows you to run as slow as 1 micron per millisecond without spreading a step across cycles.
I have an D2700MUD Atom board that is capable of feeding my Galil at half a millisecond cycle times. That is twice the data that you are moving with the ESS. The Galil can actually go as low as one quarter of a millisecond on the cycle time. But there is a point of diminishing returns. So how does this little Atom board do it? Well... it has a good Ethernet device in it. The Intel Pro series Ethernet chipsets are a favorite of mine. The Realteks and Bigfoots, not so much. My point is not all Ethernet chipsets are created equal.
All this is to say that any decent PC with a decent Ethernet chipset should be able to feed an ESS without stuttering, even with a very low motion buffer depth. I routinely run a buffer depth of 30 milliseconds on my Atom/Galil combination. My loop interval is 10 milliseconds (feedback loop) so that gives the system 3 chances at filling the buffer to its' full depth. No stutters ever. That is why I suspect that your Ethernet card is just not doing what you need it too. Because there are a lot of CRAP Ethernet chipsets in consumer PCs these days. It is a throughput issue, not a corruption issue.
Steve
-
I'll certainly check out the settings. However, this is not new hardware, I've been running the same hardware since 2010. That was initially on Mach3 then Mach4 and I've had no issues whatsoever until I upgraded to Mach 4 4.2.0.4612 ESS V270 from Mach 4 V4.2.0.3804 ESS V231
That means this is clearly a software issue, unless by some amazing coincidence I've had a hardware fault at the same time. Of course that can be either a Mach or ESS issue, and I suppose Windows could coincidentally have done something to upset things. You never know what curved ball an update is going to throw you.
Is there a way I can get the old 3804 version back? I did look at the ftp link, but it wouldn't connect me to anything. I'd like to prove definitively that it still works ok with that version so I've got a reference point I can go back to.
-
Hi Roger,
For 3804 have a look here https://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/
Nick.
-
Hi Roger,
For 3804 have a look here https://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/
Nick.
Thanks Nick, that's great.
I've been in contact with DynaMotion, and they seem disinterested in making a Mach4 plugin. I guess that's because they would rather you use their own KMotionCNC software. Although that looks messy at first glance, it is configurable, so that might be the way forward.
-
Eureka! I've finally got to the bottom of this bizarre behaviour with Single Stepping and the phantom move.
I downloaded the old version that I was using before, and I spotted that I'd overridden the Custom Velocity and Custom Acceleration units. I'd failed to set those up when I configured V4612 and ESS V270
Filling in those values has fixed the problem. The custom values are much larger than the defaults, so maybe the ESS is tripped up by how long it takes to apply the backlash compensation when the settings are low and the Servos are high resolution and dynamic. Who knows. I'm surprised that it caused such bizarre behaviour.
Anyway, I've fed this back to Warp9, so maybe they can put some bounds on the values you input or make sure that at least it doesn't trip up Single Block.
So hopefully it will now behave itself and I can restore my confidence in the whole system.
What I'd really like to do is to use KFLOP with it, and I'd be delighted with the system. Open loop systems suck. I wonder if it's worth you contacting Dynamotion to see if they can be convinced to make a plugin for Mach4. They've done it for Mach3, so I can't see why they can't do it for Mach4. Their KMotionCNC is not dissimilar to Mach3 in the way they customise the screen. It's a bit clunky, nothing like as nice as Mach4.
Maybe others reading this might be inclined to contact Dynamotion too. The more they get asked, the more likely they are to cave in and give us what we want.
-
Roger,
I'm glad you found the issue!
Also, unless you are running stepper motors, the loop is closed on your servo drive. I used to really dislike the loop being closed on the servo drive because only Yaskawa seemed to do it right and not every project justified the cost of the Yaskawa drives/motors. But now days, the other drive manufacturers have it pretty much figured out too. And they actually do a decent job! And it is soo much easier for the servo tuning challenged among us to work with the digital/position controlled servo drives. As close to plug and play as you can get.
Steve