ART,
TEST:  REPLY #526 / SPINDLE SPEED AVERAGING / NO ADVANCED THREADING / VER.028
115rpm / 40 passes/.1P

Not zero but close. The threading was done to a 2" length.
The lead increase is .002" per inch. I measured along the length in 4 quadrants of the
piece. Lead as follows:
.5"  - .001"
1.0" - .002"
1.5" - .003
2.0" - .004'

Single scribed line. I wanted to make sure, so see attached pic taken at 100X magnification.
The first scribed line looked just as good as the last one along the length." like that.
Just a sharp V and no sloping towards the root.

I can't test anymore until I get back on Tuesday.

How about another tweak if you think worthwhile? If the additional testing with finer picthes goes sour for some reason then i can pull back to this one for comparison when finer pitch's or increased speeds are tested.

HMM......like my music prof used to say......
"Perfection is allways sought after, never achieved, but much is to be gained in the pursuit of it."  

RICH

Hood,
Didn't take it that way my friend.
These tests are being done with the new computer and converted lathe. There is no comparison, so to spead of, to the Sherline lathe relative to repeatabilty and accuracy. I think the same about the computers. In fact, i am right with you in thinking. Current testing would be one system taken to some level and used as a basis to compare other combinations. I can then mix and match computers, lathes,SS and see what happens.

It could be that what is good for one system is bad for another. If another person starts testing and gets different results, should be able to relate or question more intelligently.

 I am still a little concerned about the motor i am using as to rpm and Wednesday a friend will be coming over and we will test and see what we get. You can't use some of the rpm tach's since they read to .05% +- 1 rpm and that isn't good enough. We may not be able to do any better. Gets back to component verses the lathe system as a whole.

I certainly don't want to waste Art's time. Hopefully he's getting a lot of comparative info for his use.
Darn if i am not learning a lot.

Just some thought's,
RICH

Rich:

 Looking pretty good then so far. I think your right, lets press the envelope and see if we can make it as good as we can. Here's a .001 correction applied to
previous version. Tuesdays fine, and again, as always, thanks for the great results posted. The interesting thing will be how it scales to higher RPM's, if we do achieve zero
runout. 

Art

ART,
Tests for posted version in reply #532.

TEST#1 - 115RPM / .1P / SCRIBBING TEST STOPPED
I stopped the scibbing test at pass # 11 because on the third pass timing went bad.
The first three passes had a .009" / inch Decrease.
The following 8 passes had a .003 / inch Increase.
Both were single line scribes.

TEST#2 - 115RPM / .1P / 40 passes  ( retest to see if test #1 would repeat )
I left the spindle run for a few minutes.
Single scirbe at .003" Increase in lead.

Picture #1 shows test #1 &2

TEST#3 - 402 RPM / .1P / 40 passes  ( to test scaling due to rpm change )
The first 10 passes were  visualy consistent and a .002" / inch Increase.
Then a slight change at pass # 11 and consistent passes until 21.
Pass 21 changed the lead and was consistent to #39 and there was a .0055" / inch Increase.
Pass 39 changed the lead to a Increase of .008" / inch Increase
SO three passes, and at some time interval ( pass 11, 21, 39 ) you got an increase of lead.
Picture #2 shows the three intervals.

SO this is a mixed bag, but, the change in lead over a some time period reminds me of what I and
others have experienced with the current threading, that sometime during the complete threading cycle,
one or two passes are cutting deeper.( I don't think that is really what happens, i think it's a change in lead
as you can't see / measure it when actual full cut threads are being done. )

I should have left test #1 go on to see what would have happened.

I am going to go back to the version that gave a .002" / inch lead error and expand that testing some.
See if it behaves stable. Can i repeat the one test done?, will there be any pass changes?, scaling at rpm?

Any comments?

RICH

Rich:

  Thanks to your testing I think I have a grasp of whats going on. What to do about it is more complex.
I'm not as sure as to why the variable lead.. though its pretty close at this point, but I highly suspect
whats going on is the RPM is locking in at variosu values at times. This can be caused by many things.

  Mach3 when it gets a threading command, sets up the pass using the current spindle RPM, a split second later
the driver see's this command and "locks in" the current spindle RPM for the entire pass, correcting if the RPM changes
from the "locked" rpm.

   So one of two things is causing that intermittant bad pass. The RPM is wrong at some point in the process. On the versions
your testing the correction is turned off, that helps narrow this down. It means for sure the RPM is different by a percentage
 from one pass to another. If the locked in RPM is different from the RPM that Mach3 used to calcuate the pass, youll get a
leading or decreasing pitch on that pass. We can see a .001 or .003 or .005 pitch as normal, but then on a particular pass the
RPM gets locked at a wrong RPM.

   I have a few things to check inthe code now.. it could be the planner is processing the next threading pass before the first is done, thus the rpm
could be lower due to load when the next thread command is processed. I need to ensure it locks out the next runs processing till the first one is done.

  You can stop testing for a bit while I digest the numbers and see what I can do to tighten this up. Hopefully , thats all it is,
otherwise it means the RPM is wrong occasionally for some reason.. and that may be arder t find. 

I suspect  youll find even the earlier version do as this report suggests, specially if the spindle is cold. I have heard runnign it for a few minutes till stable
helps it be stable through the run.

Thx
Art

ART,
Post when you want to try something.
Appreciate the effort your putting into the threading.
RICH

Hi Rich:

 One thing I notice while looking to the code, you really need a G0 move between any G32 moves.. With G76 this isnt a problem as it injects g0 moves to pullout, but in yur testing, did you use G0 moves to reposition the passes back to the start?

  The of the g0 makes the next g32 only use the rpm current at end of g0 before it plans the next thread pass speed. Seems I may need to do some work on that..

Thx
Art

ART,
Yes.
All the code  is generated by the threading wizard and the m1076.m1s is set to true. You get two G0 moves prior to start of the thread. Before Cycle Start is clicked to begin the threading, i always waite some time, not moving the mouse etc. and don't do anything during the threading. Once i opened the threading diagnostics window after a thread pass and it caused a major lead error in the next pass. So i don't even touch the mouse etc during the threading post Cycle Start.

BTW, we checked the spindle rpm out today. The home built counter can read to 1us and is better than digital storage scopes as the sampling rate,  and other stuff can be changed. The index pulse was used for input. Basicaly the instrument does what your advanced diagnostics provides minus the graphing.  Anybody using a mechanical rpm reader or tach, well I will say, the diagnostics in Mach lathe is better!

RICH

Rich:

   Thanks for the verification. Now that the RPM is measured based on time rather then number of int's, in theory the susceptability to
switching screens should be less, but still there.

   In general operation as the index pulse swings by the sensor, MAch3 will either see it immediately , OR on the next interrupt. So
the typical variation of RPM cant be made better than  + or - 40us at 25Khz. SO a variance of 100RPM to 99.99 is what we should get
typically. Its hard to explain why the spindle may get a planning RPM very different occasionally to make the thread advance so much.

 Hmm, I guess thats the golden question isnt it.. what rpm WAS used for each line. I think Ill make a version that saves a debug file
to show the planned RPM for each pass of the thread. If it shows the RPM has varied greatly on any pass from previous passes, that will
prove the advance was due to planning at a different feedrate.

 Ill post a version soon to do exactly that, youll be able to forensically see what feedrate was the end result just as it was planned.
If that shows very stable, we look elsewhere.


Thx
Art


 

Rich:

 Each time a G32 is processed, this version will write into the lasterrors.txt file the velocity in units/sec for that thread move. Be interesting to see the velocity it picks each move..

Thx
Art