An Electronic Leadscrew Controller using a Pi Pico

[Spajo]

I have used Platform I/O for one microcontroller project. SAM51D cpu. It doesn't have to be not that complicated and it can import just about any Arduino library. An 8bit CPU might do the job, but I think the project would benefit from 32 bit CPU @ 100MHz or more. You won't have to worry about running out of resources. Python and I imagine MicroPython too is fairly slow compared to C. One option used by Klipper in the 3D printer space is to mix Python and C, the later used for speed sensitive parts of the code.

I'm really interested in this project because I think it will add capabilities to my lathe(s).

Spajo

 

[WobblyHand]

I don't know of a successful Pico driven ELS yet. Think it should be possible if one makes appropriate choices for the encoder. Need to make sure one can handle the encoder interrupt rate for the spindle, and optionally any DRO's. It's all a matter of trade offs to get what you need, without giving up much functionality...

I made my own ELS using a Teensy 4.1 (normally running at 600 MHz) and a touch panel display for the user interface. It works rather well. My DRO's are integrated into the display. Others have used an ESP32 and used a phone web browser for the interface. There are many ways to accomplish an ELS. I do have to say, it is a bit of work to roll your own from scratch. But it sure was gratifying seeing it all coming to life.

 

[AlanB]

The Pico State machines can handle really fast and efficient I/O. A combination of MicroPython and state machines or C should do the trick. Micropython is really good for the user interface. Having dual cores can also really help out.

I've had really good luck with autorouters, well over 90% can be auto and very little needs to be fixed on these simple boards. Now if you are getting into transmission lines and more complex PCB design that's something else, but this stuff is really not that demanding. I should try KiCad again, but when I tried it long ago it was really rough and the error messages were coming out in something like French, not a good fit for me.

 

[WobblyHand]

Having programmed multiple cores before, you have to extensively test this. I did an FFT engine that used 20 cores and you really have to be careful about common memory and the fact that different cores can execute the tasks at different times. They can be difficult to synchronize. Failure to sync can result in wildly wrong answers, trust me on that .

I've used commercial auto routers more than 20 years ago that did quite well. Remember using rules based routing for transmission lines, which resulted in first pass success and being way ahead of schedule. I think the KiCAD guys simply don't know how to implement auto routers or they are afraid of tackling something new. Most businesses use auto routers to save time. It's a shame KiCAD is so far behind. It works, but it's just crippled not having an auto router.

All that being said, it takes someone to start coding to get a Pico run ELS. So start coding! Talking doesn't work, coding and debugging does. Starting out, I'd say that you need a good encoder routine and you need to understand the Bresenham algorithm. After that, it's mostly user interaction. Have fun.

 

[Spajo]

Having programmed multiple cores before, you have to extensively test this. I did an FFT engine that used 20 cores and you really have to be careful about common memory and the fact that different cores can execute the tasks at different times. They can be difficult to synchronize. Failure to sync can result in wildly wrong answers, trust me on that .

I've used commercial auto routers more than 20 years ago that did quite well. Remember using rules based routing for transmission lines, which resulted in first pass success and being way ahead of schedule. I think the KiCAD guys simply don't know how to implement auto routers or they are afraid of tackling something new. Most businesses use auto routers to save time. It's a shame KiCAD is so far behind. It works, but it's just crippled not having an auto router.

All that being said, it takes someone to start coding to get a Pico run ELS. So start coding! Talking doesn't work, coding and debugging does. Starting out, I'd say that you need a good encoder routine and you need to understand the Bresenham algorithm. After that, it's mostly user interaction. Have fun.

Ha, yes talk is cheap. Thanks for mentioning the Bresenham algorithm. Any high end single core 32bit processor should eat this application alive. I plan to use an interrupt to process the encoder inputs and drive the motor. My opinion at this point.

I'm itching to get started coding. So I'm going to order an encoder and and some type of processor single board computer.

Spajo

 

[AlanB]

Much of the difficulty with multiple cores comes down to the suitability of the problem and breaking it into appropriate pieces, minimizing the communications requirements, and having the detailed understanding of the software tools and how to use them with multiple tasks and cores. The ELS application is well suited to multiple cores, with simple communications. Lately I've been working with Pico MicroPython and Teensy Arduino projects. The Teensy project is GPS PPS processing at the microsecond and millisecond level while the MicroPython is a less demanding networked clock application. Both are capable and interesting to work with, however the MicroPython is much more enjoyable and much faster to develop and debug on. An ideal situation for the Pico would be to run MicroPython on one core and C++ on the other which I haven't seen done yet but should be possible. I have a lot of projects and this one is low on the list at the moment so I'm not actively working on it, but at some point I hope to get back to it. Lots of folks have done ELS's, so do a survey and learn from what they've done. Many use 8 bit micros and work quite well, so doing it with a 32 micro should make it a bit easier.

 

[trenshi]

Welcome to the thread and to the forum! I have been doing some other projects with the Pico W but have not gone further with this ELS. I've mostly been using MicroPython on my Pico projects thus far but for maximum performance one of the other toolsets may be helpful. In the past I've done Arduino projects including Arduino on Teensy so I might use that toolset, but there are some other choices now that I haven't looked at like Platform I/O. I generally prefer lightweight tools, but some of these setups are pretty large and thus bring a learning curve. It would be great to see some progress on a Pico solution. There has been major progress on a Teensy solution in another thread here and that's worth looking at. One challenge on the Pico is reading the encoder. Finding or writing some code to utilize the Pico state machines might be perfect for that.

Thanks, understood!

I'll have a look at the Teensy projects. I suppose I wanted to find the most minimal motion control interface/package I could muster, because I'm not sure how long I'd linger on ELS capabilites versus trying to do more full CNC control. I'm just starting out with lathe stuff anyhow, but recently built a moving gantry CNC router and enjoyed the process.

I might eventually play around with the linuxcnc installation I have on an old computer, as I saw a package for simple ELS type functions via linuxcnc on github.

In a way, the most appealing thing would either be a dead barebones simple platform for experimentation (as I want to do fairly simple things, feed at appropriate rates and maybe drive a stepper for gear hobbing), or something that's more full fledged that can also support full CNC control, instead of spending as much energy just getting the ELS up.

Anyhow, thanks for the welcome.

 

[trenshi]

I looked around for the Teensy thread about an ELS, but it's a bit hard to search for the bare bones implementation from the long forum thread -- maybe I missed a repo.

I'm still going to try playing around with the pico a bit, unless I can find a slimmed down teensy or nano example that isn't a full package, but rather just encoder + motor as a platform / playground to start.

I found a PIO implementation of 4 synchronized stepper motor controls with the pico:

GitHub - Vendelator/RP2040_PIO_Steppermotors: Synchronized PIO Programs for stepper motors. 4 Motors possible.

Synchronized PIO Programs for stepper motors. 4 Motors possible. - Vendelator/RP2040_PIO_Steppermotors

github.com

and I found a good video about interrupts and interfacing with quadrature motor encoders:

I'll try playing around with my absolute inexperience and the encoder example first, moving to attempting threading and communciation via global variables or something similar. Not sure if it's the wrong tree to bark up, but right now I just want spindle/encoder rpm readout and hopefully some testing of stepper control based on this reading next.

 

[AlanB]

Teensy 4.1 ELS thread is here: https://www.hobby-machinist.com/thr...ad-screw-controller-using-a-teensy-4-1.99609/

 

[AlanB]

Here is a Pico PIO Encoder library: https://github.com/GitJer/Some_RPI-Pico_stuff/tree/main/Rotary_encoder