Electronic leadscrew on a big boy lathe

[crickets]

Thanks, this is pushing or exceeding my level of knowledge, especially about how the kernel behaves on a multi core system. Is it necessary to mask off some interrupts or can you force some cores to idle? I vaguely remember some people wanting to use certain cores as monitors for critical execution on a single core, but can’t recall how that came out.

It's possible to set cpu (core) affinity on the process and on the thread (when multi-threaded) level. I actually don't know what the execution would look like if we had a single single-thread process on a multi-core system without explicit call to pin it to the particular cpu, maybe it would always run on cpu0 ? No idea

 

[CalG]

Is LinuxCNC a thing anymore? The ELS has been hashed there for years.

For the past 20 years or more, ELS has been recognized as about as much work as going full numeric control.

A ball screw on the cross feed, and encoder on the spindle, along with unidirectional approach on the carriage takes care of it. Canned cycles and you are off!

 

[crickets]

Is LinuxCNC a thing anymore? The ELS has been hashed there for years.

For the past 20 years or more, ELS has been recognized as about as much work as going full numeric control.

A ball screw on the cross feed, and encoder on the spindle, along with unidirectional approach on the carriage takes care of it. Canned cycles and you are off!

Looks like there was a new release a few months ago, so it's still kicking. I've got a 3 axis system running the version from 2019.

 

[mattthemuppet]

So no ideas for simple features to incorporate?

not sure how feasible this is, but incorporating an adjustable proximity sensor (think bed mounted stop) and some way of doing a quick retract of the threading tool would allow you to program a stop feed + stop spindle -> retract -> rapid carriage reverse to start (2nd proximity stop) -> reverse retract (whatever word that would be).

The retract/ re-engage threading tool could be based along the lines of those quick retract threading tool holders + a small stepper motor.

Just spitballing, no idea how I would do that, but it would allow easy threading to a shoulder and ease the hassle of keeping the half nuts engaged for metric threading.

 

[crickets]

not sure how feasible this is, but incorporating an adjustable proximity sensor (think bed mounted stop) and some way of doing a quick retract of the threading tool would allow you to program a stop feed + stop spindle -> retract -> rapid carriage reverse to start (2nd proximity stop) -> reverse retract (whatever word that would be).

The retract/ re-engage threading tool could be based along the lines of those quick retract threading tool holders + a small stepper motor.

Just spitballing, no idea how I would do that, but it would allow easy threading to a shoulder and ease the hassle of keeping the half nuts engaged for metric threading.

Stopping the spindle adds quite a bit of complexity (i.e. need to cut power but also apply the brake). What you're describing can work relatively well with a sufficient relief without stopping the spindle. Also second stop isn't necessary, it would be easier to add the button to reverse the carriage until released and eyeball it.

 

[SeymourDumore]

THIS... is ALL ...too damned MUCH like "work". Of the "reinvent the wheel, all alone, and in the dark" distraction from payin' the bills and earning-a-crust class.

How many DIFFERENT metric threads.... and what run-lengths?

How HARD could it be to ignore the leadscrew, 'arf-nuts, QCB.. altogether...

And gin-up an Old Skewl, all in the metal, thread-CHASING rig.. that could be mounted on one, two, many, perhaps even ALL of the "Big Boy" lathes.... as needs dictate.

Was going to pipe up, but then you beat me to it......

5 years ago I only knew about them, owned none.
Now, I have 3 geometric and 2 tangential heads to save my ass when needed ( when needed = when the 5 CNC lathes at my disposal just cannot friggin' single point as required )

 

[EPAIII]

The problems with timing of PC serial ports (USB or otherwise) are one good reason for not using them for any time critical application. I worked with a software engineer on a system that needed +/- 8 ms accuracy. He spent the better part of a year trying to make a Windows OS achieve this about 99% of the time. He never did get it to the 100% point.

A PIC or micro controller has direct control over the output pins so this kind of timing accuracy is a lot easier to accomplish.

If I were designing an ELS I would use a PIC. PERIOD!

OK, an edit. I would use a PIC to control the screw. I would not use that same device for the user interface. There I would use something more "interface" friendly. The Raspberry Pi would be one candidate. Let the PIC worry about not skipping a beat and use the Pi for controlling it.

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.

 

[David_M]

Is there a K.I.S.S. way to connect the lead screw to the spindle? Nothing but a hollow pulse wheel mounted directly to the spindle, a fiber-optic cable, a servo motor and an analog frequency converter of some sort to create the needed ratios.

 

[MrStretch]

If you want 100% reliable, glitch-free timing use an FPGA. If you want linux running a gui, use an mpsoc. Xilinx makes ones that have a cluster of 4 A53s, 2 R5 cores and and fpga. You can run linux on the A53s, bare metal or an rtos on the r5s and then use the fpga for the real timing critical stuff. Problem is it would take several lifetimes of Sundays to figure it all out.

 

[Greg Menke]

It's possible to set cpu (core) affinity on the process and on the thread (when multi-threaded) level. I actually don't know what the execution would look like if we had a single single-thread process on a multi-core system without explicit call to pin it to the particular cpu, maybe it would always run on cpu0 ? No idea

On a multi-cpu system the process will often settle on a single cpu but if there is other activity on the system (including kernel threads), then it might move to another. The cost of moving between cpu's is generally limited to L0 and/or L1 caches having to refill on the new cpu. Its a very small effect- we noticed it only in some maximum stress-test utilization of our test systems. I would be inclined to bet if your cpu utilization is < 90% then the timing jitter caused by moving between will be in the noise.

 

[Greg Menke]

Those are all good real world observations. Sometimes people do ask theoretical questions though, so it's good to give them options they're comfortable with.

Perhaps, but why work hard guessing at solutions instead of building in instrumentation from the get-go to reveal system performance and then working out the fixes?

I would argue you don't know what your realtime performance is, regardless of kernel and OS, without such metrics. Even something as simple as a control loop heartbeat brought out to a GPIO pin for a scope to watch is a big help. We accumulate min/max/avg/stddev metrics on control loop duration and headroom, reported as status data. Its very important to see what headroom is left in an algorithm, and how often the deadlines are missed.

 

[GregSY]

All those electronics sounds like a nightmare. Even the guys who understand it want to quibble over which way will work without disasters.

Again, it goes back to the willingness to scrap a part every so often. If a success rate of 90% is OK, and you have lots of time on your hands to tangle with black boxes made in China...go for it.

Otherwise...a pleasant solution awaits.... buy another lathe with gearing for metric threads. Much like women can never have too many cats or shoes, a man can never have too many lathes.

 

[Chip Chester]

(snip) 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.
(snip)

Is this GUI a product, a 'freeware' project, or something he wrote himself? Curious, that's all...

 

[jz79]

doing this properly makes that thing basically into a teach in cnc lathe, which sort of defeats the whole manual machine thing, and, if everything is done properly all will be good (no steppers though), BUT it what about when something goes wrong with it?

basically - it will be only as good as the support, I'd throw this idea away immediately if I couldn't do it all myself, or if you have a REALLY good friend doing it, anyone doing it for money will eventually try to fleece you or you'll end up with more or less ruined machine and lots of wasted time

 

[Greg Menke]

The problems with timing of PC serial ports (USB or otherwise) are one good reason for not using them for any time critical application. I worked with a software engineer on a system that needed +/- 8 ms accuracy. He spent the better part of a year trying to make a Windows OS achieve this about 99% of the time. He never did get it to the 100% point.

A PIC or micro controller has direct control over the output pins so this kind of timing accuracy is a lot easier to accomplish.

If I were designing an ELS I would use a PIC. PERIOD!

OK, an edit. I would use a PIC to control the screw. I would not use that same device for the user interface. There I would use something more "interface" friendly. The Raspberry Pi would be one candidate. Let the PIC worry about not skipping a beat and use the Pi for controlling it.

A pic is a very good choice for this kind of thing IF the numerical end of the algorithm can be adequately represented in the small program space ie if floating/fixed point math ends up being needed for averaging or filtering the PIC program space will fill up quickly. I/O-wise the pic's are very effective for a small investment in board space and they can be quite fast also. The win is the control loop runs in the pic w/ an rs232 connection to a PC or whatever for the click-and-drool interface.

I had the misfortune of trying to use Windows in a realtime application with 1 to 5ms deadlines and low cpu utilization, it was essentially hopeless. Even the realtime scheduler was subject to being blocked by things as innocuous as scrolling a window. It would work OK as long as nothing whatsoever happened on the GUI (including a screensaver)- this was on NT 4 with a dual 450mhz SMP system. I've not seen indications that Windows is any better nowadays.

I've also run into enough corner cases with USB that I wouldn't trust it for anything more than the usual sorts of peripherals- and even then once the device count on a bus is more than 6 or so things can still get sketchy. Partitioning the slow things onto separate USB buss'es so the fast stuff can be fast helps- but if theres a misbehaving driver or some device is weird in some way then reliability can be variable. I had one system where the combination of USB peripherals was somehow confusing the motherboard USB controller to the point it wouldn't initialize and prevented the computer from booting.

 

[rons]

A dream. I would build a flip cover for the LCD.

 

[Garwood]

Is this GUI a product, a 'freeware' project, or something he wrote himself? Curious, that's all...

It's just an Arduino microcontroller that takes orders from a Raspberry Pi computer driving a nice quality 7" touchscreen. There's no magic, it's about $100 in cheap hardware stuffed inside a hunk of anodized aluminum. It's about the same size as a Kindle so it would basically mount to the machine near the threading chart.

This is really not complex to make it work. It's a damn microcontroller running dirt simple code.

 

[Garwood]

not sure how feasible this is, but incorporating an adjustable proximity sensor (think bed mounted stop) and some way of doing a quick retract of the threading tool would allow you to program a stop feed + stop spindle -> retract -> rapid carriage reverse to start (2nd proximity stop) -> reverse retract (whatever word that would be).

The retract/ re-engage threading tool could be based along the lines of those quick retract threading tool holders + a small stepper motor.

Just spitballing, no idea how I would do that, but it would allow easy threading to a shoulder and ease the hassle of keeping the half nuts engaged for metric threading.

I don't want anything operating the cross slide except me. I can turn the handle. It's a manual lathe. I just want the tool to feed at the proper pitch. I like the prox switch idea. A prox switch on a magnet would be a worker or attach prox sensors to the carriage somewhere and add adjustable collars to a rod.

 

[Strostkovy]

If I were to do it I would add an encoder to the spindle. A very basic program with an Arduino or similar to count the pulses, divide by the desired number, and output fewer pulses.

The only control I would put on is a power switch, rotary encoder for selecting thread pitch, a small 7 segment readout and a button to lock it. Probably X.XXmm resolution, and then push the encoder in to get 0.00Xmm resolution.

I recommend connecting the servo overload to e-stop on the lathe and adding an interlock switch to the gearbox so you can't engage both at once.

There is no reason to involve any sort of operating system here.

The encoder approach will also maintain synchronicity as you manually turn the chuck for lining up threads or something, and is largely jitter free.

 

[CalG]

A Compumotor S7 drive is readily numerically slaved to any pulse input.

There are several operator panels that could be populated with a selection of thread pitch results.