[Emc-users] phase of cut thread varies with spindle speed

[gene heskett]

Hi Guys;

I did notice yesterday while cutting that 4mmx0.7 thread, which btw came
out real nice, that the spindle speed you start at should not be changed
during the run as it will widen the cut thread, leaving a distorted profile
at the root of the thread. I had started it at an S200 and had run it up
to 300 with the spindle override for a couple of loops as I was touching
off to the final size. Slowing the spindle back down to 200 put it back on
track and it cleaned it up nicely. As for cutting, with that fine a
thread, I could have cut it at 600+ rpms, z was not speed challenged.

My guess is that there is a get up to speed lag in the z accel after seeing
the index before z is actually phase locked to the spindle. I have always
started a thread well off the end of it in air, and I'm thinking this
phenom could be backlash related. To that end, would it be possible to
incorporate in the retrace motion of G76, and extra 2 thousandths of an
inch to the right of its park & wait for index, which is then brought back
to the z starting position with a 2 thou move to do nothing but take up the
backlash while it is waiting for the index. This 'turn around' move would
then take up the backlash, hopefully preventing this spindle speed related
slippage between the spindle and Z. If the index arrives while the backlash
move is in progress, skip it and wait for the next index of course.

Am I making any sense here?

Cheers, Gene

[Steve Blackmore]

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw came
out real nice, that the spindle speed you start at should not be changed
during the run as it will widen the cut thread, leaving a distorted profile
at the root of the thread.

That should not happen? I thought LinuxCNC compensated for spindle speed
change by using an encoder and modifying the feed to suit? One of the
selling points over Mach I'm told ;)

Post by gene heskett
I had started it at an S200 and had run it up
to 300 with the spindle override for a couple of loops as I was touching
off to the final size. Slowing the spindle back down to 200 put it back on
track and it cleaned it up nicely. As for cutting, with that fine a
thread, I could have cut it at 600+ rpms, z was not speed challenged.
My guess is that there is a get up to speed lag in the z accel after seeing
the index before z is actually phase locked to the spindle. I have always
started a thread well off the end of it in air, and I'm thinking this
phenom could be backlash related. To that end, would it be possible to
incorporate in the retrace motion of G76, and extra 2 thousandths of an
inch to the right of its park & wait for index, which is then brought back
to the z starting position with a 2 thou move to do nothing but take up the
backlash while it is waiting for the index. This 'turn around' move would
then take up the backlash, hopefully preventing this spindle speed related
slippage between the spindle and Z. If the index arrives while the backlash
move is in progress, skip it and wait for the next index of course.

Starting off the actual end off the stock is normal for threading and
the carriage should have all the backlash gone by the time the tool hits
the work. I always start my threads 5mm off the real start point and
never have a problem. I would think the minimum distance would have to
be considerably larger than the actual backlash amount to be certain.

That said I never use G76 and only have a couple of tenths of a thou
backlash (0.005mm) on both axis on my lathe.

Steve Blackmore
--

[gene heskett]

Post by Steve Blackmore

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread.

That should not happen? I thought LinuxCNC compensated for spindle speed
change by using an encoder and modifying the feed to suit? One of the
selling points over Mach I'm told ;)

Oh, that part works well indeed Steve.

The problem is that it has to do the Z axis backlash comp move AFTER the
index pulse goes true, when it should already have that done by the time
its waiting on the nxt index pulse.

What I want is for it to purposely overshoot the retrace motion by 2 or 3
thou (its out in the air anyway, or in a clearance cut as the case may be),
and then, perhaps at the same time as running the x back in, run the Z back
by that same amount of overshoot, thereby triggering the backlash comp move
BEFORE the index pulse arrives.

That would, in my little bitty mind, remove an unknown distance move and
prepare the z to be locked in step with the spindle as the index pulse
arrives.

As is, there appears to be perhaps 30 degrees of spindle turn at 300 rpms
before the Z can become locked after it has completed the backlash move,
and that would be 60 degrees at 600 revs etc.

Whatever, it is more than sufficient to be seen with a good glass when you
run a couple repeats to about 1/2 the needed depth at 200 revs, get tired
and set the spindle up to 300. The carriage moves sideways with that 100
rev difference more than enough to see it in the bottom profile of the
thread being cut. In this case since I wasn't at full depth, I slowed the
spindle back down as I was doing a touch off to go .1mm deeper, and the
distorted thread was then repaired by the next .1mm or .2mm deeper cuts.

Post by Steve Blackmore

Post by gene heskett
I had started it at an S200 and had run it up
to 300 with the spindle override for a couple of loops as I was
touching off to the final size. Slowing the spindle back down to 200
put it back on track and it cleaned it up nicely. As for cutting,
with that fine a thread, I could have cut it at 600+ rpms, z was not
speed challenged.
My guess is that there is a get up to speed lag in the z accel after
seeing the index before z is actually phase locked to the spindle. I
have always started a thread well off the end of it in air, and I'm
thinking this phenom could be backlash related. To that end, would it
be possible to incorporate in the retrace motion of G76, and extra 2
thousandths of an inch to the right of its park & wait for index,
which is then brought back to the z starting position with a 2 thou
move to do nothing but take up the backlash while it is waiting for
the index. This 'turn around' move would then take up the backlash,
hopefully preventing this spindle speed related slippage between the
spindle and Z. If the index arrives while the backlash move is in
progress, skip it and wait for the next index of course.

Starting off the actual end off the stock is normal for threading and
the carriage should have all the backlash gone by the time the tool hits
the work.

My point is that it cannot lock until the backlash move has been completed.
That is pretty much a fixed delay, and the faster the spindle is turning,
the more degrees it turns before the lock can kick in.

Post by Steve Blackmore
I always start my threads 5mm off the real start point and
never have a problem. I would think the minimum distance would have to
be considerably larger than the actual backlash amount to be certain.

So do I, by .1" or thereabouts. My backlash is not more than 1/5th of
that. IIRC z is about .00147" right now, phenomenally tight for a mini-
lathe being moved by its original screw, its support bearings and half nut.

Post by Steve Blackmore
That said I never use G76 and only have a couple of tenths of a thou
backlash (0.005mm) on both axis on my lathe.

That is tight, as quality machinery should be. This is a decade plus old
mini-lathe with lots of wear in the screws and bearings. And I likely have
it currently setup tight enough it has 1/4th the backlash it had new out of
the carton. OOTB, this thing was a huge POS.

Cheers Steve, Gene

[Steve Blackmore]

Post by gene heskett
So do I, by .1" or thereabouts. My backlash is not more than 1/5th of
that. IIRC z is about .00147" right now, phenomenally tight for a mini-
lathe being moved by its original screw, its support bearings and half nut.

I've read the posts that follow, the one by John K is particularly
interesting as that speed up/slow down behaviour is still there to some
extent, I can hear it, so the fix doesn't quite work for me. For what
reason I don't know.

However, my get around is the 5mm cutting in air. It seems to have
settled down by then on the thread pitches and spindle speed
combinations I commonly use. Most of my threading is in the .5 to 2mm
pitch range with spindle speeds of 500 to 1000 rpm. If I got some
variation at the start of the thread I'd increase the distance or slow
the spindle.

I think your .1 air cut is far too small - try 1 inch and see what
happens then reduce it to find a sweet spot.

I do agree though that any backlash comp needs to be taken into account
with threading and spindle index synchronization.

Steve Blackmore
--

[John Thornton]

I've cut the same threads at rpm's from 100 to 2000 (by accident) and
the pitch is perfect. I've seen a video where a guy was turning his
spindle by hand back and forth and EMC was keeping perfect pitch, iirc
the guy was positioning the stock for a recut of the threads.

John

Post by gene heskett
Hi Guys;
I did notice yesterday while cutting that 4mmx0.7 thread, which btw came
out real nice, that the spindle speed you start at should not be changed
during the run as it will widen the cut thread, leaving a distorted profile
at the root of the thread. I had started it at an S200 and had run it up
to 300 with the spindle override for a couple of loops as I was touching
off to the final size. Slowing the spindle back down to 200 put it back on
track and it cleaned it up nicely. As for cutting, with that fine a
thread, I could have cut it at 600+ rpms, z was not speed challenged.
My guess is that there is a get up to speed lag in the z accel after seeing
the index before z is actually phase locked to the spindle. I have always
started a thread well off the end of it in air, and I'm thinking this
phenom could be backlash related. To that end, would it be possible to
incorporate in the retrace motion of G76, and extra 2 thousandths of an
inch to the right of its park& wait for index, which is then brought back
to the z starting position with a 2 thou move to do nothing but take up the
backlash while it is waiting for the index. This 'turn around' move would
then take up the backlash, hopefully preventing this spindle speed related
slippage between the spindle and Z. If the index arrives while the backlash
move is in progress, skip it and wait for the next index of course.
Am I making any sense here?
Cheers, Gene

[gene heskett]

Post by John Thornton
I've cut the same threads at rpm's from 100 to 2000 (by accident) and
the pitch is perfect. I've seen a video where a guy was turning his
spindle by hand back and forth and EMC was keeping perfect pitch, iirc
the guy was positioning the stock for a recut of the threads.
John

I can well imagine that, in a setup with 2 start ball screws and next to
zero backlash. But I am running on the OEM screw & half nut. Backlash is
un-avoidable unless I take it all out and cut air while its being taken up,
its out in the air at that point anyway. Maybe that is what I should be
doing? With no comp move, probably no problem. Hummmm.

Backlash comp moves in the 15 thou range are required, and that takes time.
If the backlash comp move could be done while waiting for the index, it
would seem to be advantageous in this case. But it is not, the backlash
move is done after the index arrives. The synchronized move cannot be
established until the backlash has been taken up. And the spindle doesn't
stop & wait, not with this control setup which has no braking dump
facilities.

And that is what I'm asking the G76 cycle to do, to issue a .001" move left
while advancing X to the next cut depth, so that the backlash move is
complete by the time it pauses for the index pulse arrival. Heck, rather
than moving Z's movement range according to the angle given G76 as an
argument as X deepens the cut, retrace to a fixed point for both X and Z,
then move X to the surface, then move both X and Z to trace that advancing
into the thread angle (nominally 30 degrees) would take care of the
backlash move while waiting for the index.

Because my Z, a 16 tpi acme screw, is driven by a 2/1 geardown, I doubt I
could get to 2000 revs as that would result in some pretty wild z motor
speeds. My reliable Z move max is about 15 ipm. Its an 8 wire motor, in
series at about 2.5 amps. More speed would need to wire it parallel and
set that driver at max, 4.2 amps. And find a bigger transformer. With the
X axis being run in parallel and wide open, that tranny warms up nicely as
it is.

I did order an all steel QC toolpost kit yesterday, with an extra cutoff
tool holder so I can preset the bit heights properly without having to
spend a lot of time putzing with that when I turn the cutoff blade around
to use the threading tooth on the other end. This one has proper wedges &
should be several times more rigid than the all alu rig I have been using.

That thing, even with its bottom hollow ground, wasn't very stiff, leaning
over into the work and killing the spindle and fuse, not to mention a huge
gouge in the work, entirely too frequently. Hopefully that will be nearly
$200 well spent.

Post by John Thornton

Post by gene heskett
Hi Guys;
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread. I had started it at an
S200 and had run it up to 300 with the spindle override for a couple
of loops as I was touching off to the final size. Slowing the
spindle back down to 200 put it back on track and it cleaned it up
nicely. As for cutting, with that fine a thread, I could have cut it
at 600+ rpms, z was not speed challenged.
My guess is that there is a get up to speed lag in the z accel after
seeing the index before z is actually phase locked to the spindle. I
have always started a thread well off the end of it in air, and I'm
thinking this phenom could be backlash related. To that end, would
it be possible to incorporate in the retrace motion of G76, and extra
2 thousandths of an inch to the right of its park& wait for index,
which is then brought back to the z starting position with a 2 thou
move to do nothing but take up the backlash while it is waiting for
the index. This 'turn around' move would then take up the backlash,
hopefully preventing this spindle speed related slippage between the
spindle and Z. If the index arrives while the backlash move is in
progress, skip it and wait for the next index of course.
Am I making any sense here?
Cheers, Gene

Cheers, Gene

[andy pugh]

Post by gene heskett
Backlash comp moves in the 15 thou range are required, and that takes time.
If the backlash comp move could be done while waiting for the index, it
would seem to be advantageous in this case.  But it is not, the backlash
move is done after the index arrives.  The synchronized move cannot be
established until the backlash has been taken up.

The carriage should have time to catch up before you hit the material, though.
The only situation I can think of where what you describe could be
seen is if the spindle speed is so high that the carriage simply never
catches up to the requested position.

What does your f-error look like if you halscope it while cutting air?

[gene heskett]

Post by andy pugh

Post by gene heskett
Backlash comp moves in the 15 thou range are required, and that takes
time. If the backlash comp move could be done while waiting for the
index, it would seem to be advantageous in this case. But it is not,
the backlash move is done after the index arrives. The synchronized
move cannot be established until the backlash has been taken up.

The carriage should have time to catch up before you hit the material,
though. The only situation I can think of where what you describe could
be seen is if the spindle speed is so high that the carriage simply
never catches up to the requested position.
What does your f-error look like if you halscope it while cutting air?

I'll have to look Andy, but I suspect it will look fairly decent. I'm not
out there atm.

Interesting, running that metric g76 code, axis.3.f-error is a ramp to a
fixed value, 20 u-volts negative when following the spindle moving left,
and settles at +150 u-volts during the faster retrace move. A straight
line step ramp up or down can be seen flickering thru the display.

I have a feeling I am about to get better acquainted with stepgen.N.FF0,
FF1 and FF2 settings I assume? Or do these also have the usual suspect
inputs of a PID controller too?

Dinner time, BBL.

Thanks Andy.

Cheers, Gene

[Dave]

This suggestion is obviously a hack, but might be worth trying. Try
pre-loading your carriage in a direction opposite your cutting direction
in an attempt to remove the backlash.
If you have a small lathe with a light carriage and your ways are well
lubed; your carriage might be "bouncing or wandering" in your half
nut. Try something like a bunge cord or extension spring to pull the
carriage back towards the tailstock and see if that makes a difference.

A cable running over a pulley to a weight running up and down vertically
would do the same thing. That may allow you to run without any backlash
compensation.

Dave

Post by gene heskett

Post by John Thornton
I've cut the same threads at rpm's from 100 to 2000 (by accident) and
the pitch is perfect. I've seen a video where a guy was turning his
spindle by hand back and forth and EMC was keeping perfect pitch, iirc
the guy was positioning the stock for a recut of the threads.
John

I can well imagine that, in a setup with 2 start ball screws and next to
zero backlash. But I am running on the OEM screw& half nut. Backlash is
un-avoidable unless I take it all out and cut air while its being taken up,
its out in the air at that point anyway. Maybe that is what I should be
doing? With no comp move, probably no problem. Hummmm.
Backlash comp moves in the 15 thou range are required, and that takes time.
If the backlash comp move could be done while waiting for the index, it
would seem to be advantageous in this case. But it is not, the backlash
move is done after the index arrives. The synchronized move cannot be
established until the backlash has been taken up. And the spindle doesn't
stop& wait, not with this control setup which has no braking dump
facilities.
And that is what I'm asking the G76 cycle to do, to issue a .001" move left
while advancing X to the next cut depth, so that the backlash move is
complete by the time it pauses for the index pulse arrival. Heck, rather
than moving Z's movement range according to the angle given G76 as an
argument as X deepens the cut, retrace to a fixed point for both X and Z,
then move X to the surface, then move both X and Z to trace that advancing
into the thread angle (nominally 30 degrees) would take care of the
backlash move while waiting for the index.
Because my Z, a 16 tpi acme screw, is driven by a 2/1 geardown, I doubt I
could get to 2000 revs as that would result in some pretty wild z motor
speeds. My reliable Z move max is about 15 ipm. Its an 8 wire motor, in
series at about 2.5 amps. More speed would need to wire it parallel and
set that driver at max, 4.2 amps. And find a bigger transformer. With the
X axis being run in parallel and wide open, that tranny warms up nicely as
it is.
I did order an all steel QC toolpost kit yesterday, with an extra cutoff
tool holder so I can preset the bit heights properly without having to
spend a lot of time putzing with that when I turn the cutoff blade around
to use the threading tooth on the other end. This one has proper wedges&
should be several times more rigid than the all alu rig I have been using.
That thing, even with its bottom hollow ground, wasn't very stiff, leaning
over into the work and killing the spindle and fuse, not to mention a huge
gouge in the work, entirely too frequently. Hopefully that will be nearly
$200 well spent.

Post by John Thornton

Post by gene heskett
Hi Guys;
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread. I had started it at an
S200 and had run it up to 300 with the spindle override for a couple
of loops as I was touching off to the final size. Slowing the
spindle back down to 200 put it back on track and it cleaned it up
nicely. As for cutting, with that fine a thread, I could have cut it
at 600+ rpms, z was not speed challenged.
My guess is that there is a get up to speed lag in the z accel after
seeing the index before z is actually phase locked to the spindle. I
have always started a thread well off the end of it in air, and I'm
thinking this phenom could be backlash related. To that end, would
it be possible to incorporate in the retrace motion of G76, and extra
2 thousandths of an inch to the right of its park& wait for index,
which is then brought back to the z starting position with a 2 thou
move to do nothing but take up the backlash while it is waiting for
the index. This 'turn around' move would then take up the backlash,
hopefully preventing this spindle speed related slippage between the
spindle and Z. If the index arrives while the backlash move is in
progress, skip it and wait for the next index of course.
Am I making any sense here?
Cheers, Gene

Cheers, Gene

[gene heskett]

Post by Dave
This suggestion is obviously a hack, but might be worth trying. Try
pre-loading your carriage in a direction opposite your cutting direction
in an attempt to remove the backlash.
If you have a small lathe with a light carriage and your ways are well
lubed; your carriage might be "bouncing or wandering" in your half
nut. Try something like a bunge cord or extension spring to pull the
carriage back towards the tailstock and see if that makes a difference.
A cable running over a pulley to a weight running up and down vertically
would do the same thing. That may allow you to run without any backlash
compensation.
Dave

I thought of that Dave, but opted to pull the apron off & wound up with the
carriage fitting better AND got rid of about half the backlash by cleaning
swarf out of the half nut so it could close a bit tighter. Then I just
found the following error is a linear function of carriage speed, so I am
not done tuning yet.

But its dinner time here, BBL, probably on IRC


Cheers, Gene

[Jon Elson]

Post by John Thornton
I've cut the same threads at rpm's from 100 to 2000 (by accident) and
the pitch is perfect. I've seen a video where a guy was turning his
spindle by hand back and forth and EMC was keeping perfect pitch, iirc
the guy was positioning the stock for a recut of the threads.

One thing that is important is that the trajectory planner needs to be
running at the
full servo period, not at some submultiple. So, in the .ini file, the
SERVO_PERIOD
and TRAJ_PERIOD should be set to the same value. If the TRAJ_PERIOD
is set to a larger value, it will cause a significant time lag that
causes the
Z axis to lag behind. When reversing, this lag becomes doubled as a
position error.

Jon

[gene heskett]

Post by Jon Elson

Post by John Thornton
I've cut the same threads at rpm's from 100 to 2000 (by accident) and
the pitch is perfect. I've seen a video where a guy was turning his
spindle by hand back and forth and EMC was keeping perfect pitch, iirc
the guy was positioning the stock for a recut of the threads.

One thing that is important is that the trajectory planner needs to be
running at the
full servo period, not at some submultiple. So, in the .ini file, the
SERVO_PERIOD
and TRAJ_PERIOD should be set to the same value. If the TRAJ_PERIOD
is set to a larger value, it will cause a significant time lag that
causes the
Z axis to lag behind. When reversing, this lag becomes doubled as a
position error.

Oh cute, no relation to bow legged either. :(

Post by Jon Elson
Jon

Hummm, Okaaayyy, but what does it use if TRAJ_PERIOD is not specified? It
is not in my current .ini file. Somewhat stepgenconf generated. Heavily
diddled since.

Second, I just toured the show hal config screens and found no signals or
pins/params that correspond to the FF0-FF1 and FF2 settings that stepgen
had about 3 or 4 major revisions (2.1/2.2) ago. The .2.f-error in
particular, seems to be a direct function of the speed it is moving at,
with no apparent attempt to correct it, regardless of running distance,
back to a real 0.0 reading. The error isn't large, 150 u-volts max during
a G0 retrace move.

I can recall when the AXIS sections for the steppers had FF0-FF1 and FF2
settings in the .ini file but that was years ago...

So how do we do those corrections now?

Post by Jon Elson
------------------------------------------------------------------------
------ Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene

[andy pugh]

Post by gene heskett
Second, I just toured the show hal config screens and found no signals or
pins/params that correspond to the FF0-FF1 and FF2 settings that stepgen
had about 3 or 4 major revisions (2.1/2.2) ago.

Are you sure? I don't recall seeing them.

Anyway, I think JMK gave a complete and adequate explanation of the
situation, and the bottom line is; don't diddle spindle speed during
any one thread.
Apart from anything else you _will_ mess up the exit move.

[gene heskett]

Post by andy pugh

Post by gene heskett
Second, I just toured the show hal config screens and found no signals
or pins/params that correspond to the FF0-FF1 and FF2 settings that
stepgen had about 3 or 4 major revisions (2.1/2.2) ago.

Are you sure? I don't recall seeing them.
Anyway, I think JMK gave a complete and adequate explanation of the
situation, and the bottom line is; don't diddle spindle speed during
any one thread.
Apart from anything else you _will_ mess up the exit move.

That is so noted, this was not till Johns excellent explanation.

Cheers, Gene

[Eric Keller]

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw came
out real nice, that the spindle speed you start at should not be changed
during the run as it will widen the cut thread, leaving a distorted profile
at the root of the thread.

I think you are asking too much of the controller. When you are going
after precision, there is some sacrifice to be made in speed. This is
especially true when the machine is less than perfect. You could
potentially tune the controller a little better.
Eric

[gene heskett]

Post by Eric Keller

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread.

I think you are asking too much of the controller. When you are going
after precision, there is some sacrifice to be made in speed. This is
especially true when the machine is less than perfect. You could
potentially tune the controller a little better.
Eric

G76 is a canned cycle. It can be made to work the way I've described,
probably in less than 10 minutes time if I had the source, which I haven't
had since 2.2 days. I did build it once just to see if I could do it, most
of a decade back up the log.

As it is, the only way I can fix it is to un-tune the controller by
removing the backlash comp & letting that slack be taken up in the air, or
by writing it all as a loop that does do what needs to be done using G33.
But that only fixes my problem, why not fix it once, for everybody?

Cheers, Gene

[John Kasunich]

Post by gene heskett

Post by Eric Keller

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread.

I think you are asking too much of the controller. When you are going
after precision, there is some sacrifice to be made in speed. This is
especially true when the machine is less than perfect. You could
potentially tune the controller a little better.
Eric

G76 is a canned cycle. It can be made to work the way I've described,
probably in less than 10 minutes time if I had the source, which I
haven't had since 2.2 days. I did build it once just to see if I
could do it, most of a decade back up the log.
As it is, the only way I can fix it is to un-tune the controller by
removing the backlash comp & letting that slack be taken up in the air,
or by writing it all as a loop that does do what needs to be done
using G33. But that only fixes my problem, why not fix it once, for
everybody?

Because backlash isn't really the problem (although backlash can
make the problem worse). Re-writing the program to use G33 won't
fix it either.

The real problem is the time (and distance) it takes the Z axis
to accelerate once the index comes around. Even a perfectly tight
machine with no backlash still has an acceleration rate limit.

This will be easier to explain if I use a concrete example.
Apologies in advance to those who live in the metric world.

I also apologize for the length - this is an obscure issue, so
the explanation has to go into some details...

Assume your machine has a Z acceleration rate of 5 inches per
second per second. Also assume you are cutting a 10 threads
per inch pitch.

First lets see what happens with a spindle speed of 240 RPM,
which is 4 revs per second. Since the pitch is 10 TPI, Z will
have to move at 4 revs/sec divided by 10 revs/inch = 0.40
inches/second. The Z axis accel rate is 5 in/sec/sec, so it
will take 0.40 inch/sec divided by 5 inches/sec/sec = 0.080
seconds for Z to get up to speed. In that 0.080 seconds, the
spindle will have rotated 4 revs/sec times 0.080 seconds = 0.32
revolutions, which is 115.2 degrees.

Now do the same calculations for a spindle speed of 300 RPM,
or 5 revs/second. Z speed is 5 revs/sec divided by 10 revs/inch
= 0.50 inches/sec. Accel time is now 0.50 inch/sec divided by
5 in/sec/sec = 0.100 seconds, and the spindle will have rotated
5 revs/sec times 0.100 seconds = 0.50 revolutions, or 180 degrees.

If you rough the thread at 240 RPM and try to finish it at 300 RPM,
the finish passes will be 180 minus 115.2 = 64.8 degrees delayed
relative to the roughing passes. At 10 TPI, or 0.1000 inches per
turn, that is 0.100 inches * (64.8 deg / 360 deg) = 0.018 inches.
That will be a messed up thread.

But this problem ONLY happens if you change spindle speed
between passes. If you keep the speed the same, the delay angle
is also the same, and the thread will be fine.

When G33 spindle synchronized motion was first added to
LinuxCNC, it didn't have this problem. It had a worse problem,
one that would show up even if you didn't change the spindle
speed.

The original G33 had an "internal" Z position reference that
would begin moving at the proper speed to cut the desired pitch
the instant that the index pulse arrived. Because this internal
Z started moving instantly, it didn't matter how fast the spindle
was turning - the thread would always be right. Unfortunately,
real motors can't accelerate instantly, so the "external" Z
command that actually runs the motor still needed to have
acceleration limits applied to it.

Lets work through what happened, using the same machine and
thread as in the previous calculations, at 300 RPM.

As soon as the index arrives, the internal Z starts moving at
0.50 inches/sec. The external Z has accel limiting, and we've
already calculated that it takes 0.100 seconds to reach 0.50
inches/sec. The average speed during that accel is 0.25
inches/sec, so the distance traveled is 0.100 times 0.25 =
0.025 inches. Meanwhile, in the first 0.100 seconds, the
internal Z has been moving at a constant 0.50 inches/sec,
and has moved 0.100 times 0.50 = 0.050 inches.

That means the external Z is lagging behind the internal one
by 0.025 inches. So LinuxCNC tells it to keep accelerating.

Over the next 0.0707 seconds, the internal Z keeps accelerating
at 5 inches/sec/sec, reaching a speed of 0.8535 inches/sec.
During this 0.0707 second period, it averaged 0.677 inches/sec,
and it moved 0.0475 inches. Meanwhile the internal Z is still
cruising along at 0.50 inches/sec, and moved 0.035 inches.
So during this 0.0707 seconds, the external Z gained 0.0125
inches on the internal one - half of the distance it needed
to make up.

But now it is moving too fast. So LinuxCNC tells it to slow down.
For the next 0.0707 seconds, it decelerates at 5 inches/sec/sec,
finally ending up back at 0.50 inches/sec, where it needs to be.
The average speed for this period is 0.677 inches/sec, and
the distance traveled is 0.0475 inches, while the internal
Z only moved 0.035 inches. So external Z has finished
catching up, both position and speed are matched, and we can
begin the cut.

This whole process took 0.2414 seconds from index arrival to
the point where it was safe to begin cutting. That is more
than twice as long as it takes to accelerate to the desired
speed. It also takes more than twice the Z distance, which
might mean the first part of the thread is the wrong pitch
if there isn't enough of an air cut.

The real problem is that the peak Z axis speed was 0.8535
inches per second, even though the thread we are cutting
only needs 0.50 inches per second.

What if we are running very close to the machine limit?
Suppose the machine is only capable of 0.52 inches per sec.
In theory we should be able to cut the thread at 300 RPM,
since we only need 0.50 inches/sec. Lets walk through
one more set of numbers.

For the first 0.100 seconds things are exactly the same.
External Z accelerates to 0.50 inches/sec, and falls
behind internal Z by 0.025 inches.

In the next 0.004 seconds, external Z reaches its top speed
of 0.52 inches/sec, and stops accelerating. During that
time, the average speed is 0.51 inches/sec, and it moves
0.00204 inches. Meanwhile internal Z moves 0.00200 inches,
so external Z gains 0.00004 inches. Since it started out
0.025 inches behind, it now 0.02496 inches behind.

Now external Z is cruising along at 0.52 inches per second.
It is slowly catching up to internal Z which is only going
0.50 inches per second. After 1.246 seconds of this, it
has caught up to within 0.00004 inches of where it should
be, and starts slowing down. As it slows back down to 0.50
inches/sec, it makes up that final bit of distance.

In this example, it takes 1.354 seconds and 0.677 inches
of travel for the Z axis to come into sync and be ready to
cut a proper thread. Compare that to the 0.100 seconds
and 0.025 inches that it needs simply to accelerate to
the proper speed.

I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
the following fix, which is in there now:

At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.

The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.

[Stephen Dubovsky]

[Stuart Stevenson]

[gene heskett]

Post by John Kasunich

Post by gene heskett

Post by Eric Keller

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which
btw came out real nice, that the spindle speed you start at
should not be changed during the run as it will widen the cut
thread, leaving a distorted profile at the root of the thread.

I think you are asking too much of the controller. When you are
going after precision, there is some sacrifice to be made in speed.
This is especially true when the machine is less than perfect.
You could potentially tune the controller a little better.
Eric

G76 is a canned cycle. It can be made to work the way I've described,
probably in less than 10 minutes time if I had the source, which I
haven't had since 2.2 days. I did build it once just to see if I
could do it, most of a decade back up the log.
As it is, the only way I can fix it is to un-tune the controller by
removing the backlash comp & letting that slack be taken up in the
air, or by writing it all as a loop that does do what needs to be
done using G33. But that only fixes my problem, why not fix it once,
for everybody?

Because backlash isn't really the problem (although backlash can
make the problem worse). Re-writing the program to use G33 won't
fix it either.
The real problem is the time (and distance) it takes the Z axis
to accelerate once the index comes around. Even a perfectly tight
machine with no backlash still has an acceleration rate limit.
This will be easier to explain if I use a concrete example.
Apologies in advance to those who live in the metric world.
I also apologize for the length - this is an obscure issue, so
the explanation has to go into some details...
Assume your machine has a Z acceleration rate of 5 inches per
second per second. Also assume you are cutting a 10 threads
per inch pitch.
First lets see what happens with a spindle speed of 240 RPM,
which is 4 revs per second. Since the pitch is 10 TPI, Z will
have to move at 4 revs/sec divided by 10 revs/inch = 0.40
inches/second. The Z axis accel rate is 5 in/sec/sec, so it
will take 0.40 inch/sec divided by 5 inches/sec/sec = 0.080
seconds for Z to get up to speed. In that 0.080 seconds, the
spindle will have rotated 4 revs/sec times 0.080 seconds = 0.32
revolutions, which is 115.2 degrees.
Now do the same calculations for a spindle speed of 300 RPM,
or 5 revs/second. Z speed is 5 revs/sec divided by 10 revs/inch
= 0.50 inches/sec. Accel time is now 0.50 inch/sec divided by
5 in/sec/sec = 0.100 seconds, and the spindle will have rotated
5 revs/sec times 0.100 seconds = 0.50 revolutions, or 180 degrees.
If you rough the thread at 240 RPM and try to finish it at 300 RPM,
the finish passes will be 180 minus 115.2 = 64.8 degrees delayed
relative to the roughing passes. At 10 TPI, or 0.1000 inches per
turn, that is 0.100 inches * (64.8 deg / 360 deg) = 0.018 inches.
That will be a messed up thread.
But this problem ONLY happens if you change spindle speed
between passes. If you keep the speed the same, the delay angle
is also the same, and the thread will be fine.
When G33 spindle synchronized motion was first added to
LinuxCNC, it didn't have this problem. It had a worse problem,
one that would show up even if you didn't change the spindle
speed.
The original G33 had an "internal" Z position reference that
would begin moving at the proper speed to cut the desired pitch
the instant that the index pulse arrived. Because this internal
Z started moving instantly, it didn't matter how fast the spindle
was turning - the thread would always be right. Unfortunately,
real motors can't accelerate instantly, so the "external" Z
command that actually runs the motor still needed to have
acceleration limits applied to it.
Lets work through what happened, using the same machine and
thread as in the previous calculations, at 300 RPM.
As soon as the index arrives, the internal Z starts moving at
0.50 inches/sec. The external Z has accel limiting, and we've
already calculated that it takes 0.100 seconds to reach 0.50
inches/sec. The average speed during that accel is 0.25
inches/sec, so the distance traveled is 0.100 times 0.25 =
0.025 inches. Meanwhile, in the first 0.100 seconds, the
internal Z has been moving at a constant 0.50 inches/sec,
and has moved 0.100 times 0.50 = 0.050 inches.
That means the external Z is lagging behind the internal one
by 0.025 inches. So LinuxCNC tells it to keep accelerating.
Over the next 0.0707 seconds, the internal Z keeps accelerating
at 5 inches/sec/sec, reaching a speed of 0.8535 inches/sec.
During this 0.0707 second period, it averaged 0.677 inches/sec,
and it moved 0.0475 inches. Meanwhile the internal Z is still
cruising along at 0.50 inches/sec, and moved 0.035 inches.
So during this 0.0707 seconds, the external Z gained 0.0125
inches on the internal one - half of the distance it needed
to make up.
But now it is moving too fast. So LinuxCNC tells it to slow down.
For the next 0.0707 seconds, it decelerates at 5 inches/sec/sec,
finally ending up back at 0.50 inches/sec, where it needs to be.
The average speed for this period is 0.677 inches/sec, and
the distance traveled is 0.0475 inches, while the internal
Z only moved 0.035 inches. So external Z has finished
catching up, both position and speed are matched, and we can
begin the cut.
This whole process took 0.2414 seconds from index arrival to
the point where it was safe to begin cutting. That is more
than twice as long as it takes to accelerate to the desired
speed. It also takes more than twice the Z distance, which
might mean the first part of the thread is the wrong pitch
if there isn't enough of an air cut.
The real problem is that the peak Z axis speed was 0.8535
inches per second, even though the thread we are cutting
only needs 0.50 inches per second.
What if we are running very close to the machine limit?
Suppose the machine is only capable of 0.52 inches per sec.
In theory we should be able to cut the thread at 300 RPM,
since we only need 0.50 inches/sec. Lets walk through
one more set of numbers.
For the first 0.100 seconds things are exactly the same.
External Z accelerates to 0.50 inches/sec, and falls
behind internal Z by 0.025 inches.
In the next 0.004 seconds, external Z reaches its top speed
of 0.52 inches/sec, and stops accelerating. During that
time, the average speed is 0.51 inches/sec, and it moves
0.00204 inches. Meanwhile internal Z moves 0.00200 inches,
so external Z gains 0.00004 inches. Since it started out
0.025 inches behind, it now 0.02496 inches behind.
Now external Z is cruising along at 0.52 inches per second.
It is slowly catching up to internal Z which is only going
0.50 inches per second. After 1.246 seconds of this, it
has caught up to within 0.00004 inches of where it should
be, and starts slowing down. As it slows back down to 0.50
inches/sec, it makes up that final bit of distance.
In this example, it takes 1.354 seconds and 0.677 inches
of travel for the Z axis to come into sync and be ready to
cut a proper thread. Compare that to the 0.100 seconds
and 0.025 inches that it needs simply to accelerate to
the proper speed.
I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.

Thank you very much for that detailed explanation John K.

Obviously yes after reading this, and also considering that my Z MAXVEL is
.302, any faster runs the risk of a motor stall, but only if a backlash
move preceeds the steady run, I can run at about .500 IF I tap the
direction key, wait for the backlash move to be done, at which point I can
move the length of the bed in that same direction. Do it in one keypress,
and a following error will be output about .6" down the bed. Fixing that is
going to cost me another $250 to get it above .500. I'll need both a
higher voltage and more amps so I can switch this motor to parallel drive.
That will take a much larger transformer, higher voltage capacitors, and
swapping of the drivers for the next larger ones.

Not saying that it won't happen, but I just blew $200 on a much better QC
tool post and holders.

------------

Now, this evening I'm using halscope to look at f-error, which seems to be
directly related to the commanded speed, but at 10 ipm, is only 150
microvolts. But there is no Pgain, or FF0 to drive that steady state error
back toward zero. But, I also haven't the foggiest how much of a lateral
error in carriage position that this 150 microvolts represents either.

In the meantime it appears that if I want to push the rpms, I'll also need
to add a lot of air to the right of the beginning of the thread.

What I did at S200 2 days ago only had perhaps a fat 1/16" of air, and that
thread was cut very well indeed, far better than any metric screw I can buy
at Tractor Supply 2 to the bag for $0.50 a bag or more, out here in the
boonies.

It sounds like I should add about .1" of starting air for every 100 revs as
a general rule of thumb, which is good to know. 200 is about as slow as I
should go, drop to say 50 revs, and Z is just stepping along for every slot
that goes by in my 50 cycle 200 count encoder. Weird noise indeed..

Thank you very much John, that explanation really should be in the notes on
the wiki, with a link to it from both the G33 and G76 descriptions of the
gcode.

That said, I still think doing the backlash move and getting it over with
before it waits for the index pulse would be an improvement, however with
all the facts on the table, we still have at least half the problem I
noticed and should choose a spindle speed that Z still has at least a 200%
headroom to achieve, and simply leave that alone for the duration of the
thread being cut. And I'll quit beating this dead horse. ;-)

Cheers, Gene

[Jon Elson]

Post by John Kasunich
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.

Thanks very much for describing how this is accomplished. I remember
some of the discussion of damped oscillations of the Z axis at the start
of a thread. Ingenious fix, for the most part. I suspect there is
someone out there, somewhere, who needs to know exactly where
a thread starts on a particular part. But, that is sure a special use.
Anyway, this RPM-dependent offset really needs to be documented
in the user guide, so the average user doesn't get surprised by this.

Jon

[John Thornton]

John,

Do you know if the same algorithm is used for G76?

Thanks
John

Post by John Kasunich
I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.

[gene heskett]

Post by John Thornton
John,
Do you know if the same algorithm is used for G76?
Thanks
John

I would have to assume so since I was using G76 when I made the discovery.

Re-reading this many times, I may have come up with a solution of sorts
though. This assumes that the backlash is at least consistent, and that
sufficient air is allowed for. Backlash moves would still be at the
stepgen maxaccel and if lots of backlash, you would still hear the motor
overspeed a bit at the peak of the backlash move. I have managed to reduce
the backlash enough that I wasn't hearing that overspeed "gwow" at z start
yesterday.

Here is my thought experiment: Rather than assume a lagging index angle at
the synch point, why not do that same math, but use it to advance the start
of motion to be that same lag value, but used to issue the start motion at
that calculated angle in front of the _next_ index pulse, maintaining the
phase at effectively zero for all speeds at the time expense of using 2
index pulse periods, 2 revs of the spindle to get started for each pass.

Or has this approach already been explored and turned down in the back room
for other perfectly valid reasons?

Chris?

Post by John Thornton

Post by John Kasunich
I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.

------------------------------------------------------------------------
------ Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions will include endpoint security, mobile security and the
latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Dealing with failure is easy:
Work hard to improve.
Success is also easy to handle:
You've solved the wrong problem.
Work hard to improve.

[John Kasunich]

Post by John Thornton
Do you know if the same algorithm is used for G76?
Thanks
John

G76 is layered on top of the spindle synced motion that is
at the core of G33, so yes, they both work the same.

Keep in mind that I am recalling a conversation that I had
with Chris probably four years ago. I didn't implement the
fix, he did. It is possible that I'm mis-remembering
something, especially about the fix. I know my description
of the problem is accurate, but since I didn't do the fix,
I wouldn't count on the details of the fix being right. Before
editing the manuals, I would suggest contacting Chris and
asking if my description is correct. (I'm not sure if he
reads the users list consistently - there is a lot of traffic
here. He does read the developers list.)

Post by John Thornton
Here is my thought experiment: Rather than assume a lagging
index angle at the synch point, why not do that same math,
but use it to advance the start of motion to be that same
lag value, but used to issue the start motion at that calculated
angle in front of the _next_ index pulse, maintaining the
phase at effectively zero for all speeds at the time expense
of using 2 index pulse periods, 2 revs of the spindle to get
started for each pass.
Or has this approach already been explored and turned down
in the back room for other perfectly valid reasons?

I think it was discussed. I don't recall if there was some
subtle problem that made it not work for some cases, or if
it was simply a matter of being more complex, thus more
difficult to implement and be sure that it was right.

One thing to keep in mind - the spindle sync algorithms that
are used for G76 and G33 lathe threading are also used for
rigid tapping on mills. In that case, the spindle can reverse.
Consider the situation where one index pulse arrives, we decide
to start moving on the next one, calculate the offset so we can
start before it arrives, then the spindle reverses and it never
arrives. What if the reversal happens before we get to the
calculated starting point? What if it happens after we get to
the starting point, but we before get to the index?

All those special cases need to be considered when designing
an algorithm. The one we have now isn't perfect, but it is
pretty good (based on the fact that it has been working for
years before anybody ran into this issue.)

There are a couple of sayings:

"Good enough is the enemy of perfect" - meaning that when you
have something that works fairly well, you tend to live with
it rather than investing the work to make it better (and run
the risk of making it worse).

"Perfect is the enemy of good enough" - meaning that you can
spend so much time trying to design something that will work
perfectly for everyone under every circumstance, that you
never get anything working at all.

I don't claim to be an expert at finding the proper point
between those two extremes...

[gene heskett]

Post by John Kasunich

Post by John Thornton
Do you know if the same algorithm is used for G76?
Thanks
John

G76 is layered on top of the spindle synced motion that is
at the core of G33, so yes, they both work the same.
Keep in mind that I am recalling a conversation that I had
with Chris probably four years ago. I didn't implement the
fix, he did. It is possible that I'm mis-remembering
something, especially about the fix. I know my description
of the problem is accurate, but since I didn't do the fix,
I wouldn't count on the details of the fix being right. Before
editing the manuals, I would suggest contacting Chris and
asking if my description is correct. (I'm not sure if he
reads the users list consistently - there is a lot of traffic
here. He does read the developers list.)

Post by John Thornton
Here is my thought experiment: Rather than assume a lagging
index angle at the synch point, why not do that same math,
but use it to advance the start of motion to be that same
lag value, but used to issue the start motion at that calculated
angle in front of the _next_ index pulse, maintaining the
phase at effectively zero for all speeds at the time expense
of using 2 index pulse periods, 2 revs of the spindle to get
started for each pass.
Or has this approach already been explored and turned down
in the back room for other perfectly valid reasons?

I think it was discussed. I don't recall if there was some
subtle problem that made it not work for some cases, or if
it was simply a matter of being more complex, thus more
difficult to implement and be sure that it was right.
One thing to keep in mind - the spindle sync algorithms that
are used for G76 and G33 lathe threading are also used for
rigid tapping on mills. In that case, the spindle can reverse.
Consider the situation where one index pulse arrives, we decide
to start moving on the next one, calculate the offset so we can
start before it arrives, then the spindle reverses and it never
arrives. What if the reversal happens before we get to the
calculated starting point? What if it happens after we get to
the starting point, but we before get to the index?
All those special cases need to be considered when designing
an algorithm. The one we have now isn't perfect, but it is
pretty good (based on the fact that it has been working for
years before anybody ran into this issue.)
"Good enough is the enemy of perfect" - meaning that when you
have something that works fairly well, you tend to live with
it rather than investing the work to make it better (and run
the risk of making it worse).
"Perfect is the enemy of good enough" - meaning that you can
spend so much time trying to design something that will work
perfectly for everyone under every circumstance, that you
never get anything working at all.
I don't claim to be an expert at finding the proper point
between those two extremes...

Chuckle, neither am I John. I have been known to make that claim a time or
3 but that was in broadcast electronics where with my history that dates
back to '64, and I knew I was on solid footing backed up by the physical
laws of electronics. Plug computer software into this mix, written by
someone who actually believes the cpu makers own usage manuals, and which I
have found to be wrong on several occasions, and I know better than to
cover a bet of this nature. Been known to lose a 6 pack of suds even.

But that doesn't keep me from using a 2" piece of solder wick as a ground
bus that quiets the noise figure of a radio receivers front end by 15db
either. That was a case where the improvement was well worth the cost
although it did take me several hours to define the best place to put it.
;-)

Cheers, Gene

[unknown]

EXCELLENT post and explanation of why its the way it is John! I would
nominate this going into a Wiki somewhere.

As for the different speeds causing different "phase delays", couldn't LCNC
calculate the delay and advance the Z code the reqd amt. It knows the
accel limit so it could calculate the delay and 'start early' w/ respect to
the spindle location so the threads always stay in phase. I can see
kinematics modules causing that calculation to get hairy but its
straightforward on 99% of lathes I suspect.

Thanks for the post again!
Stephen

Post by John Kasunich

Post by gene heskett

Post by Eric Keller

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not be
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread.

I think you are asking too much of the controller. When you are going
after precision, there is some sacrifice to be made in speed. This is
especially true when the machine is less than perfect. You could
potentially tune the controller a little better.
Eric

G76 is a canned cycle. It can be made to work the way I've described,
probably in less than 10 minutes time if I had the source, which I
haven't had since 2.2 days. I did build it once just to see if I
could do it, most of a decade back up the log.
As it is, the only way I can fix it is to un-tune the controller by
removing the backlash comp & letting that slack be taken up in the air,
or by writing it all as a loop that does do what needs to be done
using G33. But that only fixes my problem, why not fix it once, for
everybody?

Because backlash isn't really the problem (although backlash can
make the problem worse). Re-writing the program to use G33 won't
fix it either.
The real problem is the time (and distance) it takes the Z axis
to accelerate once the index comes around. Even a perfectly tight
machine with no backlash still has an acceleration rate limit.
This will be easier to explain if I use a concrete example.
Apologies in advance to those who live in the metric world.
I also apologize for the length - this is an obscure issue, so
the explanation has to go into some details...
Assume your machine has a Z acceleration rate of 5 inches per
second per second. Also assume you are cutting a 10 threads
per inch pitch.
First lets see what happens with a spindle speed of 240 RPM,
which is 4 revs per second. Since the pitch is 10 TPI, Z will
have to move at 4 revs/sec divided by 10 revs/inch = 0.40
inches/second. The Z axis accel rate is 5 in/sec/sec, so it
will take 0.40 inch/sec divided by 5 inches/sec/sec = 0.080
seconds for Z to get up to speed. In that 0.080 seconds, the
spindle will have rotated 4 revs/sec times 0.080 seconds = 0.32
revolutions, which is 115.2 degrees.
Now do the same calculations for a spindle speed of 300 RPM,
or 5 revs/second. Z speed is 5 revs/sec divided by 10 revs/inch
= 0.50 inches/sec. Accel time is now 0.50 inch/sec divided by
5 in/sec/sec = 0.100 seconds, and the spindle will have rotated
5 revs/sec times 0.100 seconds = 0.50 revolutions, or 180 degrees.
If you rough the thread at 240 RPM and try to finish it at 300 RPM,
the finish passes will be 180 minus 115.2 = 64.8 degrees delayed
relative to the roughing passes. At 10 TPI, or 0.1000 inches per
turn, that is 0.100 inches * (64.8 deg / 360 deg) = 0.018 inches.
That will be a messed up thread.
But this problem ONLY happens if you change spindle speed
between passes. If you keep the speed the same, the delay angle
is also the same, and the thread will be fine.
When G33 spindle synchronized motion was first added to
LinuxCNC, it didn't have this problem. It had a worse problem,
one that would show up even if you didn't change the spindle
speed.
The original G33 had an "internal" Z position reference that
would begin moving at the proper speed to cut the desired pitch
the instant that the index pulse arrived. Because this internal
Z started moving instantly, it didn't matter how fast the spindle
was turning - the thread would always be right. Unfortunately,
real motors can't accelerate instantly, so the "external" Z
command that actually runs the motor still needed to have
acceleration limits applied to it.
Lets work through what happened, using the same machine and
thread as in the previous calculations, at 300 RPM.
As soon as the index arrives, the internal Z starts moving at
0.50 inches/sec. The external Z has accel limiting, and we've
already calculated that it takes 0.100 seconds to reach 0.50
inches/sec. The average speed during that accel is 0.25
inches/sec, so the distance traveled is 0.100 times 0.25 =
0.025 inches. Meanwhile, in the first 0.100 seconds, the
internal Z has been moving at a constant 0.50 inches/sec,
and has moved 0.100 times 0.50 = 0.050 inches.
That means the external Z is lagging behind the internal one
by 0.025 inches. So LinuxCNC tells it to keep accelerating.
Over the next 0.0707 seconds, the internal Z keeps accelerating
at 5 inches/sec/sec, reaching a speed of 0.8535 inches/sec.
During this 0.0707 second period, it averaged 0.677 inches/sec,
and it moved 0.0475 inches. Meanwhile the internal Z is still
cruising along at 0.50 inches/sec, and moved 0.035 inches.
So during this 0.0707 seconds, the external Z gained 0.0125
inches on the internal one - half of the distance it needed
to make up.
But now it is moving too fast. So LinuxCNC tells it to slow down.
For the next 0.0707 seconds, it decelerates at 5 inches/sec/sec,
finally ending up back at 0.50 inches/sec, where it needs to be.
The average speed for this period is 0.677 inches/sec, and
the distance traveled is 0.0475 inches, while the internal
Z only moved 0.035 inches. So external Z has finished
catching up, both position and speed are matched, and we can
begin the cut.
This whole process took 0.2414 seconds from index arrival to
the point where it was safe to begin cutting. That is more
than twice as long as it takes to accelerate to the desired
speed. It also takes more than twice the Z distance, which
might mean the first part of the thread is the wrong pitch
if there isn't enough of an air cut.
The real problem is that the peak Z axis speed was 0.8535
inches per second, even though the thread we are cutting
only needs 0.50 inches per second.
What if we are running very close to the machine limit?
Suppose the machine is only capable of 0.52 inches per sec.
In theory we should be able to cut the thread at 300 RPM,
since we only need 0.50 inches/sec. Lets walk through
one more set of numbers.
For the first 0.100 seconds things are exactly the same.
External Z accelerates to 0.50 inches/sec, and falls
behind internal Z by 0.025 inches.
In the next 0.004 seconds, external Z reaches its top speed
of 0.52 inches/sec, and stops accelerating. During that
time, the average speed is 0.51 inches/sec, and it moves
0.00204 inches. Meanwhile internal Z moves 0.00200 inches,
so external Z gains 0.00004 inches. Since it started out
0.025 inches behind, it now 0.02496 inches behind.
Now external Z is cruising along at 0.52 inches per second.
It is slowly catching up to internal Z which is only going
0.50 inches per second. After 1.246 seconds of this, it
has caught up to within 0.00004 inches of where it should
be, and starts slowing down. As it slows back down to 0.50
inches/sec, it makes up that final bit of distance.
In this example, it takes 1.354 seconds and 0.677 inches
of travel for the Z axis to come into sync and be ready to
cut a proper thread. Compare that to the 0.100 seconds
and 0.025 inches that it needs simply to accelerate to
the proper speed.
I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.
--
John Kasunich
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[unknown]

Maybe use the max speed and max accel to calculate one offset to be applied
to all threading motion

Post by unknown
EXCELLENT post and explanation of why its the way it is John! I would
nominate this going into a Wiki somewhere.
As for the different speeds causing different "phase delays", couldn't LCNC
calculate the delay and advance the Z code the reqd amt. It knows the
accel limit so it could calculate the delay and 'start early' w/ respect to
the spindle location so the threads always stay in phase. I can see
kinematics modules causing that calculation to get hairy but its
straightforward on 99% of lathes I suspect.
Thanks for the post again!
Stephen

Post by John Kasunich

Post by gene heskett

Post by Eric Keller

Post by gene heskett
I did notice yesterday while cutting that 4mmx0.7 thread, which btw
came out real nice, that the spindle speed you start at should not

be

Post by John Kasunich

Post by gene heskett

Post by Eric Keller

Post by gene heskett
changed during the run as it will widen the cut thread, leaving a
distorted profile at the root of the thread.

I think you are asking too much of the controller. When you are

going

Post by John Kasunich

Post by gene heskett

Post by Eric Keller
after precision, there is some sacrifice to be made in speed. This

is

Post by John Kasunich

Post by gene heskett

Post by Eric Keller
especially true when the machine is less than perfect. You could
potentially tune the controller a little better.
Eric

G76 is a canned cycle. It can be made to work the way I've described,
probably in less than 10 minutes time if I had the source, which I
haven't had since 2.2 days. I did build it once just to see if I
could do it, most of a decade back up the log.
As it is, the only way I can fix it is to un-tune the controller by
removing the backlash comp & letting that slack be taken up in the air,
or by writing it all as a loop that does do what needs to be done
using G33. But that only fixes my problem, why not fix it once, for
everybody?

Because backlash isn't really the problem (although backlash can
make the problem worse). Re-writing the program to use G33 won't
fix it either.
The real problem is the time (and distance) it takes the Z axis
to accelerate once the index comes around. Even a perfectly tight
machine with no backlash still has an acceleration rate limit.
This will be easier to explain if I use a concrete example.
Apologies in advance to those who live in the metric world.
I also apologize for the length - this is an obscure issue, so
the explanation has to go into some details...
Assume your machine has a Z acceleration rate of 5 inches per
second per second. Also assume you are cutting a 10 threads
per inch pitch.
First lets see what happens with a spindle speed of 240 RPM,
which is 4 revs per second. Since the pitch is 10 TPI, Z will
have to move at 4 revs/sec divided by 10 revs/inch = 0.40
inches/second. The Z axis accel rate is 5 in/sec/sec, so it
will take 0.40 inch/sec divided by 5 inches/sec/sec = 0.080
seconds for Z to get up to speed. In that 0.080 seconds, the
spindle will have rotated 4 revs/sec times 0.080 seconds = 0.32
revolutions, which is 115.2 degrees.
Now do the same calculations for a spindle speed of 300 RPM,
or 5 revs/second. Z speed is 5 revs/sec divided by 10 revs/inch
= 0.50 inches/sec. Accel time is now 0.50 inch/sec divided by
5 in/sec/sec = 0.100 seconds, and the spindle will have rotated
5 revs/sec times 0.100 seconds = 0.50 revolutions, or 180 degrees.
If you rough the thread at 240 RPM and try to finish it at 300 RPM,
the finish passes will be 180 minus 115.2 = 64.8 degrees delayed
relative to the roughing passes. At 10 TPI, or 0.1000 inches per
turn, that is 0.100 inches * (64.8 deg / 360 deg) = 0.018 inches.
That will be a messed up thread.
But this problem ONLY happens if you change spindle speed
between passes. If you keep the speed the same, the delay angle
is also the same, and the thread will be fine.
When G33 spindle synchronized motion was first added to
LinuxCNC, it didn't have this problem. It had a worse problem,
one that would show up even if you didn't change the spindle
speed.
The original G33 had an "internal" Z position reference that
would begin moving at the proper speed to cut the desired pitch
the instant that the index pulse arrived. Because this internal
Z started moving instantly, it didn't matter how fast the spindle
was turning - the thread would always be right. Unfortunately,
real motors can't accelerate instantly, so the "external" Z
command that actually runs the motor still needed to have
acceleration limits applied to it.
Lets work through what happened, using the same machine and
thread as in the previous calculations, at 300 RPM.
As soon as the index arrives, the internal Z starts moving at
0.50 inches/sec. The external Z has accel limiting, and we've
already calculated that it takes 0.100 seconds to reach 0.50
inches/sec. The average speed during that accel is 0.25
inches/sec, so the distance traveled is 0.100 times 0.25 =
0.025 inches. Meanwhile, in the first 0.100 seconds, the
internal Z has been moving at a constant 0.50 inches/sec,
and has moved 0.100 times 0.50 = 0.050 inches.
That means the external Z is lagging behind the internal one
by 0.025 inches. So LinuxCNC tells it to keep accelerating.
Over the next 0.0707 seconds, the internal Z keeps accelerating
at 5 inches/sec/sec, reaching a speed of 0.8535 inches/sec.
During this 0.0707 second period, it averaged 0.677 inches/sec,
and it moved 0.0475 inches. Meanwhile the internal Z is still
cruising along at 0.50 inches/sec, and moved 0.035 inches.
So during this 0.0707 seconds, the external Z gained 0.0125
inches on the internal one - half of the distance it needed
to make up.
But now it is moving too fast. So LinuxCNC tells it to slow down.
For the next 0.0707 seconds, it decelerates at 5 inches/sec/sec,
finally ending up back at 0.50 inches/sec, where it needs to be.
The average speed for this period is 0.677 inches/sec, and
the distance traveled is 0.0475 inches, while the internal
Z only moved 0.035 inches. So external Z has finished
catching up, both position and speed are matched, and we can
begin the cut.
This whole process took 0.2414 seconds from index arrival to
the point where it was safe to begin cutting. That is more
than twice as long as it takes to accelerate to the desired
speed. It also takes more than twice the Z distance, which
might mean the first part of the thread is the wrong pitch
if there isn't enough of an air cut.
The real problem is that the peak Z axis speed was 0.8535
inches per second, even though the thread we are cutting
only needs 0.50 inches per second.
What if we are running very close to the machine limit?
Suppose the machine is only capable of 0.52 inches per sec.
In theory we should be able to cut the thread at 300 RPM,
since we only need 0.50 inches/sec. Lets walk through
one more set of numbers.
For the first 0.100 seconds things are exactly the same.
External Z accelerates to 0.50 inches/sec, and falls
behind internal Z by 0.025 inches.
In the next 0.004 seconds, external Z reaches its top speed
of 0.52 inches/sec, and stops accelerating. During that
time, the average speed is 0.51 inches/sec, and it moves
0.00204 inches. Meanwhile internal Z moves 0.00200 inches,
so external Z gains 0.00004 inches. Since it started out
0.025 inches behind, it now 0.02496 inches behind.
Now external Z is cruising along at 0.52 inches per second.
It is slowly catching up to internal Z which is only going
0.50 inches per second. After 1.246 seconds of this, it
has caught up to within 0.00004 inches of where it should
be, and starts slowing down. As it slows back down to 0.50
inches/sec, it makes up that final bit of distance.
In this example, it takes 1.354 seconds and 0.677 inches
of travel for the Z axis to come into sync and be ready to
cut a proper thread. Compare that to the 0.100 seconds
and 0.025 inches that it needs simply to accelerate to
the proper speed.
I first observed this problem on my lathe a few months
after G33 was added. I could hear strange noises as the
motor first accelerated to higher than the proper speed,
then decelerated again. I also got bad threads on the
end of my part, because the sync process was using a lot
more Z distance than it should. I described the problem
to Chris Radek (who implemented G33) and he worked out
At the beginning of each G33 pass, LinuxCNC uses the spindle
speed and the machine limits to calculate how long it will
take Z to accelerate, and determines how many degrees the
spindle will rotate during that time. It then adds that
angle to the index position and computes the Z position
using the corrected spindle angle. That means that Z will
reach the correct position just as it finishes accelerating
to the proper speed, and can immediately begin cutting a
good thread. Z will never have to move faster than you
would expect given the spindle speed and thread pitch.
The downside of this fix is that the offset is different
if the spindle speed is different. I was worried about
that at the time, and argued with Chris about it. But
I couldn't come up with a better way to solve the problem.
It has been at three or four years now (maybe longer?),
and this is the first time someone has been bitten by
this particular behavior, so I think Chris was right.
--
John Kasunich

------------------------------------------------------------------------------

Post by John Kasunich
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users