An Electronic Lead Screw controller using a Teensy 4.1

Sorry if you discussed this, but what is limiting your top speed? (Why do you need to dynamically change microstepping?)

Edit: am I correct that it's to get increased torque from the motor by reducing microstepping where possible? If you aren't close to the top speed, you can use mechanical reduction also?
My fear of the chuck exploding! The Teensy is capable of keeping up with the spindle encoder interrupts.

The reason for changing microstepping is only to accommodate the biggest pitches, or the lowest TPI threads. The Bresenham algorithm requires the ratio to be less than 1/2, I believe. To do that, pitches like 5mm or 4 TPI need to have ustep = 4. This is because ustep is in the numerator. I could change the lathe gear box I suppose, but I have no feedback to the Teensy that the gearbox was indeed changed. As it is, I can handle all the pitches and threads by simply leaving my QCGB at 1:1 ratio, except for the threads noted.
 
The reason for changing microstepping is only to accommodate the biggest pitches, or the lowest TPI threads. The Bresenham algorithm requires the ratio to be less than 1/2, I believe.
That's the part I'd like to understand. You described before that encoder pulses trigger an updated stepper pulse train. With finer microstepping, you'd just have to output more stepper pulses between encoder pulses. Seems like that should be limited only by the upper limit on pulse rate?
 
That's the part I'd like to understand. You described before that encoder pulses trigger an updated stepper pulse train. With finer microstepping, you'd just have to output more stepper pulses between encoder pulses. Seems like that should be limited only by the upper limit on pulse rate?
I misspoke. The simple Bresenham line algorithm only requires a slope < 1 to be valid. For references: please see Bresenham Line Algorithm and Didge

The slope of the line is given by the ratio of N/D where

N = leadscrewTPI * basestep * microstep
D = desiredTPI * encoder_resolution

To get the desired TPI with a slope < 1 we need to reduce the number of microsteps at times, not to increase them, especially if desiredTPI << leadscrewTPI. Understand? So if N>D the algorithm doesn't work properly. Therefore we need to reduce the number of microsteps/step.
 
I was thinking of something like this discussion in Dodge:
For use cases where even a higher ratio is desired there are techniques we that can be used. One example is to generate intermediate step pulses between Bresenham steps. We can space them in time accurately (within the limits of the timer resolution) if we keep track of the input speed.
 
Been reading about an ELS quite a bit. It seems the TI controller board is out of stock, and has been for at least six months. The Teensy 4.1 processor seems to have the guts and software support to...

Just a replay to subscribe to the thread...

Starting to collect parts to build my own ELS. So, very curious to see how this one turns out.

Dan
 
I was thinking of something like this discussion in Dodge:
Ah, yes. A more advanced, or sophisticated approach. At the moment, can't say if it's necessary. My choice is to take a simple approach and only change if it proves inadequate. My code is dead simple and consequently it's easy to debug. I got the motor control working in one day. I'm reluctant to have adaptive timing for the pulses, simply because it is really hard to diagnose when things go wrong. If I was directly driving the motor currents, it actually would be easier. But I am driving the motor through another device, who's algorithm is not public. In light of that, my general approach is KISS. Only change if necessary. So far, at this stage of integration, I don't think that those changes are required. My SW is at V0.02. My HW is at V0.1. There will probably be some changes, as time goes on.

I haven't made significant changes in the SW yet, because I'm running a lathe with a vulnerable assortment of flying leads and exposed electronics. It's not exactly a stable platform. By that I mean if you wiggle the wires by moving things on the bench, sometimes weird stuff happens, like the display doesn't come up. This is due to the solder less breadboard contacts being intermittent. These abominations are great to cobble together an idea, but they are awful for reliability. I've experienced this before many times. That's why I designed and ordered PCBs. Once I get them, assuming they are usable, then real development can continue.

One thing I know for sure is I can edit a couple of values in the thread table to get a few more coarse threads, since the slope limit for my algorithm is unity, not 1/2. I was conservative in my implementation, not knowing how anything would work. I just enter the system values and the desired TPI. The SW doesn't care if the values are big. But I usually simplify the fractions so the numerator and denominator are the smallest values of that ratio. When I select a thread or pitch I display N and D. A production version of the SW wouldn't need to display the internal values. I only displayed the value for the sake of defensive coding. Giant numbers display poorly.
 
My Omron E6B2-CWZ6C has open collector outputs! However, I have to power the encoder with 5V-24VDC. So I could power the encoder with my 24V supply...

Let me apologize in advance. I may be spamming this thread for a while as I read through the backlog.

Are you guys certain you have actual Omron parts? These encoders are typicall $450 to $650 through distributors. I'm seeing what I believe are chinese knockoffs on ebay/amazon and similar sites for under $40 us.
 
Let me apologize in advance. I may be spamming this thread for a while as I read through the backlog.

Are you guys certain you have actual Omron parts? These encoders are typicall $450 to $650 through distributors. I'm seeing what I believe are chinese knockoffs on ebay/amazon and similar sites for under $40 us.
Actually I have no idea if it is counterfeit or not. I do know that the one I have works to 890 RPM, because I tried it yesterday. Probably 100's of others have built ELS systems using this part, sourced on eBay. This is the encoder Clough42 used. My encoder seemed to come from Omron, it came with datasheets, a little shaft adapter, and even a tiny allen wrench. The nicely printed datasheet is identical to what I found online.

I think you found some distributors are not shy about charging their well heeled customers, to enable paying for valuable customer support. I am not expecting customer support for this unit, if it dies, I will get another one, or its equivalent. If this were for a commercial or bespoke big, high dollar system, I'd go through normal distribution channels. But this is just for me, and I am cheap. That being said, how do you know if ANYTHING you buy is authentic? The more the authentication, the more dear the part. You want full traceability, like space qualified, you pay.
 
I think you found some distributors are not shy about charging their well heeled customers, to enable paying for valuable customer support. I am not expecting customer support for this unit, if it dies, I will get another one, or its equivalent. If this were for a commercial or bespoke big, high dollar system, I'd go through normal distribution channels. But this is just for me, and I am cheap. That being said, how do you know if ANYTHING you buy is authentic? The more the authentication, the more dear the part. You want full traceability, like space qualified, you pay.
Yesterday, Looking on ebay, you see differences in labels of the 'Omron' parts. Some have different fonts, others have different color backgrounds, etc. Clear signs of something shady going on. To be clear, I have no problem paying $40 or $50 for a real Omron encoder. :) I don't even have a problem with spending $40 on Chinese encoder with a genuine Chinese label! :) I do take issue with a knockoff copy of a known good vendor with what is most likely substandard parts (or even grey market parts.) I don't think traceability is necessary, but buying from a vendor like Newark, Mouser, Digikey, etc you are pretty much guaranteed to get genuine parts. Having battled counterfeit/copied items in the past, its something I'd prefer to avoid going foreword.

Also, In my case I just dropped a lot of cash on rebuilding (machining and scraping) this old lathe. So, a few hundreds dollars on a good encoder is cheap insurance IMO.

Anyway still slogging through the thread. Lots of good info and thought processes going on here!

Dan
 
Lots of good info and thought processes going on here!
Hope you find them of use. Whether it is all 100% correct or not, time will tell.

I have had issues with counterfeit or substandard parts. But buying this encoder, from a recommended p/n, turned out ok. The box looked authentic, the part looked authentic and the docs matched up. I go out of my way to avoid what I think are shady parts or suppliers.

That being said, I would never hook up a totally unknown part for the first time on a machine and expect it to work! Or trust that a brand new bunch of recently fabbed parts would just work. I tested the rotary encoder while I was developing code. I have reasonable confidence that my encoder is not junk. I did cut threads using the encoder, and the threads fit their corresponding nuts. My approach to integration is to do it bit by bit, not all at once. That way I am assured that the subsystems are ok, before dealing with the whole system.
 
Back
Top