An Electronic Lead Screw controller using a Teensy 4.1

[WobblyHand]

Oof, of on the wrong foot. Arduino doesn't seem to know that the way to make desktop launchers changed in Ubuntu many years ago. So they created a semi-worthless launcher. It is just a text file. At least I have a clue what the "install" did. "Install" is a misnomer, it just seems to be execute in place. The install did not affect the Arduino IDE that Ubuntu knows about. That is the older IDE 1.8.13.

I do not know how the above affects the Teensyduino install, if at all. Guess I'll ask that on PJRC, as it is very PJRC centric question.

 

[greenail]

At 3600 RPM (max lathe speed) that is 60 rev/second. For a 1K encoder, that is 60K codes/sec and 240K edges/second. Roughly 4us. I don't think I have ever gotten my lathe to spin that fast, I'd be afraid of some disaster! At half that speed, there would be 120K edges/sec. Running the Teensy at 600MHz, means the processor can execute 5000 instructions in that 8.33us.

My code calls the motion planning on every encoder interrupt.

ESPels/motion.cpp at 796a64ffa15a9f0e5b8ecc185d0486c0ae6055ef · jschoch/ESPels

ESP32 electronic leadscrew for a lathe. Contribute to jschoch/ESPels development by creating an account on GitHub.

github.com

For threading the processing speed is likely moot. My encoder is 2400 CPR, 600 PPR

Clough42 mentioned something on his repo, that I don't think was right. Essentially he warned about the Teensy quad decoder rolling over more often. I just looked this up and the T4.1 register length is 32 bits, the same as the TI chip. Don't know if that was FUD or he was going by some old information. I'm not taking anything away from him, he was clever to pull this off using a cheap launchpad. Think the form factor of the Teensy is a bit better.

i'm using int64_t for the position counter.

 

[greenail]

Oof, of on the wrong foot. Arduino doesn't seem to know that the way to make desktop launchers changed in Ubuntu many years ago. So they created a semi-worthless launcher. It is just a text file. At least I have a clue what the "install" did. "Install" is a misnomer, it just seems to be execute in place. The install did not affect the Arduino IDE that Ubuntu knows about. That is the older IDE 1.8.13.

I do not know how the above affects the Teensyduino install, if at all. Guess I'll ask that on PJRC, as it is very PJRC centric question.

I use vs code and platformio, not a fan of the arduinoIDE.

 

[WobblyHand]

it only reads the spindle encoder. Fridge DRO was a completely separate project.


I don't have much documented, the contoller it isn't that much different than I explained. The websockets and react are a bit more complicated but there are plenty of tutorials available on both. I used react hooks, but you could use just about whatever you liked. The big simplifier is the arduinojson library which serialized/deserializes the data over the websockets. You can use plain old json or move to binary optimized when you have it working.

Ah, ok. Thanks for clearing that up.

Thanks for the tip on arduinojson lib. In the past I have had to push binary, because of the volume of data, or the datatype. json at least in the past didn't know about complex numbers, or even for that matter floating point. I will check it out.

Too bad on the docs. I have learned to heavily document at least my source code. If I have a break, of say a few years, I'd be hard pressed to know what the heck I did. This is especially true of anything tricky I figured out. In my work life I saw many times where code used to work, doesn't anymore, and no documentation to support it. The solution was to throw away the code base, write new code and documentation. It was not efficient, but at least the code was supportable in the future. For myself, I am my own support. I am the poor slob who has to pick up the pieces. So I have forced myself to document my code. I have found my own docs to be very useful, as I can basically understand and reuse stuff pretty quickly.

 

[WobblyHand]

Small victory. Got Arduino installed/updated and have Teensyduino added. I did get the ethernet attachment, so I will try building that (assemble and solder) to see if I can attach to my laptop. I think it is only good to 100Mbit, but that's plenty good for many things.

After a bit of a struggle with example programs that just don't freaking work, I got Ethernet to connect to google and download some data. It's disappointing to see these non-functional examples being downloaded with libraries. But by combining the results of two ethernet libs, got the webclient to connect. Downloaded 336645 bytes in 3.931 seconds, hardly a world beater, but better than a dialup! 85.64KB/sec. Can't wait for the encoder and stepper to arrive.

 

[AlanB]

For testing you probably want to program another micro to generate quadrature encoder signals, so you don't actually need the encoder to get started. Testing with a real encoder is not very efficient for software development.

 

[jeffkash]

For testing you probably want to program another micro to generate quadrature encoder signals, so you don't actually need the encoder to get started. Testing with a real encoder is not very efficient for software development.

Clough42 has arduino code to generate the quadrature encoder signals.

 

[WobblyHand]

For testing you probably want to program another micro to generate quadrature encoder signals, so you don't actually need the encoder to get started. Testing with a real encoder is not very efficient for software development.

True, but coding a simulator is risky in the sense that you write code on your main platform that runs against the simulator. The risk is the simulator really isn't like reality. I've seen that a lot. That said maybe I can cobble together some cheapo arduino to generate a signal train.

 

[WobblyHand]

Clough42 has arduino code to generate the quadrature encoder signals.

Great! Thanks.

Found it, but there's no info on what arduino. I don't own a normal arduino, whatever that is anymore. (An AVR device?) I have an 32u4, an M0, and a M4 device to choose from. So the code isn't plug and play. Oh, well. Guess I will have to dig into it. At least it is a start!

 

[AlanB]

ELS Electronic Lead Screw Gearbox Musings

Encoder

2000 rpm lathe spindle
1024 line rotary encoder, 4096 edges per rotation
33.3 rotations per second, 136,533 events per second

Motor

200 steps per rotation stepper motor driving gearbox to leadscrew and feed system
8 microsteps per step (common choice)
1600 microsteps per rotation

Processing

So how hard is it to manage this control?
Pi Pico controller, 133 MHz, 974 clock cycles per encoder edge (one core)
Teensy 4.1, 600 MHz, 4,394 clock cycles per encoder edge

If we use a simple encoder edge driven state machine approach using fractional ratios less than one we can get exact fractional gear ratios and generate output step pulses with very little code. This would allow electronic gearing up to 4096/1600 or 1:2.56, which, in combination with the gearbox on most lathes is more than enough. If higher ratios are needed then a higher resolution encoder can be chosen or a lower microstep value can be used.

The Algorithm

Find the encoder edges, either with interrupt on pin change or by polling or by using the quadrature input hardware (which probably adds more complexity than required here). In the case of the Pico a separate core can be dedicated to the realtime control algorithm so continuous polling is easy.

When an encoder edge occurs the fractional numerator of the ratio is added to an accumulator. If the accumulated sum is greater than the denominator the denominator is subtracted from the accumulator and an output motor step pulse is generated. This is essentially a one dimensional version of the Bresenham algorithm.

Embellishments for directional control will be needed, and debouncing if the encoder edges are not clean. I use a lookup table to decode the quadrature and it gets directional information and filters out bounces, but there are many ways to handle this.

There is no need to worry about acceleration and deceleration as this is a gearbox following the spindle, the physics of which will control the acceleration and deceleration. The simplest approach is to allow changing the fractional ratio (electronic gearshifting) only when the spindle is stopped, but there are ways of synchronously adjusting the fraction while running if that is desired. Adjusting the ratio too quickly (while in motion) might cause issues with some motor controllers. Slowly adjusting the gear ratio during feed adjustment while moving is not a problem. During threading there should be no need to adjust ratios while the spindle is moving.