-
Welcome back Guest! Did you know you can mentor other members here at H-M? If not, please check out our Relaunch of Hobby Machinist Mentoring Program!
An Electronic Leadscrew Controller using a Pi Pico
- Thread starter AlanB
- Start date
- Joined
- Feb 25, 2021
- Messages
- 3,138
While I agree starting simple is best (crawl, walk, run), I like to think through potential areas that might be interesting to avoid ruling them out in the initial design. Two things that would make sense to me for threading would be
1) auto stop at a point (shoulder, thread gutter, etc). This would reduce the issue of getting the leadscrew disengaged a a key spot.
2) rapid travel to a point. Typically in reverse from the primary threading direction. Why reverse the whole spindle when the ELS could just back the carriage up
These two features would allow you to easily thread without disengaging the half nuts.
For real time processing, I would have the ELS track the encoder turns using an up/down counter. Each encoder input should simply increment/decrement the counter appropriately. Makes for a very short encoder ISR. Possibly also grab the clock time of the interrupt.
Based on the encoder counter, calculate the rate of stepping for the motor. Set up a timer interrupt at that rate to drive the leadscrew. That rate is obviously dynamic.
This keeps the stepper running smoothly rather than using the encoder as a timer for the stepper which is going to have jitter due to rounding and irrational encoder/stepper ratios. It also facilitates an algorithm to accelerate the carriage (leadscrew) to avoid missed steps if using a simple stepper instead of a hybrid or servo.
This may be more complicated than a simple ELS needs but is how I envisioned getting the best performance out of the hardware.
1) auto stop at a point (shoulder, thread gutter, etc). This would reduce the issue of getting the leadscrew disengaged a a key spot.
2) rapid travel to a point. Typically in reverse from the primary threading direction. Why reverse the whole spindle when the ELS could just back the carriage up
These two features would allow you to easily thread without disengaging the half nuts.
For real time processing, I would have the ELS track the encoder turns using an up/down counter. Each encoder input should simply increment/decrement the counter appropriately. Makes for a very short encoder ISR. Possibly also grab the clock time of the interrupt.
Based on the encoder counter, calculate the rate of stepping for the motor. Set up a timer interrupt at that rate to drive the leadscrew. That rate is obviously dynamic.
This keeps the stepper running smoothly rather than using the encoder as a timer for the stepper which is going to have jitter due to rounding and irrational encoder/stepper ratios. It also facilitates an algorithm to accelerate the carriage (leadscrew) to avoid missed steps if using a simple stepper instead of a hybrid or servo.
This may be more complicated than a simple ELS needs but is how I envisioned getting the best performance out of the hardware.
I was thinking it might be interesting to have a magnetic pickup to get one pulse per rotation to verify the gearbox is in the right gear. Same idea.
The spindle mechanical subsystem determines system acceleration, the leadscrew needs to be in precise lock step with that, anything else is an error in gearing. Using fractions based on the spindle encoder is very simple and can be done very quickly which is good for high spindle speeds and simple hardware like the Pico PIO. There is no need for irrational fractions that I know of, even metric threads are simple fractions with a 254/10 added to gear teeth and leadscrew integer ratios. The largest errors are from the stepper motor steps, the spindle encoder is higher resolution.
The carriage position is related to motor pulses as long as the transport (leadscrew/feed) is not disengaged. Counting them doesn't require an ISR as those pulses are being generated, easy enough to count them as they are generated. Tracking the encoder is something the PIO decoder could do as it processes the edges, but one has to be careful about interrupts at those rates. At 4000 RPM with 4096 encoder that's an interrupt every 3.6 microseconds. At those rates interrupts often become problematic, some library function or other ISR somewhere turns interrupts off for too long and interrupt processing adds a lot of overhead to the actual task. I've chased deep problems with interrupt systems and it can be a major distraction for a project.
Stopping the feeding or threading at a shoulder, slewing back to a starting point is certainly possible. The user interface must accommodate more functions to handle that. Perhaps more controls as well. I've seed a few ELS projects that added that functionality.
Controlling the gearing by managing a timer running the stepper rather than using fractions from the encoder is a significantly different approach, and I have not investigated that in any detail. Maintaining the gearing ratio precisely might be a significant computational and timing challenge during spindle speed changes due to cutter loads. For that technique one might choose a processor with a richer timer system and higher computing speed rather than a Pico. The Pico PIO and multicore is well suited to the fractional approach which has been very successful for many ELS projects. Have you found any examples of the timer driven approach to ELS that discuss the requirements for the processing and timing hardware?
Last edited:
- Joined
- Dec 18, 2019
- Messages
- 6,480
FYI Teensy prices have jumped 50% since I bought mine. They are around $26 now. Having a Pico do this would be a great thing for people.
That being said, so far, I don't have any issues using a single core processor (Teensy 4.1) at encoder rates up to 400 KHz without losing steps. Using a 4096 pulse per revolution encoder, that is about 5859 RPM, which is more than twice as fast as my lathe can go! I can also drive the display at 100ms concurrently.
That being said, so far, I don't have any issues using a single core processor (Teensy 4.1) at encoder rates up to 400 KHz without losing steps. Using a 4096 pulse per revolution encoder, that is about 5859 RPM, which is more than twice as fast as my lathe can go! I can also drive the display at 100ms concurrently.
For anyone not aware, the Clough42 ELS, perhaps the most popular current DIY ELS is thoroughly documented on his channel on youtube in 20 plus videos. There is also a thread or more here on hobby-machinist on using it. It is based on a 90 MHz TI DSP demo board that is reportedly out of stock till August. It is strictly a multi-ratio electronic gearbox, with no shoulder, acceleration/deceleration or independent motion capability. The user interface is a very inexpensive LED and Buttons board module that is available from many sources. The control algorithm uses floating point calculations rather than fractions and he talks about the errors from this approach. It does not use the "slaved timer" technique that we were discussing above. A popular encoder for this and many other DIY ELS systems is the Omron E6B2-CWZ6C with 1024 lines, 4096 edges and costs around $30. It is good to 6000 RPM. There is a github repository for the code. The developer sells various components that make it easier to fabricate, but I think everything is out there for a DIY build. The software toolset is a proprietary TI toolchain but buying the "demo board" entitles one to run the software. My intention here is partially to collect and share information about various DIY ELS systems and components for those who are interested and considering making one. If the Clough42 system meets your needs it is a fairly easy build and the costs are modest. Even if you plan to make your own custom ELS some of the early videos in the series are worth reviewing.
Last edited:
- Joined
- Feb 25, 2021
- Messages
- 3,138
As I said earlier an ELS is a about three down on the project list of microcontroller projects. Since I already have full featured QCGBs on all three lathes, If I do get around to it I’ll be interested in implementing something with a little more than simple ratio functionality.
- Joined
- Feb 25, 2021
- Messages
- 3,138
As a correction to my earlier comment, I said irrational ratios and should have said any non-integer ratio. For example, if you need to execute 2 (micro) steps every 3 encoder pulses. I believe that’s probably worst case.
I've been away from the internet for a few days. Amazing to get out into the wild now and then. 
It is interesting and useful to think in more detail about how these systems work.
The simple algorithm outputs a pulse 2 of 3 times there is an input pulse for a 2/3 ratio, in a repeating skip, pulse, pulse sequence. This rotates the magnetic field (not quite instantly, the rotation is impeded by the drive voltage, inductance and drive electronics bandwidth to the change of currents). The mechanical system filters these inputs according primarily to the rotating inertia and effective "spring" constant from the torque of the system, which is usually dominated by the motor's rotor. Each "microstep" is on the order of some tenths of a thousandth or less. The smaller you make the microsteps the less stiff they are (some say torque is reduced, but this probably isn't the best way to think about it, if it lags a bit behind there is essentially no torque lost, so loading mostly affects lag, and more lag likely results in more effective filtering and smoother motion). The rotating magnetic fields are exerting force on the rotor, pulling it around. The resulting average errors from the digitization would be less than one microstep, plus any lag needed to develop adequate torque. Many people have already built these types of systems, and they have these types of motors and drives. It seems to work pretty well, I haven't been finding that people's simple DIY ELS systems failed to meet their needs, at least none have said on their internet videos or pages that I have noticed. There are many imperfections in the mechanical system gears and leadscrews already (of lathes we can afford), not just this. This is probably not even the dominant error source in the system. There are ways to improve it if that is actually an important requirement, like using a precision gearmotor or a servo with high encoder resolution, and a higher resolution spindle encoder.
The errors caused by trying to synchronize a separately generated timing signal would have to be analyzed. The source would generally have discrete timing steps that would not match the needed pulses, so there would be errors there, some of which might be cumulative. A number of rapid and precise timing and calculations would be required to make it work. The feedback loop to monitor the spindle RPM and compute the needed position updates of the leadscrew, and feed back to the timing controller would add additional errors and feedback loop stability issues. It is certainly a valid approach to the problem, however it is far from simple, and it is much more difficult to predict the performance before you build and debug it. It seems like a rough way to do it, but perhaps it would be simpler once the design was developed. It seems like there might be a high computational load to get a good closed loop bandwidth. It would be interesting to see some examples of this approach that have already been developed. Have you found any?
In any case one wanting to experiment with that type of control should probably select a microcontroller well suited to that technique - perhaps not a Pico. This synchronized pulse generator technique is more of a hardware design approach, and seems better suited to an FPGA rather than a microcontroller. I would choose a microcontroller than had an adequate onboard FPGA, use a separate Microcontroller and FPGA, or use an FPGA that has an internal microcontroller or FPGA IP that can be compiled into the FPGA directly. We worked with all of those on projects in the past. Very impressive and flexible hardware. To have success with that approach the team needs to have the requisite skills to operate in that design environment, which is a mix of microcontroller, software and FPGA hardware logic design. But that way you can implement timers that have the properties that are needed and are mated in the appropriate way. Doing it with discrete timers in or external to microcontrollers will likely add inter-timer delays and various issues that may not be resolvable without adding additional hardware. The nice thing about an FPGA design is that you can keep tuning the FPGA logic implementation and not generally have to rip up the hardware later in the project as long as adequate capability was chosen in the FPGA.
What is needed to implement it? Measurements of the encoder timing, a pulse generator that can be programmed an dynamically adjusted while it continues to generate smooth pulse trains. The calculations to provide the controls. Enough computational bandwidth to handle them at a high enough rate to have adequate closed loop performance when the lathe encounters spindle loading and slows down - a phase locked loop.
In any case it is an interesting approach. The question is - is the improvement it promises worth the cost/complexity?
It is interesting and useful to think in more detail about how these systems work.
The simple algorithm outputs a pulse 2 of 3 times there is an input pulse for a 2/3 ratio, in a repeating skip, pulse, pulse sequence. This rotates the magnetic field (not quite instantly, the rotation is impeded by the drive voltage, inductance and drive electronics bandwidth to the change of currents). The mechanical system filters these inputs according primarily to the rotating inertia and effective "spring" constant from the torque of the system, which is usually dominated by the motor's rotor. Each "microstep" is on the order of some tenths of a thousandth or less. The smaller you make the microsteps the less stiff they are (some say torque is reduced, but this probably isn't the best way to think about it, if it lags a bit behind there is essentially no torque lost, so loading mostly affects lag, and more lag likely results in more effective filtering and smoother motion). The rotating magnetic fields are exerting force on the rotor, pulling it around. The resulting average errors from the digitization would be less than one microstep, plus any lag needed to develop adequate torque. Many people have already built these types of systems, and they have these types of motors and drives. It seems to work pretty well, I haven't been finding that people's simple DIY ELS systems failed to meet their needs, at least none have said on their internet videos or pages that I have noticed. There are many imperfections in the mechanical system gears and leadscrews already (of lathes we can afford), not just this. This is probably not even the dominant error source in the system. There are ways to improve it if that is actually an important requirement, like using a precision gearmotor or a servo with high encoder resolution, and a higher resolution spindle encoder.
The errors caused by trying to synchronize a separately generated timing signal would have to be analyzed. The source would generally have discrete timing steps that would not match the needed pulses, so there would be errors there, some of which might be cumulative. A number of rapid and precise timing and calculations would be required to make it work. The feedback loop to monitor the spindle RPM and compute the needed position updates of the leadscrew, and feed back to the timing controller would add additional errors and feedback loop stability issues. It is certainly a valid approach to the problem, however it is far from simple, and it is much more difficult to predict the performance before you build and debug it. It seems like a rough way to do it, but perhaps it would be simpler once the design was developed. It seems like there might be a high computational load to get a good closed loop bandwidth. It would be interesting to see some examples of this approach that have already been developed. Have you found any?
In any case one wanting to experiment with that type of control should probably select a microcontroller well suited to that technique - perhaps not a Pico. This synchronized pulse generator technique is more of a hardware design approach, and seems better suited to an FPGA rather than a microcontroller. I would choose a microcontroller than had an adequate onboard FPGA, use a separate Microcontroller and FPGA, or use an FPGA that has an internal microcontroller or FPGA IP that can be compiled into the FPGA directly. We worked with all of those on projects in the past. Very impressive and flexible hardware. To have success with that approach the team needs to have the requisite skills to operate in that design environment, which is a mix of microcontroller, software and FPGA hardware logic design. But that way you can implement timers that have the properties that are needed and are mated in the appropriate way. Doing it with discrete timers in or external to microcontrollers will likely add inter-timer delays and various issues that may not be resolvable without adding additional hardware. The nice thing about an FPGA design is that you can keep tuning the FPGA logic implementation and not generally have to rip up the hardware later in the project as long as adequate capability was chosen in the FPGA.
What is needed to implement it? Measurements of the encoder timing, a pulse generator that can be programmed an dynamically adjusted while it continues to generate smooth pulse trains. The calculations to provide the controls. Enough computational bandwidth to handle them at a high enough rate to have adequate closed loop performance when the lathe encounters spindle loading and slows down - a phase locked loop.
In any case it is an interesting approach. The question is - is the improvement it promises worth the cost/complexity?