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





 

Art,
I need to digest what you posted.
I am using rev .027 and will update to version .028.

I need to do a few things ( paper boy decided to put the f'n paper through the front window   , so first things first ).
I fixed my pc problem, new pc put together and it is solid! So need to play some, but this pc is showing only 1 or 2
change in the driver test and is as good as the one i borrowed. So this gives us a comparison with another solid pc.

The lead is always increasing for the thread test recently done.

  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%..?

ANS: My screen ( lathe screen ) dosn't show the kernal speed. I think chip modified a mill screen  to show it some time ago and will try and find it. If you have a screen with it on it post it and will use it.

  Do you have any way of telling externally what the real spindle RPM is when you have a reading on the screen?
ANS:Yes, I am using a Hasler Speed Indicator which reads to within 1 or 2 rpm and is quite consistant. I always let the spindle run a while and then try check the rpm before, during, and after a test if i can . That's the best i can do.

If you select a higher pitch..say .5 , is the lead error still the same amount or does it scale with the pitch selected?

ANS: I haven't done enough testing to really say. I'll think about the pitch selection and range and see what i can come with like .025,  .050, .1 as they are easy to measure on the toolmakers microscope. I am trying to stay at one selected rpm, minmizing axis influences.

As far as the screw and nut, yep the nut will go on. But it depends on the nut length. I know i can tap a piece
and then do a thread on the manual lathe with a min of backlash and it will track the thread very accurately. So say you have a nut 3/4" long and a fine thread, the nut would bind. Sort of like putting a metric nut  onto an imperial thread. But let's not divert away from the testing.

Later,
RICH

Hello all:

I have read the entire thread this afternoon, and marvel at the efforts to solve this problem. The electronic/technical skills of all involved is certainly high, and a great deal of work has been put forth by all.

However, this problem appears to be escalating to higher and higher levels of complexity, with computer clock microsecond timing and motor speed variables shifting about seemingly at random. I wholly agree with the post's of  Simpson36. Perhaps it is time to rethink the problem, i.e. think "simple."

Engine lathes have been cutting threads for a long, long time, and the problem of synchronizing the spindle/carriage is done with a precision lead screw, geared to the spindle, which moves the carriage by means of a bronze half-nut, engaged at the appropriate time as indicated by a carriage dial geared to the lead screw. The machinist was the computer, watching the carriage dial to engage the half-nut at the exact moment, to synchronize spindle and threading tool exactly, after selecting the gearbox change gears for the thread pitch. 

The spindle index-pulse signal has now replaced carriage dial and half-nut, and the machinist's eye. The lead screw is geared to the carriage motor and motor encoder. But, the old school gear train between spindle and lead screw is gone; replaced by microsecond time clocking counters, motor speed and torque guesstimates, number averaging, and much more things that this writer does not understand at all. However, it does seem akin to the old-school gearing system, except rubber bands are used where gears and keyways used to be! And, it is not simple.

May I suggest using an encoder on the spindle, with the index-pulse retained of course. The spindle encoder signals become the baseline source of all timing for carriage motor drive synchronization. These spindle encoder signals become an electronic gearbox, if linked correctly with the carriage drive encoder counts. Spindle speed can vary all over the place, as well as the Computer frequency clock ticks, and will in no way affect the "electric gearbox" ratio between spindle and carriage.

Example 1:
500 count/rev encoder on spindle, carriage encoder .0001" linear travel per encoder pulse (2000 count/revolution , .1/5 inch pitch leadscrew)
Cutting a 1/4-20 thread, the pitch is .05" per 500 pulses per revolution of spindle. .05 linear travel = 500 linear motor pulses, per 500 pulses from spindle encoder.

Example 2:
Cutting a 1/2-13 thread, the pitch is .076923077" linear travel. This = 769.23077 pulses per 500 spindle pulses per one spindle rotation. It would take 4 revolutions, or 4 full pitches before a full .0001 pulse step had to be added, if the ratio was 500/769.

With a 500 count spindle encoder, at 600 RPM, the pulses per second are only 5000 pulses per second. If I read the thread correctly, the number of 25,000 PPS is the clock speed of Mach3. I seriously doubt anyone is going to want to do threading over 1200 RPM, and the coarser the thread, the lower the spindle speed becomes. If the spindle speed must be high, i.e. fine pitch, small diameter, the Mach threading program should be able to post an upper limit spindle speed for a given thread pitch. 

I am sure there are elegant, mathematical routines to synchronize the lathe spindle and carriage, for any thread pitch. Machining threads to a known standard of precision is fundamental, in the machine industry.

Regards,
John

Art,
I am back to using ver .027.    If there is a problem that with using that version let me know. Ver .028 was a mess.  Four installs and a few hours of agrivation and back i went! It  just would not send a signal out the PP. Couldn't run the machine! I think it didn't like the address of the PP and few other things.

John,
Yes, slaving the spindle to Z would be nice if possible in Mach and have used it that way with another program. Maybe the SS will provide for it some day.

RICH

Chestermarine

500 line encoder at 600 rpm would be 20,000 per second. also threading above 600 rpm is a daily occurrence for most people that use carbide, most of my threading is in excess of 1,000rpm.


Hood

Hi John:

   Your right of course, slaving to an encoder woudl give perfect threads. The problem is that Mach3 uses Windows in a semi-real-time environment.
While I managed to make Windows run in real-time, I cant do division in the driver. There is no easy way to do a geared slaving. I do have already
a encoder type of threading driver. We use a 100 slot wheel with a separate index pulse. BUT, its still a game of timing and uSecond timing, though the
statistical revelance of the numbers are higher.
   I cant fully explain techincally why  we have to deal with it the way we do, but its a result of the technical challenges faced when trying to make Windows
run in a real-time mode. Take an encoder for example, if it runs at 600rpm and has 100 slots per wheel, thats 1000 inputs per second, and the kernal typically
only runs at 25000 , so it leaves only 25 intervals between slots to do corrective actioins, and without a proper floating point gearing, its very hard to arrange.

   I worry about accelerative discontinuities and jerk from disturbing the waveform too much due to corrections. In the end it boild down to a rather easy solution in the
mind, if an output is planned at a certain spindle speed, we may have to put out 3 steps per encoder pulse for example.. but the triggering of this is very difficult and its
why the threading is triggered to go, then slowly adapted to changes.. its really all due to the lack of floating point in the driver. There are ways around that, and I
may in the end have to go there, but its far from simple, so all this testing is really about finding all the variables, and seeing exactly whats necessary as a result.


 Rich:
  Understood, sorry about that version, Im not sure why it wont put out for you, seems to work well here.. but Ill investigate to see if I messed up somewhere. 
My entire thrust was to try to make it weasier on you, not harder, so drop that version till Im sure I can make it work better for you.
The problem with .027 is it doesnt have certain corrrections in it to allow me to do a simple driver change to switch the way things are done.

Art

ART,
I replaced the ver .027 of Mach.exec in the Mach directory with  the file you posted ( Mach3threadOct2 )  from reply #460 and that works and the version now say's .028.
( The original installation of .028, had me really going nuts as i thought something was wrong with the new pc's PP or installation of it ).
So I assume all is good now. 
RICH

Rich:

  Excellent. That will allow me to make some changes.

 The tests youve been doing all use the original MAch3 threading code, with no real changes to the timers, they still use the number of interrupts
as thir trigger. Im looking at updateing that to PCI bus timing, which is in nanoseconds. Im thinking that way if the computer is less than stable, it wont matter
as only the actual time from index to index will count. It should make the rpm more accurate ..

Thx
Art

ART,
I am loading software onto the pc so won't be till later today for actaul tests.
Till then,
RICH

Rich:

 Take your time.. no rush on this stuff at all..

Art