Perhaps I am missing something, but I see no way that any software can compensate for spindle speed using a single index pulse per rev. It is a physical impossibility no matter how fast the computer or the software is. These are the inescapable conditions that immediately occur to me;

1) No matter how many pulses per rev, the data is always after-the-fact, in other words, for a slowdown to be detected, it must have ALREADY occurred, so it is too late to compensate for deviations between the detection read and the previous read. Unless the delta in time and error is very tiny, AND the mechanical system response is extremely fast, then a correction, (which can only be done as a 'catch-up' unless some type of prediction is made), really looks to me to be undoable.

2) If the spindle motor slows down significantly, then it is a given that the drive motor has insufficient torque to maintain RPM. It would be illogical to presume that the already overloaded motor would have any available excess torque capacity to catch up with the now over advanced threading feed, so the only alternative would be to slow down the feed, which in turn would change the load on the motor since this action would change the effective depth of cut from the last pass in that portion of the thread where the correction is made.

I do not know how MACH attempts to keep the threading synchronized, but it seems to me that it is irrelevant because if my thinking it correct, there are not adequate data for one method and inadequate power in the other.

It occurs to me that only a very high number of samples per rev would have any chance of maintaining sync and then *perhaps* only if MACH had data on how many amps the motor is drawing during the cut.

The fact that people with very high power spindles (relative to the size thread being cut) have no problems tends to support my conclusion, but again, I may have missed something.

Rich I was actually meaning Machs Diagnostic screen but thinking about it the Turn screen may not show the pulse frequency. I use my own screen and its based on the Mill screen I made so it has the pulse frequency showing. Would be interesting to see if it alters in realtime as mine doesnt.
 Out of curiosity, what make CPUs do you use, all mine are AMD, just wondering if it could be as simple as the difference in the way AMD and Intel do things?

Hood

Rich,

Just a comment on your driver test result. The period of time that your pulse goes slow seems massive. I have never had any more than the width of perhaps a single pixel above or below that line, even at 100k.

It would be interesting to calculate the number of pulses effected during the duration of the disturbance

Hood,
 It's an Intel P4 and all the the others are Intel's also.
 I need to look at Threading Diagnostics and compare some data it gives. Was interesting to find that the PP wont read the 53 rpm while the SS would.
I noticed that the variance in the Mega clock rpms varied as the rpm went up, which relates to the locked RPM.

HMM......... the scribed lines i did were at 402 RPM while the actual threading ws done at 115 RPM, but fewer passes .....so if the variance is smaller at the lower rpms i wonder how the scribed lines would turn out at the lower rpms.
RICH

Simpson,
One of things that Art did was to provide for spindle slowdown and a lot of time was spent for the hobbiest.
A lot of those punny lathes ( i got one ) will have problems when trying to do anything over say a 40 or 32 thread.
You get spindle slowdown, and at say 24 TPI, it may be some 10% or more, yet the program adjusts , and you can accomplish the thread. I have even stopped the spindle for a second and recovered the threading cycle.
I have cut 1/2-13 in a steel rod with that punny lathe,but , you really need to experiment.
It does work! Trust me i have spent a lot of hours testing it. Just need to keep things in perspective though.
RICH

BTW,I agree with you on that if you have adequate torque / HP  ( not only the spindle but the axis system also ), accuracy and repeatability, to begin with ,then there will be  threading success. There is a whole community of users that don't have that. That's why i did the lathe conversion. But it is more complex than just the machine part. Computers can just suck at times. 

Simpson,
"It would be interesting to calculate the number of pulses effected during the duration of the disturbance"

Yep, same goes for the variance in pulses per second, but may not be as simple or relative as you would first think.
RICH

Simpson:

  Your right..and your wrong.

  During a period of rotation, there may be as many as say 5000 interrupt periods.. Mach3 is measuring how many interrupt periods occur, or used to. It now measures how many megaclocks occur, at a base rate of about 2Ghz say..

  So for each rotation we measue the megaclocks..this is before we actually cut. Now lets say we get 24,000,000 as a steady rate prior to cut. We simply divide to show the rpm..

 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.

 SO your right that the correction is always 1 rotation behind in terms of correction, but it can be shown statistically that if one rotation is off, the next rotation will be off the same amount +- a certain %, it may for example keep slowing down.. in which case each rotations motion in the Z axis is further slowed. As a rolling % of correction we begin to approiach the center of the bell curve of probablities of where the spindle is likely at.

  Its a fairly good method of correction, and works well as long as the megaclock is stable ( is always is unlike the number of interrupts per rotation which varied much more ) and the sensor is stable..mine isnt and Ive seen many that werent. At any rate, its pretty good to about 10-15% variance on most systems but other influences can throw off the statistics and make the thread wander higher and higher over time. This is why the wandering thread pitch as you go further out. Mach3 cannot speed up from original speed, but can easily slow and speed back up to normal speed. Testign shows this works but we're simply trying to make it better.

The system knows that after so many rotations, we shoudl be in such and such a position and simply tries to get there bassed on the number of ratoations seen, current position, and speed.

There will always be a limitation based on the fact we arent real-time though.
Art

I'll address this to Art and Rich both as combining the info implies that the effort is aimed, at least somewhat, at marginally powered hobby lathes. Correct me if that is not the case.

Thank you, ART for the explanation of the function. This is quite a fascinating topic. I see that the new method for measuring is more accurate perhaps, and even if the 'bell curve' could be considered a prediction of sorts, the problem remains that it is after the fact and only once per revolution. And there are additional factors conspiring against the perfect thread.

Measuring the period of a full revolution injects another assumption into the equation. Not only must you assume that slowdown will be statistically similar for the next revolution, with only one pulse per rev, you also must assume that the slowdown is consistent over the entire revolution. I think that is unlikely, especially if the tool entry azimuth does not coincide closely with the pulse azimuth.

For example, if the tool enters at 180 degrees relative to the pulse, your measured revolution will 'see' only half of the slowdown, and therefor misadjust by 50% the needed correction for the next full revolution, and will consider the increase in the subsequent time period as a further slowdown and misadjust again, followed by another change in period, and so on . . . . . if I am thinking correctly.  Additionally, it is my impression that forum members here (as well as the available wizards, perhaps?) do single point by a simple plunge with equal depth of cut for each pass. If that is correct, then each pass will require more power and there will be a corresponding increase in the slowdown from pass to pass. This presents a vexing problem that there is no solution for so long as a single pulse per rev is used.

This brings up an interesting question of harmonics . .  if you will. It is possible that the 'oscillation' in speed correction described above could be self exciting? That would explain the escalation of the error as the thread becomes longer . . as has been described here and there.  I have not followed this closely so I'm shooting from the hip here.  I have not thought this through at all . . just a mad thought. 

Threading solutions for the 'stab-in-the-dark' department:

Here are just some thoughts that occurred to me in noodling over the MACH single point threading challenge. These ideas may or may not improve success, (my dime says they will), but they cannot do any harm and are free to try. Hopefully they will prove useful:

1) arrange for the tool entry point to be as close the the index pulse as possible.

2) use a more sophisticated threading technique that will even out the load from one pass to the next.
       Alter the G-code to cut only one side of the thread and reduce the feed (or depth of cut if messing with feed confuses the adjustment algorithm) such that as successive cuts take more 'height' of the the thread, a  corresponding reduction in depth or feed equalized (within reason) the power required for the cut.

3) use a motor speed controller based on PWM rather that SRC and use one that has good compensation for slowdown. I am using a Minarik drive which has an adjustment for that and does a very good job trying to maintain set speed. Certainly there are others that also work well.



If MACH has less total change and less delta throughout the cut, then as the function was described to me, it *should* be able to zero in on an optimal correction sooner and maintain the correction thru successive passes.

Simpson:

   I do believe the oscillations of the vfd autocorrections have an effect. But its all more accurate than youd think. Firstly, I keep a rather large
64 bit counter of the actual times involved and keep track of remainders.. While errors can be created by entering the material offset from the actual index pulse, those errors
self correct from rotation to rotation. The way the math works it keeps in in as good a track as possible, but the vfd can negate some of the safety there. I suspect its better
not to have a correcting vfd personally.

  Consider a 5 rotation thread, with some fake numbers..

We have planned the motion and filled the output buffer with 1mm ( 2000 steps) per rotation. We start with the trigger.

Unit triggers on index, motion begins...Counters are zero'ed.. static measurement of one spindle rotation of say 26000000 nanoseconds per rotation is now locked in as base. This
is being measured all the time as the unit waits for the index trigger prior to threading..

So motion begins and we wait for next index.
Index hits.



When index pulse hits, we look to the number of nanoseconds passed. Say its 28000000 nanoseconds.

We now subtract 26000000 from the counter, leaving 2000000. We now slow the motion by 7.6% over the next
rotation, but its done by a bresenham division algorithm that keeps track of the remainders, so that each rotation can help
correct for overcorrection on a previous rotation. Each rotation is linked that way to the entire thread. Think of it this way..

I--------I--------I--------I-------I

Before the thread is even started, Mach3 knows that a certain number of total pulses should have come out by the time each "I"
in the above line is encountered, ( "I" being an index pulse). By counting the pulses and the position of the index pulses
we can calucate exactly how many steps short we are ( or over ) at each index pulse. The correction therefore is not based on the last rotation, but on the total number of rotations and the total number of pulses that should have gone out. SO while one rotation may
contain an erronous slowdown due to tool entry etc.. the actual correction on the next rotation will take that into account
as a sum total of the entire thread. The numbers will then always be pretty correctable UNLESS the spindle speeds up in its correction
to make it impossible for mach3 to catch up, as it cannot speed up anymore than the planned speed of 1mm per rotation.

  In theory, this is of a high enough order of correction that added corectional steps would have little influence. The trick is
not to look at each rotation time as the correction for the next rotation, but for each rotation time to add to the whole
and be used to correct for position that far into tthe thread it has reached. Keeping track of raminders allows this to be very robust.

   Ill be testing over the next few weeks and will update the dialogs to show expected vs real poition and the correction applied as a result.

Thx
Art