I remember one (least some part of) Norvegian team that was trying to make FORTH-processor for graphics application, bit slices were driven out of everything else than esoteric radar and such signal cruching. And finally out of that too with when signal processors started to appear. With PC:s I lost all interest on computers. Just too many layers of junk.

Okay looking back at he old spreadsheet I see I kind of lucked out on the new lathe. I just this week made a set of pulleys for it and I coincidentally gave them an exact 5 to 1 ratio. I did that at the time mainly because 18T and 90T were good do-able numbers for indexing on my old spin collet, and I lack a dividing head. And because 5 to 1 was in the range of a good reduction ratio for the specs of the treadmill motor I had. To have both of those things work out to exactly 5 to 1 was true dumb luck for me.

Why? Because I hadn't looked at this old electronic lead screw thread. And looking at it now I'm reminded that 5 to 1 is THE absolutely ideal ratio to make this work. Because what it means is that I can attach the 600 line encoder I already have directly to the DC motor and that gives me 3000 lines per rotation at the spindle. The DC motor has an extension shaft on the back end, for very easy attachment.

Looking at the lead screw, the ratio of the stepper motor and lead screw will be 1.5 to 1, that means (with a 200 step motor) the 300 steps per lead screw rotation on a 10 TPI screw yields 3000 steps per inch, super-convenient for the 3000 pulse per turn signal from the spindle.

And that means that simple integer division by the intended TPI will yield the proper pulse rate for the stepper to produce that TPI. Divide encoder pulses by 4, you get a 4 TPI screw. Divide by 28, you get a 28 TPI screw. etc.

This doesn't even require an Arduino to accomplish. It can be done with perhaps two discreet IC's. Maybe something in the 74LS161 series chained ( I have some). I think that's going to be my approach. If that doesn't work I can always fall back on the programmed Arduino I had already developed 3 years ago in this thread. But even an SBC is overkill, oversized, and slow and complicated by comparison.

Actually even one modern IC might work -- I don't know what's available these days. Basically I need a divide by N circuit with a max divisor of say 56 (for 56 TPI, or fine feed).

And that means that simple integer division by the intended TPI will yield the proper pulse rate for the stepper to produce that TPI. Divide encoder pulses by 4, you get a 4 TPI screw. Divide by 28, you get a 28 TPI screw. etc.

Well, rowbare, I know it's a little difficult to visualize at first, but think about it, and I think you'll get it...they just carry, as long as the thread continues. If you were doing only one turn, yes you'd have a remainder at the end of that turn, but this is a continuous process. In other words, the pulses don't have to line up with the end of each turn. It's just two different frequencies superimposed -- the spindle rotations, and the stepper pulses. Does that make sense?

If you look at it as superimposed frequencies, there has to be a harmonic relationship between them.

Given a 32 tpi thread (32 shows a bigger error than 28) and 3000 ppr, if the cutter has not moved exactly 1/32 of an inch after 3000 pulses, the thread pitch is off.

3000/32 = 93.75, so a divide by n will provide 93 pulses to the stepper per revolution. After 32 revolutions, the stepper will have gotten 32 * 93 = 2976 pulses and will have moved 0.992 inches cutting a 32.25 tpi thread. It isn't a huge error but an error just the same. It is certainly more significant in theory than in practice though...

3000/32 = 93.75, so a divide by n will provide 93 pulses to the stepper per revolution. .

Nope, it will provide 93 pulses, plus the .75 remainder as a "virtual" timing interval, because the spindle won't have to travel more that 1/4 of its normal inter-pulse distance before sending the next pulse, #94 to the stepper. The encoder has already moved that .75 amount.

See, the encoder doesn't reset once it gets to 93 which is what you're imagining. It's moved past that point just short of the next pulse position. The stepper just sees a continuous regular stream of pulses from the encoder. And those are timed exactly right.

Get it?

The only error is the fineness of resolution of the stepper. But there is no cumulative error from remaindering.

With a perfect leadscrew and a 3000 ppi stepper ratio the tolerance is a flat .00033" at any point along the full travel of the lathe.

If you want metric it could be done the same way, but naturally you'd probably want a metric leadscrew anyway, and then you'd work the pulley and encoder ratios the same way but favoring your measurement flavor.

If you want both yeah you could go the microprocessor route. Been there done that earlier in the thread.

If I thought about it hard, I bet I could do it simply with IC's as well. 8 bits (two ls161s) gets you divisors up to 255. And 254 is an interesting number for system conversions. But I don't want to think hard about it right now.

Fair enough assink. But I should explain what I love - I guess you'd call it elegance in conservation of resources. So I'm real happy with ditching the microprocessor-display-multifunction approach and thinking through a pennies on the dollar four component control solution that will cut any integer thread up to 255 tpi with no cumulative error. I think of that as my kind of fun. And that's what drives me to make my kinds of things and post them on this very unique forum.