Electronic Leadscrew for the New Lathe

[S. Heslop]

Image from lathes.co.uk http://www.lathes.co.uk/boxford/page2.html



The leadscrew itself has the spline in it, instead of it being a leadscrew and a separate splined shaft for the autofeed.

Can't quite see how it's all connected in this image though. But the worm reduction would probably help bring threading leadscrew speeds down to something slower for autofeed, and at least save the need of switching gears back and forth except for when you need to cut threads.

There's alot of popular videos on the topic of worm hobbing using taps, and it looks like it works fairly well (even though I've only seen one video where the guy bothered to include a scene of the thing actually meshing with a worm).

[Fergus OMore]

Again, might I suggest that you look at the Pools Major? OK, the first lot of pictures are pretty basic- perhaps a dog clutch but follow on until you look at the tailstock stock end and see what appears to be something different. Then you see a non- threaded leadscrew.

I'l let you enjoy the rest but with a bit of fiddling with the feed screw dials, you get some interesting developments- which I haven't seen later.

Enjoy- it's different

Norman

[Manxmodder]

Simon, the free hobbing process works best with a spiral flute tap,certainly when small diameter taps are being used.....OZ.

[vtsteam]

Simon, thanks, so you were just mentioning a way to separate functions of autofeed and threading without using two leadscrews. That's the part I didn't quite get. What the purpose was. (btw, the Craftsman also has a single, grooved leadscrew.)

Well, looking at that drawing, it may be interesting as a historical mechanism, but two leadscrews and/or making a single grooved leadscrew plus a lot of complexity in the apron isn't something I'll be doing on my own lathe. There won't be any gears in the apron, and no rack and pinion either. The only thing in the apron will be a half nut, and if I go with chase threading, a clamp for the pushrod, as outlined earlier.

To me, complex apron gearing makes sense for large lathes with very heavy carriages and long traverses, but for something like a 9x12 lathe it doesn't serve a purpose. On the Gingery, I release the half nut and slide the carriage toward the headstock instantly to position it. It's a lot faster than cranking the carriage handwheel on the craftsman.

For hand feed on the Gingery, you close the half nut and use the crank at the tailstock end of the leadscrew. It's a lot finer control than the rack and pinion on the Craftsman apron.

For autofeed on the Gingery you slip a round belt onto the leadscrew pulley at the headstock end, and the leadscrew turns. Very simple and straightforward. The Craftsman is cumbersome on all counts by comparison.

[Will_D]

May I suggest that first we set down some requirements:

1. Cut threads accurately and quickly

2. Use fine feeds both longitudeanly (and cross slide (if supported)) to quickly machine some parts.


Req 1:

Requirement 1 can be satisfied by simple (conventional) gear trains and the leadscrew and the TDI as implemented on most lathes
or
A pseudo cnc system as mentioned in this thread that picks off headstock rotation and converts this into a digital input to software that then ouputs control signals to leadscrew stepper motor drive.

Consider this:

Thread cutting is a slow process. To set up the gear train on a conventional lathe may take 5 minutes or less. To cut the thread can take 30 minutes. That's for imperial threads on an imperial lathe (Longer for Imp on Metric)

So on balance I would favour the traditional aproach!


Req 2:

Requirement 2 can be satisfied by simple gear trains and the leadscrew or by applying a separate digital/cnc feed to the lead screw.

On my ML7 I have just one FF available using the gears and lead screw.

Using a simple digital lead-screw drive would give infinite feed rates. Just think of a controllable rechargeable drill applied to the leadscrew hand wheel on a ML7

BTW: Guess what I am working on!

[vtsteam]

Will I truly appreciate your organizational bent, but the requirements were set out early on:

1.) Get away from conventional change gears 

And by golly Will, if you can cruise to a thread gear setup from a feed on my Craftsman 12 x 36 in 5 minutes time my hat is definitely off to you!

I'm no better than Martin Cleeve with my own lathe, who says changing, and then threading a half inch long part, and then changing back killed an evening of his, and why he designed his gearbox.

Maybe different lathes vary this way. Certainly people do! 

[Manxmodder]

Steve, the quest for a reliable electronic screw drive is,I think, very much worth the headache of figuring out a workable scheme. Maybe you'll go that route right now,or perhaps the idea needs time to evolve a bit more and you can upgrade to a full e system later.

  Earlier on I think you touched on the possibility of toothed belt and pulley drives. These are worthy of further consideration as they are relatively cheap to purchase,light to handle,clean due to no grease  and fairly straight forward to make your own pulleys from casting and milling.

I certainly like the idea of belts from the practicality viewpoint.

Agree also that not all lathe brands are as easy to change back gears on,and can understand why it makes some reluctant to get involved in the process when it takes up so much time.....OZ.

[vtsteam]

Is it at all possible to skip software entirely with a stepper motor?

Put an encoder disk on the spindle that directly generates the signals needed by the stepper motor driver -- step and direction?

By varying the disks, couldn't you select different "gear ratios"?

Wouldn't that also deal with the problem of a stalled spindle?

A straight stepper would have 200 steps per revolution -- a belted reduction, a multiple of that. Would it be fine enough to do it?

[vtsteam]

Okay so thinking about this hypothetically:

1.) Say you have a 200 line encoder on the spindle and a 200 step stepper on the lead screw.

2.) The encoder connects (through whatever buffer necessary) to  the STEP pin of the stepper driver.

3.) For the experiment, you connect the Direction pin to a Direction switch., and bring low or high as required

4.) The leadscrew is a 10 tpi pitch.

You rotate the spindle one revolution by hand.
This should rotate the stepper by one revolution.
And the carriage would move 1/10 inch.
If you were cutting a screw you'd get a 10 TPI screw thread.

Now you change out the disk in  the encoder for a 100 line disk.
One revolution of the spindle turns the stepper one half revolution.
The carriage moves 1/20 inch
If you were cutting a screw you'd get a 5 tpi screw thread

And a 400 line encoder would generate a 20 tpi screw.
etc.

But what about threads not integer divisible into 200 steps/rev for the stepper?

If the stepper was reduced 6 to 1, you could get quite a few more factors. Also the fineness of even an aproximation would increase. One step would equal 1/12,000 inch of carriage movement. For a prime pitch -- take 13 tpi, for instance, you'd need a 923 line encoder, and the thread would be accurate to about .00008" in 1"

Another possibility -- increase the encoder speed.

How about putting the encoder on the spindle motor (if DC variable drive type) and you used a timing belt from the spindle motor to the spindle, they would be in sync. The spindle motor might run 6 times the spindle speed. So the encoder would run at that speed. For our 13 TPI example we then need a 154 line encoder instead of 923. Accuracy is a little lower (154 x 6 = 924), but still good enough.

Or you could use the same belt, and spindle pulley, but add another stub spindle for an encoder pulley set to whatever ratio was convenient. You could mix and match encoder pulleys and encoder disks where necessary. This should still be a lot easier (and cleaner) than change gear trains, since it involves only one pulley and no oil.

Encoder disks could also contain multiple line grates, similar to a dividing plate, so several ratios could be on just one encoder disk. You move the sensor out to to the appropriate band to select the ratio.

[vtsteam]

It's possible that encoder disks could be printed out on a printer, if the number of lines was reasonably low, and the disk reasonably large.

An optimum set of pulley ratios for the motor, spindle and ledscrew, with the encoder on the motor might work out very well for homemade encoder disks.

[vtsteam]

Making encoders and quadrature theory:

http://www.societyofrobots.com/sensors_encoder.shtml
http://www.dgkelectronics.com/inkscape-extension-for-creating-optical-rotary-encoder-discs/
https://github.com/Hyvok/Inkscape-rotary-encoder-disk-generator
http://tutorial.cytron.com.my/2012/01/17/quadrature-encoder/

[vtsteam]

Going to bed. Seems like this leadscrew drive would all be easy to test out with equipment i already have -- maybe even on the Gingery as a temporary kludge, except for the sensor for the encoder.... there might even be one of those at the local Radio Shack....

[awemawson]

Steve, gearing up the encoder is definitely workable. On my Traub the main spindle encoder is 1024 slots, but the same encoder is used for 'C axis positioning'  geared up to 90,000 points on the circle !

Fairly obviously you need to avoid any backlash, but the Traub just uses a toothed belt under tension and seems to work !

[RussellT]

Steve

I think that's a brilliant idea.    I wish I'd thought of it.

I've been thinking about it.  Direct drive to the leadscrew at 10tpi would give steps of 0.0005" which I think should be fine for most purposes.  If you need more torque I might think of using the epicyclic gears from an old cordless drill as that would give a compact drive.

A 12tpi leadscrew would give you better solutions for threads like 6,12,24 tpi as well as slightly smaller steps.

As far as your encoder goes the diameter limits the number of steps.  For convenience you will presumably be using an ordinary sized printer which would give a maximum diameter of about 8 inches and a circumference of about 25 inches.  I'd guess that using plain paper and a reflective sensor you could easily use marks about 1/16 apart giving 8 per inch, or 200 per revolution.

I've taken printers apart and they have finer resolutions than this but using a clear disc with a transmitted light sensor.  From the point of view of changing discs it makes sense to have all the hardware on 1 side.

At 200 pulses per spindle revolution the coarsest thread you could cut would be the same as your leadscrew pitch.  That's very close to working without gearing on either spindle or leadscrew.  If you could make your encoder read finer markings then you're almost there.

You could also have multiple sensors across the radius of your disc so you could use switches to select from a number of different threads and fine feeds on a single disc.  Old CDs seem an obvious candidate for discs - diameter is reduced but you could use the centre from a CD case to make changing quick.  You need to get the printed markings down to about 0.01" wide to get a thread of 6tpi from a 12 tpi leadscrew.

I also like the potential for having an electronic disengage when thread cutting.

The difficulty is as always picking up the thread. 

I don't think a single point clutch on the spindle would work because if you wobbled the encoder disc engaging the clutch you could generate a lot of pulses of unknown direction and lose position, and you couldn't disengage the half nuts for a quick return.  If you used a switch to disengage the feed you would lose position too.  I think the simplest way might be to mark a starting position on the encoder disc (if you used gearing to drive it you'd need to mark the spindle too) and return the carriage to a fixed starting point.  Starting with the lathe stationery also takes care of accelerating the leadscrew as pulses are accelerated naturally as the lathe spindle accelerates and reduces the possibility of missing steps.

Russell

[lordedmond]

If you go down the CD route they use to make printers that printed directly on to CD that had a coating on them , don't know if they are stil made though.

Some had a laser in them and burn the info into the disc others used the ink .

Note I do not mean the ones that you print onto a sticky backed paper and put that on the disc that would not be true enough

Stuart

[vtsteam]

Russell I'm going with 10 tpi leadscrew because I still think of this as a manual lathe, and there will be a leadscrew crank with a thousandths dial at the tailstock end, Just like the Gingery. On a 12" leadscrew, 1/2" x 10" acme allthread is available and just right. I'll use the same on the cross slide, etc. I don't care about handedness so it will all be RH thread. Cheap and easy.

I'm thinking a 3x reduction on the spindle motor, which is a treadmill type rated at 6000 RPM. I'll probably put the encoder on the motor. That will give a theoretical max spindle speed above 1000 RPM probably. I'll probably go with a 3 to 1 reducton on the leadscrew.

This combo should give enough resolution for threads down to 4 tpi, and yet keep the encoder disk printing relatively coarse. That could be adjusted either way on both ratios to hit whatever works out to a happy medium. I think there will be a sweet spot balancing thse for this specific lathe/moto/leadscrew -- but might take some experimentation.

BTW the motor comes with a good sized flat faced flywheel, which could serve as an encoder mount. I wasn't going to leave it on, but maybe it would also smooth out cutting as well as hold the encoder, so it's a possibility.

I could use help on choosing a suitable reflective pickup (ideally working with paper and ink, one face) and how to buffer or condition the signal (if necessary) to the step pin of a typical stepper driver.

[vtsteam]

I spent a lot of time today with a spreadsheet I made up to try what-if scenarios for different ratios on the leadscrew/stepper and the encoder/spindle. I used a thread range of 4 to 40 tpi.

My conclusion is, with that large a range your encoder disk needs either too many lines at the low pitches to make easily, or too few lines at the higher pitches for thread accuracy.

You could manage it by changing the reduction ratios for the leadscrew/stepper and spindle/encoder into 3 ranges with three sets of encoder disks, but this starts getting cumbersome.  It's a little better than change gears but not enough, in my opinion to justfy it on my own lathe.

I was only working with simple straight encoding, not quadrature, and that is pretty limited in range for a computer disk printable on a computer printer. That's likely the problem.

The alternative I came up with which would definitely work, and is more electronically conventional, is just use  a single encoder of reasonable resolution, and instead of swapping disks for different pitches, use a divider circuit to generate the pulses to the stepper driver.

Some dip switches to set the pitch would work -- all the thread pitches between 4 and 64 could be set in 5 bits (5 switches) for input Make it 6 switches to include direction. And no screen necessary, since the switches are indicators themselves.

This is approaching what a computer does, but you don't really need a computer, a screen, or keyboard.

 If you do use a single board computer for that, not much of one. It doesn't need a graphical OS, keyboard or even a LED dsplay driver. Basically it just needs to poll the switch state and do the dividing and output the stepper pulse. So I need 6 input lines and two output. Actually, the direction output could just be a switch -- no need to process. So okay, 5 input lines.

Because the pulse triggering is the encoder on the spindle, there is still the protection in case of spindle stall.

You could either make up the divider by discrete IC's or use something like a pic or arduino board.

The one question I have is the ability to do the input, dividing, and output fast enough. The throughput required for say 100 rpm spindle speed and a 1000 pulse per revolution encoder would be about 1.7 khz. Seems like integer math could be used for this to keep it fast.

I might try this -- I don't have the know-how to do it in discrete components, but maybe I could learn enough about Arduino programming to do it with the Uno board I've got.

Basically I'd need a dip switch and an encoder.

From my spreadsheet it looks like a 1000 line encoder run at twice spindle speed, in conjunction with a stepper with 4 to 1 reduction to the leadscrew would give reasonable threading accuracy for the full range of pitches I mentioned.

[sparky961]

The one question I have is the ability to do the input, dividing, and output fast enough. The throughput required for say 100 rpm spindle speed and a 1000 pulse per revolution encoder would be about 1.7 khz. Seems like integer math could be used for this to keep it fast.

I'm running software quadrature decoding of a 4000 count servo encoder using a state machine on a "Teensy 3.0" board ( http://www.pjrc.com/teensy/teensy31.html#specs ).  It uses 2 pins as interrupts to trigger state changes and it's astoundingly fast for what it is.  I've implemented error checking for bad state transitions, so I'm fairly sure I'd know if I were missing pulses.

I added a quick conversion to show RPM in my code and it looks like I'm doing 1750 RPM and still maintaining an accurate count.  This is all in development and yet to be verified, so take everything here with a grain of salt.

Short answer: I think you're alright

[awemawson]

High count Chinese quadrature encoders are amazingly cheap on eBay

[PekkaNF]

You probably know this one allready:
http://www.ni.com/tutorial/7109/en/

Short discussion about creeping count...
http://www.dynapar.com/Technology/Encoder_Basics/Quadrature_Encoders/

What is important here is to note that two channel encoder (quadrature encoder) used as two channel (bidirectional information) and coupled right to counter (hardware or software) produces reliable counting. Too simple signaling could produce few (or sometimes many) erroneous counts when signals are not kept stable, even if they would work in ideal world.

To get big enough disc to lathe spindle and guarding it well (if optical encoder is used) is bit of a problem.

As mentioned before cheapest high count solution would be to use timing belt to "upgear" the encoder, it is used a whole lot in industry. Only few things to check is that encoder axial bearing loading is not exceeded, rpm is not exceeded and pulse count is not exceeded. You even could use "index" pulse for rpm-display.

Pekka

[RussellT]

The sensors are not expensive so you could have more than one along the radius of your encoder, and you could also have an encoder disc on motor or on flywheel which would give you a much greater range of input pulses.

I imagine something like a row of sensors from spindle to motor and a disc that would slip onto the end of the shaft of either facing the row of sensors.  Depending on dimensions the same sensors could be used for either disc position.

Going for electronic division would make it difficult to cut special threads, you never know the metric system might make it to the USA soon.

However you could take care of that if you went for microprocessor/Arduino division.  I would say that you have to stick to integer maths for accuracy.  If you use the Arduino you need to use an interrupt for the input pulses.

I wouldn't want to use dip switches like that.  I think they're fiddly and difficult to see.  I'd go for a row of toggle switch - or if you have visitors to impress some huge steam punk style knife switches.

Russell

[vtsteam]

Sparky that teensy board is really neat!!

Andrew total agreement, that's what I'd use.

Pekka, commercial encoder per Andrew.

Russell special threads no problem, just depends how you implement the switch processing.

A lookup table for division count  per thread switch setting could give any results you care to set up in the table. 6 bits of input  would give 64 threads.

It also relieves the processor from doing division. it can be very fast as an algorithm.

Agorithm:

1.) Poll switch setting byte value,
2.) use that as an index to do a lookup in a table, and store the table value found
3.) Increment a count on receiving encoder pulse (interrupt or polling, whatever suits the board)
4.) Compare the count to the stored value
5.) if the count is equal to the stored value, send step pulse, reset count, loop
6.) else loop

Accuracy:

Example:

With a 3 to 1 stepper to leadscrew ratio, and a 10 tpi leadscrew and a 200 step motor, the movement fineness is 6000 steps per inch of carriage movement. That should be plenty.

With a oommon Ebay 600 line encoder at 5 to 1 spindle ratio the fineness of control is 3000 divisions per revolution. The worst rounding error would be in the higher pitches that weren't factors. Let's say 39 tpi was desired for some reason (40 is a factor). The error would be about 0.1% of pitch.  Some odball fractional pitch around this fineness of thread could be as bad as 0.7% off. That's theoretical worst case. And coarser threads are better. Oddball fractional pitches around 20 tpi would have a max error of half that. And many common thread pitches are factors.

You could use a finer encoder if this error level was a bother, or you could step up the encoder ratio further -- I don't think it will matter to me on my lathe with its overall tolerances in general. However increasing the pulses per spindle rev increases the noise and calculation speed requirements. I'm not sure that it's worth going further on my lathe.

Another possibility for dealing with rounding errors would be to round down, but accumulate errors in the algorithm, add them, and increment the encoder pulse count when they exceed 1.

I did think about toggle switches for input, and maybe I'd do that later after first going with a dip switch to get things moving. Plus I like the idea I could hide a dip switch more easily.

Ideally a rotary switch with a big metal knob would be a great "old school" solution to fit a traditional looking lathe, I think. You'd have to make one with a PC board and wipers, but it could be done as a later project in itself!

Thank you all for your replies!

[DMIOM]

Steve,

Even if you don't buy any of their products, I'd recommend having a look at the US Digital website - they're one of the leading manufacturers, and I've used their products for quite a few applications over the year.

I can't see it on their website at present, but they even used to make a tiny device called an "eDivide" which had a bank of DIP-switches to set the ratio. I've used those for prototyping and then produced small-runs using PIC controllers.

You mentioned using the likes of an Arduino - I'm not sure if one would keep up reliably, but a PIC programmed in C should certainly cope. I've made a couple of slip-detectors using encoders & PICs - one had sensors either side of a clutch on a shaft running at just over 5,000 rpm; the other was similar but across a whole transmission, so as well as the two encoders, there were also a number of pins used to signal the gear in use to the PIC, so the dividing ratio could be set appropriately. One of the tricks was to use the hardware counters built into the micro, minimising the arithmetic overhead.

Dave

Edit: here's a very simple diagram, using their own stepper driver - just add the variable divider betwixt the encoder & driver....

[RussellT]

It sounds as though you're going to end up doing the programming you were trying to avoid.

I suggest amending your outline as follows.

5.) if the count is equal or greater than the stored value, send step pulse, deduct stored value from count
6.)loop

You might be able to improve accuracy by multiplying the count by 10 or 100 - that way you could get a couple more significant digits on your stored value and by using the subtraction method I've just suggested the extra pulses would be added in whenever they were needed.  That still allows you to use integer maths which avoids the extra processor load and any possible inaccuracy from rounding errors.  It wouldn't be as good as increasing the input count.

Russell

[vtsteam]

Thanks Dave, that's a very useful site!  And that diagram with divider you mention is what I was thinking of. I do have a different stepper driver, but similar.

re. PIC: I don't know C.    Too bad there isn't a board for FORTH, I know that! 

Russell, yes to getting away from programming, but seems necessary -- the error from the disc encoder bands method seems too great. I don't think the programming is too big an issue. As long as I avoid feature creep!

Yes, sounds like a good suggestion re. reducing error.

Here's my spreadsheet for others to play around with. You can see the effects of changing reduction ratios, leadscrew TPI, encoder gratings, etc. and it will give error rates, disk band size, thread TPI etc.

edit:

I've removed the spreadsheet attachment here because it needed revision -- the latest version (v1.2) is on page 4 of this thread.....