Hello Guest it is September 15, 2019, 09:16:41 PM

Author Topic: Problems threading on the lathe  (Read 330050 times)

0 Members and 1 Guest are viewing this topic.

Offline simpson36

*
  •  1,374 1,374
    • View Profile
Re: Problems threading on the lathe
« Reply #480 on: October 05, 2009, 04:27:38 AM »
Now we start the movement, since we're in mm/rev mode, we know the mm's of motion were calculated based on 24,000,000 clock cycles per rotation. If the ortation is sensed to be now 2700,000 clocks per rotation, we know the spindle has slowed by 12.5% .. so we now slow the output during the next rotation by 12.5%, and keep track of this rotation.

I pondered this proceedure when Art originally posted it, but a pitch error INCREASE would not be consistent with the above quoted correction proceedure, so it was an unresolvable quandry. Now that Rich has discovered that the pitch is DECREASING, it makes sense.

Therefor, I can submit a possible solution . . .  hopefully.

Taking the above quoted proceedure as literal and accurate, a correction of only 100% of the previous rotation error is not adequate. While the error would removed from subsequent rotations, the original measured error remains. Also, as stated elsewhere by Art, the process begins anew with each pass. So absent historical data being brought forward, this remaining error would naturally accumulate.

My suggestion for a solution to this issue is simply to make the correction in a subsequent pass in an amount that will not only eliminate the error in the current pass, but ALSO make the correction for the error measured in the previous rotation, which is still present in the thread at the begining of the 'correction' rotation. Only this combined correction would result in restoring the correct relationship at the end of the adjutment event.

A simplistic example would be that the measured error is 5. If the next rotatation compenstaes by 5, as described in the quoted passage, then the overall thread progress still contains the original error, which will be carried thru the entire pass, and then be componded by the same process occurring anew because the next iteration is blind to the previous data.

It seems to me that adding a correction for the previous (measured) rotation to the calculated correction for the current rotation is the missing link.




Offline RICH

*
  • *
  •  7,358 7,358
    • View Profile
Re: Problems threading on the lathe
« Reply #481 on: October 05, 2009, 07:43:36 PM »
ART,
Did a few more test pieces today. Same 115 rpm, 40 passes @ .0001" deep for 10,20,40 TPI.
I used the standard lathe screen and threading wizard.
Now we know that the tracking was good but the lead was decreasing. So i tried the tests with adjusted lead.
The rounded lead error was a decrease of .008" / inch. So I just changed the lead to be used in the wizard as follows:

TPI       TRUE PITCH     MODIFIED PITCH
10         .1                  .1008
20         .050               .0504
40         .025               .0252

The Gcode provided by the wizard will post the modified feedrate ( namely .1008 / .0504 / .0252 ) even though it rounds it in the wizard screen.

The lead error in 1" was almost un-measurable ( including each crest / root distance ............ 0 or under .0005" / inch. That's about as perfect as you can get! Heck, what are you measuring, the lead screw accuracy if you know what i mean.

You can also decrease the inputed lead if you want to take care of an advancing cut lead.  I haven't tried a 0-80 to see if the lead should be modified to .01256 ( don't cut to many 1" long 0-80's ).

Will relative /  ratioed numbers hold true for other rpm? I don't know.

So, if you left the threading code alone, and a user tested ie; cut a scribbed test piece at .1" pitch for 1 or 2" long and very accurately measure the lead, then adjust feedrate accordingly, they may just solve their problem.
It's a work around, an easy one, but users must remember that there are a lot of other influences that can play into threading.

Is John S doing any testing?
 :)  :)  :)  :)  :)  :)
RICH

Offline RICH

*
  • *
  •  7,358 7,358
    • View Profile
Re: Problems threading on the lathe
« Reply #482 on: October 05, 2009, 08:26:20 PM »
Here is apicture of the threads done in last post. There is only one single scribed line on each piece.

BTW, you need a realy good top notch tach to measure IPM accurately. Just thought i would mention that in case you try to measure and associate spindle rpm to actaul Z feedrate while threading. Myspeed indicator just doesn't cut it.

RICH

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #483 on: October 05, 2009, 10:31:19 PM »
Rich:

   Interesting. Youve proved that computer is very stable, its also interesting that at 115 RPM it seems no matter what pitch, .8% increase in pitch will
make it correct. Be interesting to see how that scales with feedrate. By the way, have you ever used the advanced threading plugin to see how the RPM
measurement differs from the normal Mach3's? Id be curious as to hwo it reports RPM vs how the normal Mach3 reports RPM..

 In the advanced threading plugin, if you set the timing and index inputs both the the index pins input, it will act as if you have a 1 slot wheel on it, and will read
the RPM based on actual time, not interrupts.


Simpson:

    The code actually does carry history forward.. Ill see if I can come up with a better explaination of how it does that, really I need to get in there and study its behaviour a bit
to refresh myself before I attempt it. Ive been working on Tempest a bit too long, I get a bit rusty on the threading code. :)

Art

 

Offline RICH

*
  • *
  •  7,358 7,358
    • View Profile
Re: Problems threading on the lathe
« Reply #484 on: October 05, 2009, 10:37:57 PM »
ART,
Assume the advanced threading plug in was the one we trying to use a few months ago.
Is that correct?
RICH
« Last Edit: October 05, 2009, 10:52:47 PM by RICH »

Offline RICH

*
  • *
  •  7,358 7,358
    • View Profile
Re: Problems threading on the lathe
« Reply #485 on: October 05, 2009, 10:52:05 PM »
Hmm,
Ok, i have a working opto that i can use and can make up a multislot disc rather easily for it. One is encoder #3 and one is the index in the pin out if i rememeber correctly.Since both work off 5 volts that may be rather easy to do now for me.  I thought i could be rather tricky and just take spindle and Z axis ft /min, but quickly found out that my rpm counter is not accurate enough.

I will do some testing at other spindle speeds to see what happens.
RICH
« Last Edit: October 05, 2009, 10:54:13 PM by RICH »

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #486 on: October 05, 2009, 11:10:53 PM »
Simpson:

  Just had a refresher on how I did that in the threading module. I figure a better explanation is in order of exactly how I
manage single point threading. I tend to agree on the face of it with those that say its impossible, but when I developed it
I wasnt aware of that. :-) , so I did as cloase as I think could be done given the restrictions in architecture.

 So we have to accept certain givens..

1) Motion is preplanned, in a buffer of steps. This buffer can be considered an endless array of bytes. most of the time each entry will be zero. Each interrupt cycle.. at 25000 times a second, an array iten is retirved, and analysed, if a bit 0, for example is a 1, a step is put out on the X motor. If its a zero, no step is put out, if -1, a backwards setp is put out. That array item is delted, and next interrupt we get the next one( This is all simplified for examplication. )

2) Due to this, the driver of course knows nothing about speed, acceleration, or even if a motor is stepping or not, we simply have an array of bytes, and we step though that array one byte at a time. Mach3 continuously refills this array of bytes so the next stepo will be correct.

3) TO measure RPM, we count how many interrupts between each index pulse. This is divied out to find the rpm. ( The advanced threading uses time as the measurement)

Ok, so we have those limitations, we have no idea what speed any motor is moving.. or even if it is. BUT, we know time is linear, counting at 25000 steps a second. We know prior to the threading starting that the spindle is hitting index every 11345 interrupts. ( for example).

 So when threading starts, we start a counter.. we count the number of interrupts between each suceeding index pulse and place it in a var called CURRPM.. Then, every interrupt we add CURRPM to our originally zeroed counter, we then subtract the reference index pulse count. If this number is greater than the reference count, we skip an interrupt processing. This is a bresenham divider time relinearisation of the pulse streams time, not the motor motion directly. A motor moving at full speed, would then have 1 step delayed till next interrupt, but normally, this operation would be a small fraction of one step of a motor in time.

   Thats a bit hard to understand.. consider this sequence of events..


Kernal speed 25000. Threading is commanded and spindle RPM is 120. An index occurs every 12500 interrupts. Threading begins..

On each interrupt counter = (counter + currpm) - refrpm

we start with..
Counter : 0  CurRPM: 12500  RefRPM: 12500

  The counter wont change for 1 full rotation, its always getting 12500 added to it, and 12500 subtracted from it..

Now the next interrupt comes in at 12900..

So on that interrupt, the counter is now 12900 - 12500 = 400.
Eachinterrupt this number will increase by 400. When it hits 12500, an interrupt is skipped. Not a motor step, an interrupt.
This means time is stretched, the motor motions, all equally are slowed by 1/25000 of their time base. The ref is then subtratce from the counter and it all continues.

  This means that as each rotation slows..or even maintains its new speed, the error count grows, and is compunded by further slowdowns
so it actually has a sense of history. Time corrections are also applied linearly across the motion for this correction. And since the number subtracted when an interrupt is skipped is the ref rpm, fractional counts are kept, and spread across the next rotation. As the speed increases to normal speed, the counter approaches equilibriam again with its total zero.. and no further time intervals are skipped.


  This is all necessary due to the way motion is planned before the threading begins, so all we can alter is time itself, not anything to
do with motor motion.

   You question is well put though, if the spindle has slowed by 1%, we can then pretty much anticipate that the next will also be 1%, so why not double down and correct at 2% for the first slow rotation. You cant really do that though as you cant really make that assumption. It could be just a slightly slow index input for example.. so its best to stay exactly one rotation behind at all times. Mathmatically its the best one can do with a single input, If the RPM is, indeed ,slow on the next by 1% again, then it hasnt changed, nor will the algorithms slowdown, it will be exacly 1 rev behind, but if for whatever reason the rpm increases back to normal, ( VFD self correction for example ), then the algorithm will automatically speed back up to normal and we'll be exactly 1 rev behind it again.  

  The only way we get fooled is if the vfd speeds up to a speed greater then the start reference speed, in which case the error from the previosu rev cannot be corrected, and will be forever locked in, and will grow on each rev that is faster than reference. However, since remainders are taken into account by the bresenham, its counter goes negative by the uncorrected amount, and should the rpm slow down, the algorithm will not slow down to compensate until the over speed that was uncorrected is eaten up.

   Its a pretty simple algoritm, simple enough to be very smart. Overspeeds will be corrected when and if they can, underspeeds will be 1 rev behind at all times, and very small fractions are accounted for. Its why its actually possible to do this without knowing anything about the motors motion, its simply the matching of two varying time bases by a counter than keeps track of total time with no capability of rollover.



Hope this explanation helps, it actually helped me to write it and get reaquainted with how the heck the code works in the first place.

Thx
Art

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #487 on: October 05, 2009, 11:14:20 PM »
Rich:

  John S is at a show, but he'll be joining us soon on this.

For the multislot, you can use an encoder input, ( on ecoder #3 as I recall) OR a timing input, as well as index input . If using encoder I
think its possible to just use the encoder. I need to look at that module now and get back up to snuff on how that worked. Last threads cut on it were
looking good to me, but had variances similar to your initial tests. The two work very differently, so similarities in results will help point us to the real culprit and what
( if anything ) can be done to make it all better.

 I do recall the new module was much better at rpm measurment..

Art

Offline RICH

*
  • *
  •  7,358 7,358
    • View Profile
Re: Problems threading on the lathe
« Reply #488 on: October 06, 2009, 08:43:40 PM »
ART,

Just a few more tests.
I was curious on how things would behave as the spindle speed was increased.

In post # 481 things scaled rather linear at 115 rpm. as shown below.

TPI       TRUE PITCH     MODIFIED PITCH
10         .1                  .1008
20         .050               .0504
40         .025               .0252

So i did some testing at higher spindle speeds. If I go past 600 rpm i would need to change kernal speed
above 25000khz so a little limited ( trying to keep stuff constant).

The threading was for 10 TPI ( .1 pitch ) 40 passes.
RPM      PITCH / Inch                   MODIFIED PITCH USED FOR PERFECT LEAD
            (DECREASE)
115      .008                               .1008
194      .0055                             .10055
402      .0035                             .10035

So the pitch decreases also as the RPM increases. I will assume that for smaller threads at the higher rpm
they would proportionately decrease as like the 115 rpm tests for 10, 20, 40 tpi.

Just a note, according to Mr. Smid, a lead error will be intoduced on long threads if you use a Feedrate less than
six figures ( not required for leads divided into 4 or fewer decimal places ).

RPM
--------
I din't try any of the advanced threading plugs in yet.  I will confirm my measured spindle rpm's  later since a  friend will be lending me an accurate time measuring device. 

I wonder if the error goes away at 1000 rpm?


RICH

Offline ART

*
  • *
  •  1,698 1,698
  • Tough as soggy paper.
    • View Profile
Re: Problems threading on the lathe
« Reply #489 on: October 06, 2009, 10:02:27 PM »
Rich:

  Interesting. The error decreases as speed increases..  I would have thought the reverse would have been true.
Since any perterbation of the timing in any of the variables would be a larger percentage of the time of one revolution
as we go faster, I would have thought any constant affecting us would then increase the error as we go faster.

  It would seem then that whatever the error is..is isnt a constant. It must be progressively getting smaller as the
interrupt timing gets smaller.  I woudl think calcuated feedrate cannot then be the problem as its decimal granularity is the same
for all speeds. I have to give this some thought as to why the non-intuituve nature of that result. It may be that any correction
being done is being doen for shorter periods as we go faster.. so any error in correction would then affect the result less and less.
Also, as the correction algorithm runs, its numbers woudl be smaller so interrupt skipping woudl occur less frequently..

 I think I may have to send you a driver with speed correction turned off entirely to see what the effect of that would be, I think
Im getting an idea of where the problem may lie, it may be a granularity of spindle rpm measurment causing a correctiion to be applied
that is really not necesaary..

Ill crunch some numbers and let you know what I think.

Art