An Electronic Lead Screw controller using a Teensy 4.1

And for imperial I get:
Code:
leadscrew TPI =  12
Steps per rev =  1600
Encoder ppr   =  4096

Thread   Approx Ratio   int N, int D   Error in 10 pitches
 [TPI]                                      [in]
6.0      0.781          (781, 1000)      0.0005
8.0      0.586          (293, 500)      -0.0001
10.0     0.469          (469, 1000)     -0.0005
11.5     0.408          (51, 125)       -0.0008
12.0     0.391          (391, 1000)     -0.0008
18.0     0.26           (13, 50)         0.0009
20.0     0.234          (117, 500)       0.0008
24.0     0.195          (39, 200)        0.0007
28.0     0.167          (167, 1000)      0.0009
32.0     0.146          (73, 500)        0.001
40.0     0.117          (117, 1000)      0.0004
56.0     0.084          (21, 250)       -0.0006
Any other threads I should put in? Can't do a 4 TPI with 8 micro steps, but can do it with 4. Happy that biggest divisor is 1000, seems more manageable. Darn font isn't preserved when you edit the message, have to set it again.
 
Last edited:
10,000 you could handle with 16 bit integers. And you have 32 and 64 bit integers available...
 
Here are a few threads (per inch) I've seen mentioned (not verified):

19 british pipe thread
22 5/16 bsf
26 brass pipe, cei & 1/4 bsf, 3c collets
27 gas thread
 
It's not hard to enable the code to generate double pulses which is the same as converting to 4 microsteps per step on the leadscrew drive.
 
Here are a few threads (per inch) I've seen mentioned (not verified):

19 british pipe thread
22 5/16 bsf
26 brass pipe, cei & 1/4 bsf, 3c collets
27 gas thread
Are these straight threads?

I added 72, 80, 96, and 100 TPI along with 3, 4, & 5 mm threads. For the heck of it I put in the ones above. Ok, that was fun, but need to go learn some more about the processing.
 
Are these straight threads?

I added 72, 80, 96, and 100 TPI along with 3, 4, & 5 mm threads. For the heck of it I put in the ones above. Ok, that was fun, but need to go learn some more about the processing.

I collected those from other ELS conversations, I don't know the details.
 
I think I would organize the UI so there were "standard threads" and "special" thread lists, so one didn't have to wade through them all. And perhaps just have a "custom" so you can select any value, either instead of or in addition to the "special" selections. Same goes for feeds. Have a short list of normal ones and a way to enter others when needed.
 
I think I would organize the UI so there were "standard threads" and "special" thread lists, so one didn't have to wade through them all. And perhaps just have a "custom" so you can select any value, either instead of or in addition to the "special" selections. Same goes for feeds. Have a short list of normal ones and a way to enter others when needed.
Sounds like a good plan. At the moment, I'm just trying to get a feel for all the tasks required. I haven't implemented any thing close to an ELS just yet. It will take me a while to work it all through. Might model the UI similar to greenail, with a JSON file. Then I can either write a local display function based on the data, or remote. I do have an old tablet that is unused, but I have to think about that. The local display does have touch, but it is only 320*240, which makes for a difficult UI, but probably no worse than Clough42's keypad.

Suppose I could use a bigger local display, but perhaps the tablet would be better. 10" display vs 2", my choice would be the 10", just for the pixels. Just gets hard to push the data. Easy to get network or interface bound. Need to calculate the data requirements before deciding.
 
Sounds like a good plan. At the moment, I'm just trying to get a feel for all the tasks required. I haven't implemented any thing close to an ELS just yet. It will take me a while to work it all through. Might model the UI similar to greenail, with a JSON file. Then I can either write a local display function based on the data, or remote. I do have an old tablet that is unused, but I have to think about that. The local display does have touch, but it is only 320*240, which makes for a difficult UI, but probably no worse than Clough42's keypad.

Suppose I could use a bigger local display, but perhaps the tablet would be better. 10" display vs 2", my choice would be the 10", just for the pixels. Just gets hard to push the data. Easy to get network or interface bound. Need to calculate the data requirements before deciding.
We use a 7" Nextion display. It has a serial interface and a touchscreen. Comes in both a capacitive and resistive model. You can store multiple pages in the display.
 
@greenail in the reference you give by Didge, what does he mean by encoder resolution? Is the total number of edges per revolution, or the number of A pulses per revolution? My encoder has 1024 A and 1024 B pulses per revolution. But obviously 4096 edges per revolution.

I believe "encoder resolution" == PPR which for full quadrature is 4 x CPR

It is my understanding that the ratio Rp needs to be < 1, where

Yes for his algo but you can do ratios larger for 1. this may help https://github.com/ashiagarwal73/Bresenham-s-line-algorithm-for-all-quadrants

Rp = ( pitchdistance/turn * steps/rev * microsteps/step ) / (leadscrewdistance/turn * encoder_resolution) = (Pd * S)/(Pl * E)

So if I were to thread 8 TPI, Rp >1 (2.34375) if encoder_resolution = 1024, but Rp < 1 (0.585) if encoder_resolution = 4096. So knowing the right value of E (encoder_resolution) is important.

Stepper resolution is also relevant. you can use less micro steps to get the ratio smaller for larger threads. What kind of lathe will you be using? It has an upper bound on what threads it can cut from a rigidity perspective. If you implement 4 quadrant bresenham this isn't an issue. I haven't bothered yet.

What do you do if (Pd * S), or (Pl * E) are not integers? Round them and calculate the error?

the esp32 is pretty fast so I just use doubles and floats. Likely teensy can do the FP math.
Also, for your stepper motor controller, is the microstep (number of microsteps per step) software programmable? On my junk stepper driver, the number of microsteps is set by a dip switch, which would not be good for a real application.

microsteps can be done on the fly but most drivers are set via dipswitch or jumper. you want to save the microsteps as a config var and store in NVRAM if possible.
 
Back
Top