An Electronic Leadscrew Controller using a Pi Pico

[AlanB]

Using a Pi Pico for an Electronic Lead Screw Controller

The purpose of this thread is to discuss an Electronic Leadscrew System based on the Pi Pico. There have been a number of other similar projects in various forums and on youtube channels, but as far as I know none have used the Pi Pico. There are many processors that can do this job adequately, this is not really to determine which processor is "best", but to study the suitability of the Pico for this task, and perhaps share some ideas and maybe even some code for this work, and to encourage others to try this for their own project(s). This is not intended to take away from the similar Teensy 4.1 project, or other similar projects, but to separate the discussions based on the specific different hardware. There are many ways to do this project!!

The more I look at the Pi Pico the more I think it is an especially suitable choice for an Electronic Lead Screw microcontroller. It has hardware and support software that is well suited for the task, and it is small, available and inexpensive. In these times of chip shortages the availability is a key feature. It is also well supported by the Pi Foundation and many tutorials, software and libraries for it are developing at a very fast pace, including support from the large Arduino community. There are multiple toolsets and environments available for the Pico already, and it is a very young microcontroller with what I expect is a very bright future.

For those not familiar with the Pi Pico, here is a summary of this new microcontroller and board from the Raspberry Pi Foundation:

Pi Pico Feature Summary

21 x 51mm (0.83 x 2.1 inches) breadboard friendly DIP format
RP2040 Dual Core ARM Cortex M0+ up to 133 MHz
265KB on chip SRAM
2MB on board Flash
26 GPIO pins including 3 Analog Inputs
2 UART, 2 SPI, 2 I2C, 16 PWM
USB controller with Mini USB connector
1.8-5.5VDC supply
low power sleep modes
accurate on chip clock (microseconds since boot in 64 bit register)
temperature sensor
accelerated integer and floating point libraries on chip

The Pico PIO has a powerful I/O subsystem with Two blocks:
Each block has Four programmable state machines, with
Two I/O FIFOS, 32 instructions, and two IRQs to the Pico,
For a total of 8 state machines with 16 FIFOS

Note that there are many other boards from other vendors that have this new microcontroller chip, and they each offer slightly different features.

Suitability for an ELS

Dual Cores are an excellent fit for a real-time system with a user interface as the ELS requires. One core can be dedicated to the real time critical performance while the other can be dedicated to the user interface and other less critical tasks. The PIO blocks can be used to provide improved hardware level real-time I/O performance in reading the spindle encoder and generating output pulses to the motor controller.

An ELS has basically one critical task - to read a spindle encoder, and at a precise ratio, control a motor that drives the carriage threading and feeding shafts. The goal is to both do away with loose change gears, and to provide a wider set of gear ratios for threading and feeding.

In many cases a lathe has a gearbox with some selections for threading and feeding, but usually this set of ratios is incomplete, especially in the smaller lathes. It may be lacking metric ratios, or some in-between less common imperial ratios may not be present or are only available by changing loose gears into the drive chain. Many ELS systems essentially ignore the existing gearbox. My PM-1228 lathe has a 15 speed gearbox, so I would like the ELS to be able to work with the gearbox rather than ignoring it, allowing me to choose gearbox settings that optimize the overall performance of the machining operation.

Real Time Requirements for an ELS

A popular encoder for ELS systems is a 1024 line rotary encoder which produces 4096 edges per rotation. If the spindle is turning 2500 RPM the resulting encoder input to the microcontroller has 170,667 edges per second, or one edge every 5.86 microseconds. While this is a fairly high rate for a microcontroller a modern chip like the Pico has a maximum clock frequency of 133 MHz so it has about 779 clock cycles per encoder event to do the processing. So it requires some care in programming but is certainly not impossible.

This can be handled by the microcontroller running in a tight loop, or by using interrupts. Handling interrupts at these rates requires care and libraries that don't turn interrupts off for more than a few microseconds at a time. Dedicating a core to the realtime task is very appealing.

Pico PIO Blocks

The Pico PIO State Machine Blocks are particularly well suited to the ELS realtime task. For example one could be used to generate the direction and step pulses with appropriate timing for the motor control. Another could be used to preprocess and decode the incoming spindle encoder signals, or it even might be possible to fit the gear ratio calculation into a PIO. I'm just starting to learn what these powerful but small state machine processors can do.

Next Steps

I have a small Pi Pico testbed set up that I've been playing with for awhile. It's reading a GPS and displaying information about GPS altitude information using MicroPython.

So far all I've done with the ELS is to research existing systems online and make notes and calculations. I do have a spindle encoder and possibly a motor controller and motor that would be suitable. The hardest part of this project is probably mounting the gear on the lathe, not making the electronics and software.

Are others interested in discussing and/or investigating a Pi Pico based ELS?
What other projects might the Pico be suitable for?
What have you done with the Pi Pico??

Alan B

 

[jwmelvin]

I’ve considered the ELS idea but not to the point of jumping in. My Clausing is set up for only imperial threads, and it’d be nice to add metric.

I’ve done some projects with Ternsy and RPi, but don’t know the Pico. I’ll be following along your discussion and appreciate your sharing.

 

[rabler]

I picked up 4 of the Pi Pico boards, with plans to use in place of the AVR line of processors in my next electronics project. I'm thinking of adding some intelligence to my RPC, both monitoring and possibly for for enhancing voltage control on the generated leg. I also have thoughts about upgrading my RPC to a dual idler RPC (10+20HP).

I've also thought of using it for an ELS although all of my lathes have a full QCGB, but it would be useful for adding metric threading. I've wanted to look at the PIO system to see how much can be done with that in conjunction with the encoder. All the encoder interrupt service routine (ISR) needs to do in increment a count, given one possibility is using it with my 10EE that spins up to 4000 RPM, shorter is better. I have yet to look at the interrupt scheduling/priorities and latency issue, but I wonder if the PIO could be used to mitigate latency issues.

I'm in the process of building a new shop, and have included an office which my electronics bench has already moved into (although things are not yet set back up).

I've also considered using the Pico in conjunction with IGBT rectifiers to replace the 10EE DC controller, need to run my DC motor off to a motor shop first though to see if it can be rewound for a realistic price. I have built an AVR (Arduino nano) controller for an SCR-based DC controller, but a direct IGBT design could be a lot more elegant if I can get the right control algorithms.

FWIW, I'm an old fashion K&R C programmer and avoid python like the plague, but am comfortable in the world of interrupts, and direct IO, etc.

Editted to add: While the lathe may spin up to 2500 or 4000 RPM, realistically threading is going to occur at 500 RPM or less.

 

[AlanB]

I have at least two copies of the original K&R C programming book around here somewhere. About wore one out when it was new and C was young. C is excellent for all the real time work, but I do enjoy Python for programming many other things. It would be interesting to run Micropython in one Pico core (for the UI) and C in the other, but I haven't seen that done. Yet. So we're probably stuck with C for now. Either the Arduino or the Pico SDK perhaps, or there are others.

We had some big supplies with IGBTs at work. Megawatt level. Sounded like gunfire when they blew one up. Those algorithms need to be correct.

At least with an ELS we're not likely to blow things up.

 

[rabler]

So what are the working parameters?
At the most basic, an els is something that keeps a ratio between spindle turns and leadscrew turns. And a UI to enter that ratio. But:
1) What are reasonable ratios?
2) What error is tolerable?
3) What happens if there is a real qcgb in the mix?
4) How does threading vs normal feed effect the mix?
5) Is there utility in any other functions than emulating a leadscrew gearbox?
edited to added: 6) backlash compensation

 

[rabler]

Took a look at the rp2040 datasheet again.
Unfortunately it doesn’t have a direct hardware timer capture function that I saw. (Where a timer can be latched or copied to a register on a i/o signal in hardware). So a low latency interrupt is necessary. Fortunately it does appear that it has the ability to change the priority on various interrupt sources, and interrupts can interrupt lower priority interrupt routines. The encoder input isr should be able to be just an increment/decrement of a counter, and perhaps a copy of a clock counter.

 

[AlanB]

Took a look at the rp2040 datasheet again.
Unfortunately it doesn’t have a direct hardware timer capture function that I saw. (Where a timer can be latched or copied to a register on a i/o signal in hardware). So a low latency interrupt is necessary. Fortunately it does appear that it has the ability to change the priority on various interrupt sources, and interrupts can interrupt lower priority interrupt routines. The encoder input isr should be able to be just an increment/decrement of a counter, and perhaps a copy of a clock counter.

What did you plan to use the timer capture for? I've used those for time synchronization with the GPS PPS signal, but don't know that's needed here. The PIO can do things with less latency than interrupts. There is a 64 bit microseconds since boot counter that will be useful for timing things, if resolution below 1uS is needed the PIO state machines can run at 133 mhz.

 

[AlanB]

So what are the working parameters?
At the most basic, an els is something that keeps a ratio between spindle turns and leadscrew turns. And a UI to enter that ratio. But:
1) What are reasonable ratios?
2) What error is tolerable?
3) What happens if there is a real qcgb in the mix?
4) How does threading vs normal feed effect the mix?
5) Is there utility in any other functions than emulating a leadscrew gearbox?

Excellent questions, to which the answers will vary depending on the lathe's design features and the user's needs. What are your requirements? I'm not planning to make a "one design fits all" solution, but rather build up a toolbox of components that can be used to tailor a solution to individual needs.

In no particular order,

In my case (PM-1228) the gearbox has 15 ratios from about 0.33 to 2.4.

The encoder I have is 4096 edges per rotation. The steppers most use are 200 steps/rotation and 8:1 microsteps is common. I'll start with those values.

The algorithms commonly used allow fractions up to 1:1 between the motor pulses and the encoder edges. Encoder edges trigger the process and motor pulses are generated or not depending on the ratio. So if you have a 4096 encoder, and are using 8 microsteps you have 1600 steps per revolution. So the maximum output ratio is 4096/1600 or 2.56:1. If higher output RPM is needed the microstepping could be reduced to 4 and then 5.12:1 would be possible. In my case with the available gearbox ratios I can get by with 8 microsteps. The gearbox may also help here, in my case it does.

On my lathe there are separate shafts and gear ratios for threading, feeding, and cross feeding. On a lathe with only a leadscrew then more low ratios would be needed for feeding, but those are just smaller fractions, so they don't represent much challenge to the ELS. 32 bit or even 64 bit integer fractions have quite a range.

Other ELS functions potentially opens up a huge range of possibilities. I'm not too interested in that myself at this time but perhaps others would be. But one has to be careful to not run before walking. With a solid foundation more features can be added later. I'd like to get something working before contemplating increases in project scope.

Tolerable error is a deep topic. From what I've seen there seem to be little in the way of tolerance problems in the ELS systems that folks have built. The resolution of common encoders and motors combined with the gearing in the lathe seems to make this a non-issue. Operating with the gearbox in the least favorable setting might make the 1600 steps / revolution to about 530 steps per revolution coming out of the gearbox. This would be useful or needed only when cutting a very coarse thread. If the leadscrew was 12 TPI each step would correspond to about 2 ten thousandths if I did the math correctly. Of course the configuration of the gearbox and ELS is up to the user, so the high gearbox ratio may not be the best choice to make that thread, there are usually many choices with the gearbox that the ELS can make work. Selecting a lower gearbox ratio will make the motor RPM go up and may restrict the speed at which the threads may be cut, but this is perhaps the normal tradeoff and threads are not usually cut at high RPM values.

My current thought is to design an ELS for the lathe that can accommodate any gearbox setting, and display useful information about the RPM limits and perhaps the effective step size so the operator can make choices about what gearbox ratio to use. For a lot of things one could just set the gearbox at 1:1 and let the ELS do everything (what most ELS systems do), but leaving the options up to the operator is useful for some edge cases. It just requires the user interface to take a gearbox input so the operator can inform the ELS of the gearbox configuration. Also I plan to make it possible to use the change gears in the future, if one wanted to, and not do irreversible changes to the machine.

This is a starting point, not a final design. It is based on looking at all the ELS designs I have run across on the internet in the last ten or more years. My PM-1228 is new, but I've had a small lathe since 2003, and it had a pile of change gears and no QCGB. So I've wanted something for awhile. Clough42's ELS is about 3 years old, I was looking and thinking about this long before that.

Backlash Compensation - the lathe is running one direction, so lash isn't really a problem. The ELS will have less lash than the gears it replaces. If a CNC is the goal, then there are several excellent solutions out there already (that have such compensation) and duplicating that complexity is not something I expect to entertain. I do have some excess I/O capacity on the Mill's LinuxCNC controller to handle the lathe, so I would probably go that way if I wanted that kind of functionality.

Alan B

 

[AlanB]

I picked up 4 of the Pi Pico boards, with plans to use in place of the AVR line of processors in my next electronics project. I'm thinking of adding some intelligence to my RPC, both monitoring and possibly for for enhancing voltage control on the generated leg. I also have thoughts about upgrading my RPC to a dual idler RPC (10+20HP).

I've also thought of using it for an ELS although all of my lathes have a full QCGB, but it would be useful for adding metric threading. I've wanted to look at the PIO system to see how much can be done with that in conjunction with the encoder. All the encoder interrupt service routine (ISR) needs to do in increment a count, given one possibility is using it with my 10EE that spins up to 4000 RPM, shorter is better. I have yet to look at the interrupt scheduling/priorities and latency issue, but I wonder if the PIO could be used to mitigate latency issues.

I'm in the process of building a new shop, and have included an office which my electronics bench has already moved into (although things are not yet set back up).

I've also considered using the Pico in conjunction with IGBT rectifiers to replace the 10EE DC controller, need to run my DC motor off to a motor shop first though to see if it can be rewound for a realistic price. I have built an AVR (Arduino nano) controller for an SCR-based DC controller, but a direct IGBT design could be a lot more elegant if I can get the right control algorithms.

FWIW, I'm an old fashion K&R C programmer and avoid python like the plague, but am comfortable in the world of interrupts, and direct IO, etc.

Editted to add: While the lathe may spin up to 2500 or 4000 RPM, realistically threading is going to occur at 500 RPM or less.

Re threading RPM - yes exactly, the feeding needs to work at full RPM but threading that fast would be much too exciting.

 

[AlanB]

It would be optimal for the PIO to handle the encoder, fraction calculation and pulse output.. I think PIO can handle the encoder and motor pulse, I don't know if the fraction computation can be done there yet. It's basically an add, compare, and conditionally subtract and triggering the pulse output. So it is not too complicated. If all that is handled in PIO then the cores won't have any hard realtime to do.

For a higher performance implementation I would select a small FPGA. In that case the micro just loads the FPGA parameters and does no realtime at all.