Is LinuxCNC the right tool for the job?

The beauty of LinuxCNC is you can do almost anything you can think of.

Here is a simple example of a stepper winder done in HAL alone.

gnipsel.com/linuxcnc/index.html

To thread you need spindle feedback usually an encoder with index is used with a 1:1 ratio with the spindle.

LinuxCNC is the right tool for CNC... trivial or not just depends on you.

JT

So your proposing disconnecting the threading screw and putting a stepper or servo drive on it and using the 1/2 nut to thread manually with the speed of the lead screw electronically geared to the spindle?

JT

eremius wrote:

Does LCNC support some sort of sensor which can monitor the speed of the chuck and adjust the speed of the leadscrew accordingly? Is this a relatively trivial task?

A full CNC conversion of a lathe with LinuxCNC is a well-trodden path, and is fairly straightforward.

LinuxCNC requires a sensor on the spindle for threading, this can be done in a number of ways. It should have at least a single pulse per rev, and ideally both a single index pulse per rev and a number of extra pulses on a separate channel for more fidelity, and better stil is 2 more channels of extra pulses to give position and direction (then you can do tapping with a tap in the toolpost).
There are a number of ways to do this, including connecting something like: www.ebay.co.uk/itm/40mm-Outer-Diameter-I...ncoder-/281099904847 in a 1:1 ratio with the spindle using gears or a belt (running from the existing back-gear stud is an option), or fitting gear-tooth sensors that detect the spindle bull-gear ( www.ebay.co.uk/itm/2pcs-ATS667LSGTN-T-Ge...sor-IC-/151026083886 )

With a full CNC conversion the computer retracts the cutter at the end of the thread, reverse the leadscrew, returns to the start and makes the next cut.


It can't do this with just a single controlled axis, and I am very curious how the other systems work. The issue is that if you disengage the leadscrew in the usual way at the end of the cut, then return the carriage, then re-engage the screw, the controller has no idea at all where on the screw you re-engaged the nut.

One way round this is to use the encoder / stepper purely as electronic gearing. Then you need to use the thread-counting dial in exactly the normal way. But there is a problem there, as the normal way does not allow you to disengage the nut when the ratio of screw pitch to leadscrew pitch is non-integer. So, you don't gain the advantage of being able to trivially switch between metric and imperial.

If you have a bidirectional encoder then you can still do what is normally done in this situation, you can leave the nut engaged, stop the spindle. reverse the spindle, wind the carriage backwards and then start the next cut.

If you motorise the power shaft then you can dial in infinitely variable feed-per-rev with the leadscrew disengaged too, to save leadscrew wear.

The simple electronic gearing can be done purely in HAL, no need for a GUI and the Beagle Bone Black might be an appropriate platform. It is actually pretty trivial to do this with an Arduino too.
One interesting question is how you inform the system, what gear ratio you require. A monitor, keyboard and mouse seem excessive for that. One thing that might work might be a binary coded switch. 3 digits would use up 12 IO pins, and then a second pin would select TPI or mm pitch. (so 175 would be either 1.75mm pitch or 175 TPI). Adding on the requirement for 3 channels for the encoder and 2 outputs for the stepper drive puts you outside what an Aduino Uno can do, so you might have to look at the Tre, at which point the Beagle Bone is about the same price, and LinuxCNC + HAL is an option. The Arduino might well be simpler, however. The Arduino can't later become a full-CNC LinuxCNC host though.

So, whilst what you want to do is simple, it isn't common enough for there to be a well-trodden path for you to follow. If you wanted to add a motor to the cross-slide too, and go full-CNC then it bizarrely becomes much more common, and existing configurations can be used.

On a lathe you often don't need G-code, there are a number of setups out there where you type in diameters and feeds on simple turning / boring / facing operations and leave the machine to it, like a double-axis power feed. You can make most one-off components pretty efficiently that way. This is the setup I use, but there are others: www.linuxcnc.org/index.php/english/forum...s/26550-lathe-macros

eremius wrote:

So which of these would be the better choice? I can see the first one being able to detect reversals of the head but am not sure if the second one would as well. If so, the gear tooth sensor seems like it would be the better option for me.

The encoder is a 3-channel quadrature encoder. It will give 400 pulses per rev quadrature + index.
The gear tooth encoder will give as many pulses as there are teeth on the pulley, and with three sensors will give the same three channels (you would need to find a keyway or lump on the spindle shaft for the index pulse.

The disadvantage of the encoder is that it doesn't have a hole in the middle, so isn't trivial to mount to the spindle. You need a gear, and it needs to be the right gear too.
Depending on the hardware you choose the proper encoder might produce too many pulses per second to count at higher spindle speeds. For example a parallel port can count at about 20kHz, with a software encoder. That looks like you might be OK to 3000rpm (unless the encoder is 400 slots, and this 1200 counts, in which case it is 750rpm. That's still pretty quick for threading though.

The gear tooth sensors are more expensive than the encoder (astonishingly) and might need some interfacing electronics to connect to your hardware (Though I have connected them directly to a Mesa IO card, so probably not).