Adding capabilities to my ELS system

[WobblyHand]

Thought I'd start a thread about adding some extra capabilities to my completed ELS system that I created for my G0752Z/G0602 lathe. The ELS is documented at https://www.hobby-machinist.com/thr...ad-screw-controller-using-a-teensy-4-1.99609/

What I'd like to do is to add the following capabilities:

1. Feed to a stop
2. Thread to a stop
3. Multi-start thread to a stop

 

[WobblyHand]

If you recall, my ELS has a touch screen interface, a Teensy 4.1 micro-controller, and an integrated two axis DRO. It currently can do 25 imperial threads, 24 metric threads, 9 imperial feeds, and 10 metric feeds, and will support other values, but I haven't entered them into the tables. I made a design choice to limit the number of entries to a single page, that can be easily selected by a finger tip. This was to keep the display programming simple. At some point, I may add the algorithm to compute the correct ratios inline. Currently they are computed offline, but are easy enough to add.

What my ELS isn't: A CNC lathe. However, I wish to add some features that while manual, augment the capability of the lathe. The goal is to make this easy to use, and hopefully, intuitive how to operate. Currently, the spindle motor is controlled by a VFD, which is not connected to the ELS. I replaced the original 0.001" resolution DRO's with 1um glass scales. There is no external DRO controller, the DRO display and updating is done in the ELS.

To get ready for these changes, I made a branch in my software repository, called feedtostop, and changed branches. This preserves my fully functional "production" ELS code, should I ever wish to revert to it. One thing that I did in the main branch, was to disable my ELS via disabling the spindle encoder. It was an early design choice, which I need to change. It does work, but it will make adding capabilities a little harder. Disabling the encoder starves the stepper algorithm of updates, so the stepper driver never receives stepper pulses. But this makes the whole system blind to the spindle position. It works ok for simple feeding and threading. But it will prove problematic for positioning to a stop. My new approach will be to gate the stepper driver pulses, but keep the spindle encoder active all the time. My spindle encoder uses signed 64 bit integers, so practically speaking there never should be a rollover issue to worry about, even at the highest speeds and leaving it on for years.

Made the gating changes just now, and need to test it. Hopefully this won't blow up in my face right away! Once the normal functionality has been proven with the gating change, I can start to plod through item #1, feed to a stop. For that to work, I will need a way to enter the end point, and a fool proof stopping mechanism that doesn't chatter at the end, as well as a way to simply restart the feed again.

 

[WobblyHand]

Well, almost. Seem to have introduced a small bug that I am chasing down. Was using a flag called encoderactive to gate changes like changing the thread handedness in the original code. I commented it out. So I couldn't change from a right hand to left hand screw. Err, that wasn't so good. Threading and feeding seemed to work though. Think I have that bug sorted out now. Lets try again...

 

[WobblyHand]

Still have an interesting bug that I haven't seen before. (At least I have never seen it in the main branch!) It's metric only. If I change handedness, the pitch of the thread is changed once! How that can happen, well that's a mystery to me at the moment. I will have to dig into that. I do handle metric differently, perhaps I pass the pitch incorrectly to the display. Step by step you have to beat the bugs back. Definitely feeling better about branching the code. I'd be very unhappy with myself if I hadn't done that. I can always revert back to a working system.

 

[wachuko]

I am here just waiting for the video...

 

[WobblyHand]

I am here just waiting for the video...

Ha ha! If you are waiting for a multi-start video, it will be quite a while... On the other hand, the base system works very well. I giggle every time I use it. No gear changing, simple user interface, as a project it far exceeded my expectations. Will do any thread I want, as long as I can figure out an integer ratio. Hopefully these new software add-ons will make it even better, by reducing the pucker factor of feeding and threading to a shoulder. Getting multi-start would be icing on the cake.

The hard part has been trying to wrap my head around some of the program details, more than 8 months after I completed the main branch coding. I documented a lot in the code, but it's a tougher slog than expected after an 8 month layover. Think I understand (most of) it again.

 

[GHamsz]

Sounds interesting, I'm just getting started with my ELS based on a raspberry Pi Pico W. I'm fairly proficient with the integrated state machines so my design utilizes them to "hookup" the encoder to the stepper. The processor provides the user interface, and computes the control words that drive the state machine. Once the feed has been programmed into memory it will be DMA'd to the state machine, and from that point, the processor is out of the loop. The beauty of this approach is any load speed changes while threading are handled automatically.

It's all working on the bench for all metric and ANSI threads, feed rates are defined for 1/10,000 to 10/1000 of an inch.

Today I got the stepper mounted, tomorrow the encoder.

 

[WobblyHand]

Sounds interesting, I'm just getting started with my ELS based on a raspberry Pi Pico W. I'm fairly proficient with the integrated state machines so my design utilizes them to "hookup" the encoder to the stepper. The processor provides the user interface, and computes the control words that drive the state machine. Once the feed has been programmed into memory it will be DMA'd to the state machine, and from that point, the processor is out of the loop. The beauty of this approach is any load speed changes while threading are handled automatically.

It's all working on the bench for all metric and ANSI threads, feed rates are defined for 1/10,000 to 10/1000 of an inch.

Today I got the stepper mounted, tomorrow the encoder.

Will be interesting to see your progress, in your own thread. It's all good fun on the bench. It gets quite interesting when hooked up to a lathe, especially with coarse threads - especially if your stuff doesn't quite behave the same as on the bench. That can be a challenge. It is rewarding when it all works. At least for me, the user interface and setup were a lot more work than just getting stuff to work. Lots more code in the UI than controlling the motion, probably five times more, if I recall. I never worked as a professional software developer, so the UI took me quite a while to work out.

 

[GHamsz]

Will be interesting to see your progress, in your own thread. It's all good fun on the bench. It gets quite interesting when hooked up to a lathe, especially with coarse threads - especially if your stuff doesn't quite behave the same as on the bench. That can be a challenge. It is rewarding when it all works. At least for me, the user interface and setup were a lot more work than just getting stuff to work. Lots more code in the UI than controlling the motion, probably five times more, if I recall. I never worked as a professional software developer, so the UI took me quite a while to work out.

I'm a retired EE, with 30yrs in telecom designing boards and systems utilizing embedded controllers (micro computers). The last half of my career was managing teams, but for fun I'd play around with small embedded controller projects.

The UI was straight forward, since I had libraries I could draw on from my previous home projects. I selected the Pico W for the state machines, but also for the included Bluetooth and wifi interfaces. I thought I'd control the ELS from my phone, but the 4 Line LCD is providing all I need now, so Bluetooth and wifi will be a while.

 

[WobblyHand]

In my case, I did have some libs for graphics that I had used for a Doppler chronograph that I made, which helped some. But I chose a touch panel display for the UI, which required me to create many menus and soft buttons and other design elements to make the system intuitive to use. Spent quite a bit of time on that, primarily because many of the libraries I found were hard to use within my framework. Most required rearchitecture of my code and I saw a lot of work and the real possibility of breaking my application. Didn't want to risk that. I'm a SW idiot, so if I can't get it to work from the examples, even after contacting the author, I'm not using the library. So I had to develop stuff from primitives, which was time consuming. Still, I learned something, so it wasn't that bad.