Guest
Show Posts
901
General Mach Discussion / Re: Problems threading on the lathe
« on: October 02, 2009, 10:26:18 AM »
Rich:
I truly love your testing..
OK, so you seem to have proven the effect a computer thats less than perfectly stable will have in terms of creating a variance on the thread.
And youve proven that when perfect ( or as near as Ive seen ) the computer will produce a slight Z variance in terms of an increasing pitch.
( I take it the pitch always increases..never decreases? )..
So now what..
Lets crunch that a little bit...
The lead error ( if always advancing ) would seem to indicate the Z is moving FASTER than perfect speed at a rate of .009 over an inch,
so thats exactly .9% too fast for a Z motion. Thats a very interesting result. Since MAch3 cannot speed up the planned motion for correction, but can only slow it down, it would indicate that the planning is off in speed by .9%.
So the system is planning for steps at 25000 per second. ( Actually, it uses the counted pulses per second, so that may be 25002 on yours for example) anyway.. at 115RPM, thats 1.91666 revs per second. So one rev is .52173 seconds per rev. And the lead must be off .009/.0172" per second. So that seems to indicate the speed of the Z is too fast by .01725 inches per second, or 1.035 inches per minute.
Im thinking thats the issue.
Now Mach3 is seeing the 115RPM call for threading, setting a feed speed of ( pitch/spindle speed),
and telling the planner to output pulses with a corrected time base of ( yourCPU'sPPS / kernalspeed). It does this
assuming that this is the perfect non-corrected thread motion once triggered for one pass of the thread. Since the
driver cannot speed up the motion, but can only slow it down, the advancing pitch of your tests woudl seem to show that
the real problem is in the perperation steps, not the corrective one. To have pitch advance would seem to remove the
driver from the equation because its outputting too fast for the thread.
Now I have to say that a .9% lead error is not something I consider very high in terms of what we're doign in single
point threading.. Id suspect a nut would screw on from start to any length since the error remains the same over the length of the
nut. But having said that, it'd be very interesting if we could eliminate that error, then take on the correction to see if we can
do something similar there to make it more efficient if indeed it does have any trouble at that end.
( this letter is over an hour long in typing as I check code..
)
So it all boils down to one thing I guess for the tests youve done.
The motion is moving too fast ( advancing lead ) from start to end, and this seems consistant. To me this can only mean
the spindle speed is not being read correctly in terms of computed number, or the speed of the planner is not properly
being compensated by the difference in your CPU's read kernal speed vs commanded speed.
Now we know the faster the spindle speed the worse the error is. That may be some other effect, so maybe we should ignore that
for now. Lets just consider speed as the problem, only two factors can really affect it.. spindle speed calculation and kernal frequency.
Can you note the kernal frequency your getting on the diags page, if its very close we can eliminate that I think.. unless if 225 off, in which case thats the .9%..?
Do you have any way of telling externally what the real spindle RPM is when you have a reading on the screen?
If you select a higher pitch..say .5 , is the lead error still the same amount or does it scale with the pitch selected?
Ill attach here a new Mach3 executable called MachThread.exe , I need to know what code we're in for testing, this is .028 but my version of it so I can track any further tests we do. If we do indeed solve the issue, Ill send Brian a full update for release in the next version and update of current version. Ill also make up a new driver with a selection for no correction.
Thx
Art
I truly love your testing..
OK, so you seem to have proven the effect a computer thats less than perfectly stable will have in terms of creating a variance on the thread.
And youve proven that when perfect ( or as near as Ive seen ) the computer will produce a slight Z variance in terms of an increasing pitch.
( I take it the pitch always increases..never decreases? )..
So now what..
Lets crunch that a little bit...
The lead error ( if always advancing ) would seem to indicate the Z is moving FASTER than perfect speed at a rate of .009 over an inch,
so thats exactly .9% too fast for a Z motion. Thats a very interesting result. Since MAch3 cannot speed up the planned motion for correction, but can only slow it down, it would indicate that the planning is off in speed by .9%.
So the system is planning for steps at 25000 per second. ( Actually, it uses the counted pulses per second, so that may be 25002 on yours for example) anyway.. at 115RPM, thats 1.91666 revs per second. So one rev is .52173 seconds per rev. And the lead must be off .009/.0172" per second. So that seems to indicate the speed of the Z is too fast by .01725 inches per second, or 1.035 inches per minute.
Im thinking thats the issue.
Now Mach3 is seeing the 115RPM call for threading, setting a feed speed of ( pitch/spindle speed),
and telling the planner to output pulses with a corrected time base of ( yourCPU'sPPS / kernalspeed). It does this
assuming that this is the perfect non-corrected thread motion once triggered for one pass of the thread. Since the
driver cannot speed up the motion, but can only slow it down, the advancing pitch of your tests woudl seem to show that
the real problem is in the perperation steps, not the corrective one. To have pitch advance would seem to remove the
driver from the equation because its outputting too fast for the thread.
Now I have to say that a .9% lead error is not something I consider very high in terms of what we're doign in single
point threading.. Id suspect a nut would screw on from start to any length since the error remains the same over the length of the
nut. But having said that, it'd be very interesting if we could eliminate that error, then take on the correction to see if we can
do something similar there to make it more efficient if indeed it does have any trouble at that end.
( this letter is over an hour long in typing as I check code..
)So it all boils down to one thing I guess for the tests youve done.
The motion is moving too fast ( advancing lead ) from start to end, and this seems consistant. To me this can only mean
the spindle speed is not being read correctly in terms of computed number, or the speed of the planner is not properly
being compensated by the difference in your CPU's read kernal speed vs commanded speed.
Now we know the faster the spindle speed the worse the error is. That may be some other effect, so maybe we should ignore that
for now. Lets just consider speed as the problem, only two factors can really affect it.. spindle speed calculation and kernal frequency.
Can you note the kernal frequency your getting on the diags page, if its very close we can eliminate that I think.. unless if 225 off, in which case thats the .9%..?
Do you have any way of telling externally what the real spindle RPM is when you have a reading on the screen?
If you select a higher pitch..say .5 , is the lead error still the same amount or does it scale with the pitch selected?
Ill attach here a new Mach3 executable called MachThread.exe , I need to know what code we're in for testing, this is .028 but my version of it so I can track any further tests we do. If we do indeed solve the issue, Ill send Brian a full update for release in the next version and update of current version. Ill also make up a new driver with a selection for no correction.
Thx
Art