Electronic leadscrew on a big boy lathe

I have the need to cut metric threads on my older inch engine lathes on a regular basis. I know that compound gearing is the way it's done. I've looked at what it will take to setup one or both of my lathes. The time, the expense and then the cost of the time to constantly change back and forth seems like it would be smarter to just sell the lathes I have and buy machines that cut inch and metric.

Both my lathes have a lever to quickly de-couple the feedboxes from the spindle. Both have room for a fair size 3KWish servo to mount inside the geartrain cover. A friend/biz partner already has a generic touchscreen GUI that he uses for industrial process control that could work for an electronic leadscrew controller.

I'm really thinking about doing it. I don't want to CNC my manual lathes. I have CNC lathes. What I want is just to cut metric pitches with an inch lathe. And without a bunch of BS. Like same amount of time to setup to cut metric threads as it takes to setup the feedbox for inch threads now.

I'm thinking a prox switch on the feed box disconnect lever that disables the servo whenever the gearbox is physically connected to the spindle. The unpowered servo can just spin all the time, but can only be powered when the feedbox is not physically geared to the spindle.

Without adding a bunch of fluff, can anyone think of features that could be incorporated to make metric threading gooder? Like a "rewind" or return to start feature so there would be no need to reverse the spindle?

Is there any way it could be setup so the half nut could be used? Kind of like the "rewind" idea, but instead you setup a carriage stop and engage the half nut at the same bed location into a stopped leadscrew?

You have answered your own question. It does not work. If it was economically possible, it would have already been done. If you have enough demand, buy a metric lathe. It would be much less expensive than reinventing the wheel.

It's not cost. Its dork proofing that stopped electronic leadscrews being used as factory devices on manual lathes.

Gearboxes are positive and do what it says on the label. If you don't think what you are doing an ELS system can dump you right in the kitty litter.

Dork proofing isn't too hard but the big makers just couldn't be arsed.

Big assed stepper, a couple of sensors in the spindle drive for registration and speed syncing, a dual phase lock loop and switched divider chain to the stepper drive would do just fine.

Made a system like that for the sensor head of a very cheap IR homing TGSM proposal back in the late 1970's which worked just fine to keep the rotating scanner in sync with the missile body over a wide speed range. That particular thing was roll to pitch with a bang / half bang control, half frame scanner so two scanner rotations to see the whole field of view. Gyros and proper controls were too expensive. Started out hanging from a parachute and swinging in a conical arc to give a wider scan then accelerated way when dropped so both roll rate and airspeed changed considerably as it flew. Oh and the thing was never looking at its target when the control fins moved. £100 for the whole head, sensor and control system!

If that worked an ELS system will be no trouble. Around about year 2000 the penny dropped that I could have done ELS right back then.

I imagine one of those Raspberry Pi et al uber cheap micro thingies would be well up to making one run now. Forget the touch screen. Big assed knob(s)and switches are more shop friendly. You can see what you have set. Servo drive and sync is too much hassle. Decent stepper, reasonably geared down won't loose steps.

Have to leave the nuts engaged all the time and run back. Fast return button. You will need switches to define the end-stop positions to start and finish. Clamp on be or maybe super-magnet will do.

Easy enough but not apprentice proof!

Clive

A Raspberry Pi is not a great real time controller, at least out of the box. The problem is the Linux operating system which is not an embedded OS. AFAIK there is no way to force scheduling so it makes it back to the task at hand when it needs to get there. It is pretty fast, so it may work, or it may not.

An initial consideration for me would be the parts being threaded...if they are production parts that are worth a few bucks in material, that's one thing. But if scrapping a part is expensive, or they are one-off parts, I'd be very dis-inclined to even try it. Gears have a wonderful attribute - they are very stupid. Today's 'smart' machinery is too smart for its own good.

mnl said:

A Raspberry Pi is not a great real time controller, at least out of the box. The problem is the Linux operating system which is not an embedded OS. AFAIK there is no way to force scheduling so it makes it back to the task at hand when it needs to get there. It is pretty fast, so it may work, or it may not.

Click to expand...

Definitely not true- Linux is a quite good realtime controller OS <IF> the software doing the control is written appropriately; meaning latency, scheduling, I/O is handled efficiently. We do that stuff all the time- the typically fast cpu clocks on modern cpu's afford quite a bit more flexibility and headroom and multicore processors can really open up the solution space. On slower or more resource constrained systems something like RTEMS or vxWorks is often preferable.

Can't see there would be any great problem with a relatively low speed system like an ELS whatever small processor is used. Maybe you'd do best simply deriving the motor clock speed from the processor rather than trying to generate the actual drive pulses. An off the shelf motor driver probably only wants to see clock anyway.

I wrote a driver for a scanning instrument system in LabVIEW that integrated on the fly measurements with motion control for a range of speeds and measurement strategies with no motor speed or synchronisation issues. I imagine that would be much slower on the computational side than any Raspberry Pi or whatever.

Obviously I'd do it in hardware with a stack of CMOS dividers 'cos I've pretty much done it before. Just have to remember why I needed a dual phase lock loop to make it work. Unfortunately the circuit was lost years back.

Clive

I guessing you have seen this, but in the event that you have not. Babin Machine makes an ELS for HLV's

Babin Machine servo threading for HLV and new TML-5Cst lathe - YouTube

Some of the HLV clones are available with ELS now. You might be able to source the control and provide your own stepper/servo and encoder: Toolroom Lathes – Eisen Machinery Inc

If you want to make your own ELS go to Home Model Engine Machinist Forum and you will find everything you need to
know on the subject. There is lot of info on youtube on ELS,
If you have the money have a look at a german ELS by Rocketronics . I think the basic unit starts at 250.00 EURO.

You need sub-millisecond latency for ELS, is that really ok with Linux ?

We do it all the time on Linux using moderate spec 2012 vintage systems. Sub-millisecond sleeps and accurate measurement of elapsed time is very achievable, as is stable realtime scheduling. We're doing multi-gig realtime UDP/IP over 10g ethernet, through the IP stack- timing is open loop because the devices we're feeding have very limited buffering so the Linux end has to be very precise with packet timing and inter-packet gaps.

Though Linux process context is quite a bit larger than that seen on vxWorks/RTEMS but the faster cpu's push that overhead into the noise. I wouldn't hesitate to use Linux with a suitable I/O card for realtime servo control, though I wouldn't bother with a Pi- probably something like a NuC- those things are <fast> these days.

Greg, I used google translate on your reply, I think it translated it to fortran, I’m joking, I wish I had some of what you have, I now feel like a Neanderthal
Anyhow can something like a Siemens S7 or whatever or a mitsibushi FX operate fast enough to operate a leadscrew servo?
Mark

mnl said:

A Raspberry Pi is not a great real time controller, at least out of the box. The problem is the Linux operating system which is not an embedded OS. AFAIK there is no way to force scheduling so it makes it back to the task at hand when it needs to get there. It is pretty fast, so it may work, or it may not.

Click to expand...

Raspberry Pi is a hardware platform primarily even if most people use it with Linux. Yes, standard Linux kernel isn't tuned for realtime, but you can either customize it yourself, or get somebody's build if you don't know how. LinuxCNC is one good example where Linux is used with RT_PREEEMT and does an adequate job for machining purposes. Now you also aren't really required to run Linux - Pi is just a marketed Arm platform, and will run any other OS tailored for it, including purpose RTOSes.

Greg Menke said:

Definitely not true- Linux is a quite good realtime controller OS <IF> the software doing the control is written appropriately; meaning latency, scheduling, I/O is handled efficiently. We do that stuff all the time- the typically fast cpu clocks on modern cpu's afford quite a bit more flexibility and headroom and multicore processors can really open up the solution space. On slower or more resource constrained systems something like RTEMS or vxWorks is often preferable.

Click to expand...

One of the challenges for realtime is I/O, like you pointed out. On modern PCs there are typically no built-in low latency I/O buses that can be used for machine controls - everything is USB, so it's an indirect challenge for using Linux in such applications. LinuxCNC requires either a parallel printer port or some specialized bus to run. On Pi GPIO should provide adequate low-latency I/O hookup.

Clough42 on youtube has one of the most recent implementation of electronic leadscrew. I followed some of the early videos in the series. I believe he sells a kit now. Check it out for yourself.


Good luck

Jacques

crickets said:

One of the challenges for realtime is I/O, like you pointed out. On modern PCs there are typically no built-in low latency I/O buses that can be used for machine controls - everything is USB, so it's an indirect challenge for using Linux in such applications. LinuxCNC requires either a parallel printer port or some specialized bus to run. On Pi GPIO should provide adequate low-latency I/O hookup.

Click to expand...

PCI or CompactPCI busses are available in most every PC and are an excellent way to connect I/O boards of arbitrary scale. OTOH if you want to do it on the cheap and don't mind the tradeoffs then Pi GPIO are certainly a viable approach.

jariou said:

Clough42 on youtube has one of the most recent implementation of electronic leadscrew. I followed some of the early videos in the series. I believe he sells a kit now. Check it out for yourself.

Good luck

Jacques

Click to expand...

Yes, James has parts for the whole project available now. At least he did when I got mine. Excellent project, if you like messing around. Definitely not a turn-key setup.

crickets said:

Raspberry Pi is a hardware platform primarily even if most people use it with Linux. Yes, standard Linux kernel isn't tuned for realtime, but you can either customize it yourself, or get somebody's build if you don't know how. LinuxCNC is one good example where Linux is used with RT_PREEEMT and does an adequate job for machining purposes. Now you also aren't really required to run Linux - Pi is just a marketed Arm platform, and will run any other OS tailored for it, including purpose RTOSes.

Click to expand...

Sorry but what does "not tuned for realtime" mean, ie what measurements and what criteria. I have used Linux kernels patched for realtime before, which does gain a bit by reducing scheduling jitter somewhat, at the cost of proprietary patches to the kernel. A conventional kernel, using realtime scheduling, will provide suprisingly good realtime performance. We do just fine with control loops running over 1000hz, with a cpu upgrade we could likely push close to 10khz. Linux wins big here if you have to move a lot of data; multi-core processors, DMA support and MMU are a big assist.

Generally the biggest impediment to stable realtime performance is application layer design & implementation- which applies to classic RTOS's as well.

OTOH if the question is a realtime system running on a 100hz PPC, then I'd go RTEMS or if I had no other choice, vxWorks- Linux process overhead starts to be significant down at that clock regime.

Greg Menke said:

Sorry but what does "not tuned for realtime" mean, ie what measurements and what criteria. I have used Linux kernels patched for realtime before, which does gain a bit by reducing scheduling jitter somewhat, at the cost of proprietary patches to the kernel. A conventional kernel, using realtime scheduling, will provide suprisingly good realtime performance. We do just fine with control loops running over 1000hz, with a cpu upgrade we could likely push close to 10khz. Linux wins big here if you have to move a lot of data; multi-core processors, DMA support and MMU are a big assist.

Generally the biggest impediment to stable realtime performance is application layer design & implementation- which applies to classic RTOS's as well.

OTOH if the question is a realtime system running on a 100hz PPC, then I'd go RTEMS or if I had no other choice, vxWorks- Linux process overhead starts to be significant down at that clock regime.

Click to expand...

Yes, patched. Not everyone here deals with that kind of stuff, so dumbing down the terminology helps to get the point across. You are spot on otherwise