re;Re: Threading

Dave,

I Don't see the problem.


<snip>threading algorithm right now for my next software rev, and

>it's not a particularly simple problem.
>Three conditions have to be satisfied:
>- Slewing of axis in appropriate ratio to spindle speed, at any
>speed.

This is taken care of by the divide by N.

>- Mark registration for multiple passes to align correctly.

This is handled by the "index" pulse. If not available from the
encoder, it is easily implemented with an add-on hall effect(or
optical interruptor) switch.

>- "Look ahead" to stay within acceleration limits for the axis.

This is a function of spindle speed, and since the TOTAL pulses
received from the encoder MUST exceed the output pulses needed for
the stepper(with a divide by N setup), the spindle speed can be set
to allow threading.(within the stepper/servo axis capabilities)

>Tough nut to crack, especially if there's no index pulse on the
>spindle encoder, or if the encoder can have any arbitrary number of
>slots from one up! Think I've got it figured out though...

Yes, without these constraints it WOULD be a tough problem...


This problem is VERY similar to the one EMC has had with the
dispensing of stepper pulses. (somewhat solved by Fred with freqmod).
It WILL be helped by higher spindle encoder counts (per revolution).
And the "higher math" Fred used could be implemented in a threader
routine with good success,IMO.

Here's how someone else licked the problem:

The microkinetics routine to handle this is called isThreader and is
called with the syntax(4 motors slaved are possible with this
routine. "straight" threads only need ONE, tapered threads TWO):

Call isThreader (M1,M2,M3,M4,pulses,offset,exitcode)

Where M1-4 are long integers(a computer term meaning whole number up
to plus or minus 2 to the 32nd; about 2.1 billion,plus or minus.)
which is the number of steps to take for each axis.

pulses and offset are plain Int's(whole numbers, as above,,smaller
range, up to about 65K)

Pulses is the TOTAL encoder counts (also a long int) which will be
received DURING the threading move.

And offset is the number of encoder counts to wait(after the index
pulse) until beginning the "divide by" interpolated move. This lets
the axis "re-start" in the same spot for the next pass. Also can be
used for multi-start threads.

The exitcode is a number returned by the routine to let us know "how
things went" during the move. (limit switch(es) hit,encoder errors ,
finished OK, etc.

Hope this helps.

Ballendo

P.S. I believe my reprint (of the MK routine info above) falls
under "fair use" of the program documentation.