What's new
What's new

Electronic leadscrew on a big boy lathe

Garwood

Diamond
Joined
Oct 10, 2009
Location
Oregon
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?
 

steve-l

Titanium
Joined
Mar 2, 2012
Location
Geilenkirchen, Germany
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.
 

Clive603

Titanium
Joined
Aug 2, 2008
Location
Sussex, England
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
 

mnl

Cast Iron
Joined
Sep 7, 2007
Location
Maryland near DC
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.
 

GregSY

Diamond
Joined
Jan 1, 2005
Location
Houston
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.
 

Greg Menke

Diamond
Joined
Feb 22, 2004
Location
Baltimore, MD, USA
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.

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.
 

Clive603

Titanium
Joined
Aug 2, 2008
Location
Sussex, England
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
 

salzburg

Aluminum
Joined
Apr 14, 2006
Location
vancouver b.c.
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.
 

Greg Menke

Diamond
Joined
Feb 22, 2004
Location
Baltimore, MD, USA
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.
 

boslab

Titanium
Joined
Jan 6, 2007
Location
wales.uk
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
 

Joe Gwinn

Stainless
Joined
Nov 22, 2009
Location
Boston, MA area
Fitting an electronic leadscrew is definitely possible, but it's way more trouble than it looks, and requires considerable electronics fiddling to make reliable - EMI (Electro Magnetic Interference) from the VFD must be suppressed and mitigated and so on.

Anyway, there are a number of groups working on the issue. The two that I follow are <[email protected]> and <[email protected]>. I would join these groups and listen for a while. One can also look around in their archives.
 

crickets

Hot Rolled
Joined
Jul 3, 2021
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.

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.
 

crickets

Hot Rolled
Joined
Jul 3, 2021
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.

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.
 

jariou

Cast Iron
Joined
Jan 20, 2008
Location
Cary, NC
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
 

Greg Menke

Diamond
Joined
Feb 22, 2004
Location
Baltimore, MD, USA
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.

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.
 

Yan Wo

Hot Rolled
Joined
Jan 22, 2014
Location
South Jordan, Utah, USA
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

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.
 

Greg Menke

Diamond
Joined
Feb 22, 2004
Location
Baltimore, MD, USA
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.

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.
 

crickets

Hot Rolled
Joined
Jul 3, 2021
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.

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 :)
 








 
Top