Multi-start threads on a lathe, working through how to do it

[rabler]

Since your ELS has access to Z position, another approach would be to replace the mechanical thread dial with an electronic indicator showing correct leadscrew engagement. That could be calculated for any thread pitch (i.e., metric threads with imperial leadscrew).

 

[WobblyHand]

Isn't "Simple matter of coding." an ancient Chinese curse?

Perhaps. I find that once I fully understand the physics/geometry behind something, that the coding is "straight-forward". It takes me a while to get the full understanding, actually well over 50% of the time, but the coding is mostly plodding along to get there. Coding something complicated that is adhoc, usually doesn't end well, at least for me. Sometimes I write out the strategy in steps, then implement it in code. Works pretty well for me.

 

[WobblyHand]

Since your ELS has access to Z position, another approach would be to replace the mechanical thread dial with an electronic indicator showing correct leadscrew engagement.

You mean effectively a half nut switch? Or something else?
I know Z (and X) to 1um, but don't know if the half nuts are engaged. Nor do I know which engagement on the thread dial. As far as I can tell, the half nut will engage in four places between each number on the dial. So from 1-2, the half nut can engage at 1, 1.25, 1.5, and 1.75.

 

[rabler]

You mean effectively a half nut switch? Or something else?
I know Z (and X) to 1um, but don't know if the half nuts are engaged. Nor do I know which engagement on the thread dial. As far as I can tell, the half nut will engage in four places between each number on the dial. So from 1-2, the half nut can engage at 1, 1.25, 1.5, and 1.75.

Not a switch on the half-nut. A visual indicator of when to engage the half-nut.

This is kind of a fun thought exercise, I wish there was an easy way to draw formula and pictures on a forum.

By knowing Z, any time the spindle is turning, the ELS knows whether or not the half-nut is engaged.

You can calculate expected Z based on initial Z and spindle turns. Zexpected = Z0 + (spindle theta/360) * (1/TPI)
(That measures theta in total degrees, not modulo 360.)

If Z not equal Zexpected then the half nut has been disengaged. Count spindle rotations until Z and Zexepcted match When that is true, light up "electronic thread dial". Just like a mechanical thread thread dial, you can move the carriage by hand crank, or leave the carriage in place and run the motor, and this will detect when they align.

This will work regardless of pitch. But it does not take advantage of potential multiple locations one the leadscrew where there is periodic re-alignment, although that could be calculated. Practically it would require more than a simple light because the operator needs a "nearly there" warning.

 

[rabler]

The above is not quite the same as a thread dial, as it is a more binary indicator of alignment between Zexpected and Z. So it doesn't have the period repeating nature of a thread dial. If you let the spindle run one million revs forward, you'll have to back up one million revs to get alignment.

If you want the periodic repeating nature (probably), calculate D = 1/TPI of leadscrew. Any time Z = Zexpected * n * D, you have a match, where n is any integer. To avoid calculating all possible n's, N= Z / (Zexpected * D). If N is an integer (no fractional value) you have a match.

edited to add: D=1/TPI of leadscrew

 

[WobblyHand]

If dZ/dt != 0 we are moving, but could be moving because the carriage moved by hand, rather than the half nuts are engaged. If dZ/dt = n +/- dn then I'd guess we are underway. N would have to be calculated from the instantaneous spindle velocity, which I update every 20ms anyways.

Definitely need a prewarning for alignment, or I'd miss the engagement point. If we were going whole hog, we'd use a solenoid to engage the half nuts and the engagement signal could trigger it. But that's inching towards CNC, which I really don't want right now.

 

[rabler]

If dZ/dt != 0 we are moving, but could be moving because the carriage moved by hand, rather than the half nuts are engaged. If dZ/dt = n +/- dn then I'd guess we are underway. N would have to be calculated from the instantaneous spindle velocity, which I update every 20ms anyways.

I'm not convinced you need to separate the case between spindle motion and manual carriage motion. There is no reason you couldn't manually move the carriage to Z expected and close the half nuts while the spindle is stopped, just like a mechanical dial, that is a valid approach. An indicator is just that.

Best way I can think of to do a indicator would be something like a bargraph where centered is on target, and deviation from that is based on fractional part of the division above. (N =Z/Zexpected * D). You're just trying to keep the half-nuts from being closed on the wrong leadscrew turn, so it doesn't have to be super precise. Of course you could get carried away and create an image of threading dial with only one tic mark rotating.

Yes, half way to CNC strikes me as dangerous. Operator and computer may not be in sync and something either metal or flesh could suffer.

 

[WobblyHand]

So how to get back to the same effective positions and angles as the first engagement? It seems it works for simple non-multi-start imperial threading with a thread dial. Even though the half nuts were disengaged, if you find #1 you are synced. I believe the way this is done on a manual lathe is simply to advance the spindle to the next start location, (no engagement of the half nuts) and start the normal threading process. What I could do (one time per thread start advance) is allow the spindle count to advance, and ignore the stepper pulses, until the start advance is reached. Once this is done, the stepper pulses are allowed again, at the normal N/D rate. We would need to tell the system we are on the next start, but that would have to be done anyways. Ignoring pulses can have issues, so I need to investigate that some more, don't want any strange transient things happening.

The G0752Z thread dial has 48T. Does this mean that it takes 48 revolutions of the lead screw to get back to the same position? Each tooth fits between a pitch of the lead screw.

Would be nice to actually solve this for the metric case, but for now, I'd be happy implementing the above example for imperial threads in a test version of my ELS.

Working out some physical numbers, shows life isn't that clean. For a 5 start, the thread advance is 72 degrees. For a 4096 ppr encoder, that is 819.2 counts. To advance a similar amount (I think) that would correspond to 480 steps of the stepper, or 0.6 revolutions (at the N/D ratio for the lead pitch). Pre-advancing the lead screw sounds a lot easier than throwing away or gating pulses. Nothing has to be added to the high speed interrupt service routines which means their timing is unaltered. Going to give this a try.

 

[Winegrower]

I don't have an ELS, but I think you could do a multi start thread by setting the lead screw TPI to (whatever TPI you want to measure on the final part) / (the number of leads). Then, use the half nut like always, cut one of the leads, then advance the compound by the pitch amount (1/(the final TPI)) and cut another lead.

This automatically clocks the start of each lead appropriately.

Doesn't this work?

 

[WobblyHand]

Oof, haven't looked at my source code in a while. (It's been over 2.5 months) Have to figure out what I was doing again. It made sense then... Have to get the basic idea in my head again. Not the actual code but how to transition from one state to the next, and what my naming convention was, so I can add on more features. Before I tackle multi-start I need to do feed to stop and thread to stop. And then finally multi-start thread to stop. Feed to stop is the easiest, so I'll start there. Based on what I learned, thread to stop, at least for imperial won't be too bad either. Just need to have a way of entering the stop coordinate. There ought to be a way to calculate how to resync with metric on an imperial lead screw - I will figure it out somehow.

Already branched my code, so I don't eff up my working code base. In a new sandbox, but still don't want to blow things up so soon!