Analysing a Mach3 configuration problem.
In October 2012 I helped a fellow DIY
CNC'er to analyse a problem he was having with his 3-axis milling
machine. In short he was machining a number of holes in a plate (ie
milling them out with an endmill), all holes was identical but the
machine constantly and repeatedly stalled the Z-axis when retracting
from one particular hole. Same diameter hole, same feedrate, same tool,
same everything*. The first three holes always worked fine, but when
retracting from the fourth hole the Z-axis stalled each and every time -
* Of course it turned out that
everything isn't/wasn't the same or it would have worked. Yes, the
finished holes all looked the same but the CAM-generated code to
produce them didn't which is why it worked on all holes but one....
The actual problem in this case turned out
to be a combination of CV (Constant Velocity) being turned on, backlash
compensation being turned on but not setup properly AND the
CAM-generated code for that particular hole being different than the
other holes. Actually there's nothing really wrong with the code it just
happened to "trig" this issue on that particular hole.
In order to actually see what was
happening I used my LOGIC logic analyzer from Saleae, great little tool
by the way. Since the problem was with the Z-axis stalling I set the
analyzer up to start grabbing data when the direction signal for the
Z-axis changed from "down" to "up".
(Click on any screenshot to get them in
First lets take a look at the output
exactly as the machine was configured ie. with both CV and backlash
compensation turned on. I should probably point out the following
screenshots and descriptions applies when using Mach3 with the LPT-port.
If you're using an external motion control device such as the
Smoothstepper or KFlop etc they may (or may not) handle things
differently, I don't know.
Circled in green in the above screenshot
is where the Z-axis direction signal is toggled and pulses start to go
out to the Z-axis in order to pick it up from the bottom of the hole.
This happens while both the X- and Y-axis are decelerating because
that's exactly the purpose of the CV feature - it "blends" the moves
together in order to get a more continous, flowing type motion. So far
Now, circled in red you can see the Y-axis
direction toggled. Since backlash compensation is enabled on the Y-axis
this is the time to take that backlash out. The way this is done in
Mach3 is to stop all moving axes, apply the backlash compensation and
then "restart" the other axes again. This might seem strange at first
but if you really think what's happening it kind of has to be that way
or the machine wouldn't be following the programmed path. (Which it may
not do anyway due to the CV feature blendning the moves together but
that's a completely different thing). The first step-pulse on the Y-axis
is what initiates the direction change and the other three pulses is the
actual backlash compensation - I believe.
(Sidenote: I don't really understand
what's causing a single pulse to go out on the Y-axis and I haven't been
able to analyze the G-code properly to see what's actually happening at
So the X- and Z-axis are decelerated, the
backlash compensation for Y is applied and then the X- and Z-axis are
accelerated again. This operation is hardly noticable on the X-axis
because it's almost at a standstill anyway BUT the Z-axis is moving at a
conciderable speed when told to declerate hard and then accelerate
equally hard again. This is what actually caused the Z-axis stall.
But why there, only there and not on the
other holes, they are all the same - right? Not at all, here's that
"same" Z-axis move up and out of one of the "working" holes:
Here you can clearly see that the Y-axis
direction being toggled (but this time from the other direction)
before the Z-axis even starts to move. At this point the X-axis is
decelerated hard, the Y-axis backlash is taken out, the X-axis start to
accellerate again, then the Z-axis start to move out of the hole. In
this case the Z-axis never needs to do that hard stop/go kind of thing
it did on the other "non-working" hole so it doesn't stall. On the other
hand, the X-axis gets a bit of a beating here but apparently it's so
enough down its speed/torque curve that it can manage without stalling.
Now lets go back to the offending, "non
working" hole again and see what happens when you A) turn off the
backlash compensation and B) turn off CV.
A) CV turned on, backlash compensation
Again, circled in green is the change in
direction of the Z-axis and then a nice long acceleration. The Y-axis
changes direction (due to that one single step for whatever reason) but
since backlash compensation is turned off the other axes does not grind
to a halt so everything works nicely -not a problem.
B) CV turned off, backlash compensation
Here, because CV is turned off the Z-axis
move isn't started until after both the X- and Y-axis has come to a
complete stop (that's why the non CV mode is called exact stop) - each
move is completed before the next is started. Again, you can see the
Y-axis direction being changed, the X-axis "paused", the Y-axis backlash
compensation applied and the X-axis "restarted". Then the Z-axis start
to move - again no problem because the velocity on X at the time of
applying the backlash compensation on the Y-axis is so low that it
doesn't even notice. The Z-axis doesn't even move when Y-axis backlash
compensation is applied so there's no problem either.
So what's up with all of this, shouldn't
you be able to use CV and backlash compensation at the same time? Well
of course you should, and of course you can, but you need to understand
how it works (which the above hopefully helps with) and you need to set
it up in a way that the electrical and mechanical components of the
machine can actually follow.
The obvious reason for the Z-axis stall in
this case is the rapid deceleration/acceleration caused by applying the
backlash compensation for "another" axis at an unfortunate spot. It's
important to understand that the deceleration/acceleration applied when
backlash compensation kicks in does not follow what you set in the
Config->MotorTuning dialog. Instead it uses the Shuttle Accel
time setting in Config->General Config:
As you can see in the above screenshot the
Shuttle Accel setting is set to 4ms which means that decelration/acceleration
time for any axis, when backlash compensation kicks in is just that -
4ms - and that's really not much time at all. Besides, I think the
setting is a bit strange because it sets the time it takes to decelerate
the axis to a stop from whatever speed it's currently running at when
backlash compensation kicks in - not from the maximum speed it CAN run
The higher the setting the more noticable
the the stop, pause, hesitation or whatever we want to call it will be
when the compensation is applied but it's just one of those things where
you have to compromise. The best way to deal with backlash will always
be to remove it mechaically.
In the actual case described here raising
the Shuttle Accel time from 4 to 40ms fixed the issue. The next
screenshot shows what the output looks like with the Shuttle Accel time
You can see where the direction of the
Y-axis changes at marker 1 and where the backlash compensation pulses
are applied at marker 2. There's pretty much exactly 40ms between the
two marker so the setting works as described.
After writing this I've received the
question if I could explain why single axis moves works just fine at
full speed yet two axis move doesn't - especially when the "angle" of
the move is shallow, ie one axis moves a considerably longer distance
than the other. If backlash compensation is enabled then my guess is
that the most likely reason is the same as described above.
Lets take a look at a move with a 1:10000
relation between the two axes. Ie, we're moving from X0, Y0 to X50,
Y0.05, first with backlash compensation turned off:
The X-axis acceleration isn't very visible
here due to the fact that we're "zoomed out" to see the full move but
it's there. The X-axis accelerates and due the 1:10000 ratio there's
basically 10000 pulses on the X-axis before the first pulse on the
Y-axis. Everything is as expected and works perfectly.
Now, lets see what happens when we enable
backlash compensation, same move as before:
The issue is rather obvious - that gap in
the X-axis output.
The X-axis is well up to speed when the
Y-axis figures it needs to take a step in order to "keep in sync".
Because the direction is changed backlash compensation kicks in and
decelerates the X-axis in order to compensate Y. If the shuttle accel
setting is too low the X-axis can't cope with the rapid deceleration.
The inconsistencies in the X-axis output I
believe is tha backlash compensation for the X-axis.
The bottom line is that of you have to use
backlash compensation make sure you set Shuttle Accel setting high
enough to cater for situations like this.