electronic lead screw

I'm not talking about Clough42's implementation. I started this thread to generally talk about ELS, somehow 80% of the posts are about Clough42's nice ELS but this is just one way to skin the cat. I have my own implementation and I can do whatever I want with it.

If you think about it what is required to successfully cut a thread, when the spindle is ina particular orientation, there is a define set positions of the carriage allowed. That set is uniformly spaced by a distance equal to the thread pitch. If you disconnect the lead screw driver from the chain, you will destroy that link. The same if you reverse the direction or change the feed rate/pitch. You can verify the latter two easily with the existing Clough ELS. When you reach the end of a pass, reverse the feed and back the cutter out and back the carriage up for another pass. The consequences of changing the feed rate or pitch is obvious enough not to require an actual run.

Again, you are stuck thinking about Clough's implementation where he is only trying to simulate change gears. This simplifies the implementation but it is a very limited approach. My controller keeps track of the spindle position, it can "wait" for the right time to re-engage leadscrew motor without the user having to do anything.

My attempt to do this in a straight forward manned using the driver enable failed.

This doesn't work because the motor loses position when you disable the driver. You can stop driving the motor without losing position. You don't want to disengage the half nuts because this will lose the sync between the spindle encoder, the carriage position, and the controller. Assuming the lead screw stays engaged you can then rapid back to your thread start manually, or even better if you have set a virtual stop my controller can do it for you. Then it simply needs to calculate when to re-engage the motor. It is just like using a thread dial but you don't disengage the half nuts. I thought I described this above but it seems words have failed me :(
 
Sorry, I thought we were talking about the Clough ELS. If your controller reads the position of the spindle, then yes, it is possible to disengage the motor and properly re-engage it.
 
I also think the Clough42 ELS didn't go quite far enough. Having a spindle encoder with synch pulse, and being able to stop the carriage motion at specific memorized spots, as well as reacting to a stop input would be excellent, without going to a full CNC setup. Definitely have those on my list for an Electronic Lead Screw if I make one. I was looking at a 600 mhz Teensy board the other day that can be programmed with Arduino tools, much easier to work with than the proprietary licensed Texas Instruments software. As I recall the Teensy has real encoder inputs as well. More than one way to implement this stuff. Good to see other implementations to think about.
 
I also think the Clough42 ELS didn't go quite far enough. Having a spindle encoder with synch pulse, and being able to stop the carriage motion at specific memorized spots, as well as reacting to a stop input would be excellent, without going to a full CNC setup. Definitely have those on my list for an Electronic Lead Screw if I make one. I was looking at a 600 mhz Teensy board the other day that can be programmed with Arduino tools, much easier to work with than the proprietary licensed Texas Instruments software. As I recall the Teensy has real encoder inputs as well. More than one way to implement this stuff. Good to see other implementations to think about.

The teensy 4 is a beast!

The stm32 "blue pill" also has hardware quadrature encoders and is only a few bucks. The "black pill" is $4 and is a bit faster/more capable.

My ELS is using the esp32 which has multiple cores and you can offload the button/input management and wifi while also doing the step generation. You can also generate the steps with the RMT peripheral or expand the IO by using the i2s peripheral and a few shift registers. This is what Bart Dring's GRBL implementation does and it works well. IMHO having wifi allows you to use your phone to configure the machine parameters and simplifies the overall UI by quite a lot since you rarely need to configure those parameters. Lots of buttons can be omitted. This then goes back to my idea of using a small gimbal motor with haptics to provide the majority of the user inputs.
 
There's a lot of good hardware out there. Part of the process is choosing what one wants to work with in terms of tools. Many good choices.

One annoying thing is how quickly some of these development tools "corrode". A few years down the road they have changed so much they don't work anymore on previously developed projects. Used to use raw AVR chips and development tools, was nice to have a real "C" compiler for a whole range of small inexpensive chips. Arduino came along and made the tools easier to keep working, though they did break things a few times. It is nice to read completely through the hardware documentation, unfortunately now that's become many thousands of pages for each chip, not really practical to deeply understand all the various parts anymore. I still have one of the TI motor development kits that used open hardware on the shelf here, but they've abandoned that route. My next project along these lines is to put LinuxCNC and Mesa cards in control of my PM-728VT mill, then perhaps after that I'll get a new lathe to tinker with. Too many irons in the fire already... Best of luck with your ELS, I'll be following along.
 
Look up clough 42 on YouTube
He has a extensive video series on it and is selling new circuit boards to run the whole thing and where to buy the rest of the parts.
 
Look up clough 42 on YouTube
He has a extensive video series on it and is selling new circuit boards to run the whole thing and where to buy the rest of the parts.

See post 11 in this thread. The majority of posts in this thread have been about Clough42's ELS.
 
Back
Top