An Electronic Lead Screw controller using a Teensy 4.1

[AlanB]

Clough tested about three different motors as I recall. They all worked. 8-10 microsteps are used widely used across CNC and many other projects. Even if the torque is reduced a bit at the microstep precision the smoother motion is desirable. As was mentioned the higher torque motors need higher voltage if speed is important, 48-60V is often used. Clearpath servos seem to be the high road, but spending $600 might be hard to justify since everyone seems to be successful with pretty much all of the steppers.

The closed loop steppers definitely have serial tuning software, but the protocols are not open that I've ever seen. Even getting the right program to adjust them is often a major undertaking. The defaults are often used.

 

[WobblyHand]

Phew. Fixed a crazy bug in my program. I found out that if one calls Serial.print too often, it can cause the processor to reset! I was testing at 400 KHz counts/second which is far greater than any stepper can do, and after a while my board would reset! Turns out I was attempting to write out the encoder count that often - not good. Fixed that and the encoder can follow up to 400 KHz encoder counts per second and update the ILI9341 display at 10 Hz with the RPM value. This is encouraging.

Now back to designing display windows...

 

[WobblyHand]

After much flogging about, have a few buttons on the screen. I have much to learn for user interfaces. This is nowhere near done or complete. What is nice is the RPM is actively updated from the stimulus and the rest of the display is static. I manually selected the 5th item in my threading table, and the display output the correct TPI. One has to be gratified for the little things that actually work. My encoder simulator sent a 234.4 RPM signal to the Teensy, and it output the display live, updated every 100ms (no filtering or smoothing, just counts / 20 ms converted to RPM). The stepper is controlled by the correct parameters to create a 11.5 TPI thread, with the correct values of N and D sent to the Bresenham algorithm. At this spindle speed, I am also stepping the motor. Stepper speed is Counts/sec * N/D = 16000 * 51/125 = 6528 microsteps/second. This is a picture, while the encoder simulator was active, and the stepper was running.

Lots more UI work to do, like a setup menu, a thread size menu and a feed menu. How I'm going to implement it, not sure, but I will figure it out. Just getting the basics down.

 

[AlanB]

Nice progress!

 

[WobblyHand]

Need to debounce the buttons, but have touch sense enabled on the setup, start and stop buttons. Added a picture of my lathe to the display screen, it was my first threads I cut on my Grizzly G0752Z. Not a great picture, at 160 x 120 pixels, probably put in a nicer graphic. Did it, because I could. Tomorrow, I get to design the threading setup screen. If I'm feeling ambitious, I'll do the feeding menu as well.

 

[WobblyHand]

Slowly working through the display aspects. Have the threading screen partially operational. It is entered when the yellow Setup button is pressed. If one pressed the Imp/Met button, it toggles between Imperial and Metric. If Imperial is selected than TPI is shown, if Metric, then the box label changes to Pitch.

I was going to put in a partial display of the thread table, which somehow I will make scrollable via the up and down buttons. If you touch the line with the desired pitch and select it, upon saving the new parameters will be loaded to the controller. This would be a lot easier if I was a better C/C++ programmer. I pick up my K&R book and read through it, and still don't understand quite a bit of it. And that really bogs down development. Have to write separate programs to test out ideas, even as simple as using structs. Wished I actually took classes on the subject, but that's water over the dam... Maybe that's why I never made a living working as a programmer.

Eventually, I will delete N & D from the display, since the operator could care less. uSTEP is only important for very coarse threads. Not sure what my strategy will be, since it seemingly will require a dip switch change on the driver, which I think is ghastly. For now, I will avoid 4 TPI and 5mm threads. The error is actually the 10 pitch error relative to a single pitch converted to %. As long as that error is 1 % or under, your ten pitches of that thread will work out pretty well. For instance, for 1.0mm pitch, with the values of N and D computed, the 10 pitch error relative to a single pitch is only 0.26%, or after 10mm, (10 threads) the pitch has increased to 1.0026mm. I think that will be good enough for me, but I do need to calculate the cumulative error.

 

[WobblyHand]

Well, I did get the table in there, but I only can fit 8 rows at a time. Think I will dump this part of the display for an array of buttons which are easier to select, and I don't have to futz about learning how to scroll stuff. I have 22 imperial threads and 21 metric threads. They will each fit in an array of 5 x 5 buttons. I may display the selected button's data. A save should load the parameters to the main staging area. If I press start then those parameters should become active. It's been interesting thinking about how to make sure nothing bad is allowed. The state machine is growing and getting pretty complicated.

 

[jwmelvin]

I’m enjoying watching your development, thanks.

 

[macardoso]

I've mostly been following, but why are you limited to selecting a thread with some (seemingly significant) error %? Is this a function of the discretization of the encoder/motor pulses? Or a concern to stay away from floating point math?

 

[WobblyHand]

@macardoso the issue is that position and stepper pulses are discrete. Not sure how to emit a discrete stepper pulse after some arbitrary ratio, but I suppose it can be done. The Bresenham algorithm was used to plot pixels on a screen and this is an adaptation of it. There's some error, let's call it quantization error. The error I computed is how far off the thread is after 10 threads are cut compared to a single thread pitch x 100 to give me per cent. I can lower the error by choosing a ratio that is closer to the correct one, but there's nearly always an error.

A lot of gear ratios on our lathes are not exact either, but we live with it as long as the error is small enough. My error values are quite magnified, because it was difficult for me to imagine normalized single pitch errors of say 0.0002 mm/mm. A gear table would probably call the above error 0. In my chart that is displayed as 0.2% error over 10 pitches. Hope my explanation helps. If not, or you think I have made a mistake, please let me know.

Edit: added at "name" so macardoso would receive notification of my response. Forgot to directly reply.