Electronic Lead Screw

I do have spare PWB's, but I'm not a vendor, nor am I trying to sell them. I've found that supporting a technical product is a lot of work, and it's tough to make money at it, due to the required technical support. Can't leave a customer high and dry. At least that's the way I was brought up.
 
I've thought long and hard about implementing one of John Dammeyer's ELS boards, to get a handle on this ELS thing.
 
There's a number of them to choose from now, including one "package" that I found on Aliexpress that includes the whole bundle with stepper motor, interface, and gears to suit a variety of installations. Some appear to be slightly more plug-and-play, although that's the wrong term in this case.
 
I believe that the Clough42 ELS requires the Launchpad because of the relatively convoluted way (IMO) in which he synchronizes the lead screw to the spindle. It works but it requires some computing horsepower to do it. Clough initially tried an Arduino IIRC but rejected it because of inability to process in real time. There are a number of other schemes that are documented in this forum that are more efficient.
 
There's a certain thrill in squeezing out the most from a given processor. It is hard to justify the extra work with a low volume product though.

I'm guessing that a Teensy 4 or an RP2040 could be asleep much of the time, even with such a high resolution encoder at 3000RPM. If I ever get around to making an ELS myself I might go with the RP2040 with WIFI/Bluetooth. I think it costs $6 or something like that. The RP has two fast 32 bit processors and PIO that can be programmed to do encoders or a step/direction output etc. From what I've gathered, it would be quite possible to make a 64 Bit encoder interface in the PIO/second processor with a whole other processor to do communications, display control or whatever else is needed. Well, maybe someday after the other projects and family stuff going on ...
 
A Teensy 4.1 has proven to work with no problems. It might be overkill, but I've worked on projects which sank commercially because management chose an underpowered microcontroller - that's because they had no idea how much performance they needed to do the job. I can tell you with certainty that "that job" was the pits. We didn't succeed until the manager was replaced and the processor ungraded. Wasted 12 months of fruitless development.

An RP2040 might work, but I haven't analyzed it.

The limiting factor is processing the encoder interrupts for spindle angle, determine a 64 bit count and determining if the stepper or servo needs to move. The maximum encoder speed is 100 KHz, at least for the encoder I chose. That's 10 microseconds between interrupts to do everything AND have time left over to do other mundane things, like responding to buttons or whatnot. In my case, I also update a display with RPM, and update the DRO readout using 1um scales. The processing demands would be lower with lower resolution encoders and DRO's.

It was an interesting and fun exercise, as well as a lot of work. The most tedious part was the human interface. It's not that easy to make an intuitive interface, at least for a person that didn't program for a living.
 
For my own education, how did you arrive at needing a 64 Bit counter for the application? Do you think a 32 bit counter could be sufficient?
 
If you left the spindle running for hours at a time ( lots of hours, but less than a day) at higher speeds, the count will overflow 32 bits. Going to 64 bits prevents it from occuring. (Overflow occurs in 64 bits in longer than a year.) Practically, not that likely, but possible. I had dreams of releasing software, and I take safety seriously. I wanted to essentially prevent overflow. So I implemented it with 64 bit math. It's not that easy to test this kind of problem, especially on an Arduino platform. If there was an ICE, maybe I would think differently.

On my processor of choice, Teensy 4.1, using 64 bits has practically zero overhead. Might have a far bigger impact on weaker and less capable processors. I'd rather be a sport and spend $32 on the processor than being hamstrung by an inadequate processor. Already lived that experience once, my development time is more valuable than the $28 I would save for a cheap processor. My ELS runs, so my choice paid off handsomely for me.
 
Great, thanks. I got "hours of operation" at 32 bits too. Just checking my sanity. I think Clough42 handled the overflow in software by informing the stepper drive logic of the overflow and just "zeroing out" things if it happened so the stepper driver logic doesn't sense that it is way off suddenly.
 
Cool about your LeBlond @Dabbler , but I don't recall seeing the original post in this thread. Is this a mispost? This thread is related to ELS things.

DOC's like you describe are far beyond the capabilities in my shop, they seem industrial as opposed to the dabbler that I am. Typically I'm happy if something looks roughly like my drawing, and it hasn't taken me a month to make!
 
Back
Top