Formula to change rpm on threading cycle

[Vancbiker]

…….Doosan sells this feature as an upgrade. Costs them zero dollars to just include it as a standard feature. What a greedy bunch of crooks we deal with.

Someone at the control manufacturer did have to create the software. Each machine builder has to develop correct parameters and possibly add logic to their ladder so the function performs properly with their machine design and properties. Then it needs to be tested. Then someone has to add instructions on usage in the manuals. All that work needs to be paid for somehow. What better way than to charge the end user for the feature?

This shit isn’t free. Are you the type guy that runs cracked CAD/CAM because it doesn’t cost the developer anything to create software???

 

[William Lynn]

Such a shame that we have to deal with this bull shit. Maybe one time in history it was an issue, but all the manufacturers could easily have this perfectly synced at any speed with todays technology. Doosan sells this feature as an upgrade. Costs them zero dollars to just include it as a standard feature. What a greedy bunch of crooks we deal with.

Why? Just follow the simple rule, do not change RPM in the middle of the threading cycle. Or the start point.

 

[sinha]

Is it just one part, or you want to do this for a production run?
Chatter sucks, but sometimes RPM won't make a damned bit of a difference.
If it is a production run, then perhaps you can change the cycle to a G92 and call the depths explicitly.
I do that on quite a few parts, specially on thin walled ones.
For chatter, I typically finish threading to the nominal minor, then back off .0005 and chase two or three more passes.

Increasing minimum DOC in G76 may also help.

 

[EmGo]

Such a shame that we have to deal with this bull shit. Maybe one time in history it was an issue, but all the manufacturers could easily have this perfectly synced at any speed with todays technology.

That's true ... and they could also include an egg timer, a microwave oven, and a backup 8V92 in case the power goes out.

99.9% of the time on a two axis lathe a totally synched spindle would serve no purpose at all except cost more, make the software less reliable and the lathe more fragile (try getting fifteen year old electronic parts some day.)

Isn't there some saying about "if it works, don't mess with it" ?

 

[mmurray70]

If your running production on small parts its no big deal, fix it for the next part. But if your doing jobshop work on a big expensive part it can certainly come in handy. If there wasnt a need for it this thread wouldnt have been started, along with all the stories of scrapped parts.

Theres no extra complicated hardware or software needed for the builders to do this. No different then rigid tapping. When we rigid tap we go from full speed to a stop and then reverse, all perfectly synchronized. Doesnt even need to be nearly as accurate as rigid tapping. Or cover such a wide range of speeds. Its just another example of builders charging us for what should be standard features.

 

[twr]

Options cost money car, house, cnc machine its the way it is. If you made some software would you want to give it away for free? I sure as hell would not!

 

[Azoth]

It has Zero to do with that, its all due to the synchronization between the Spindle RPM and the Axis Motion. As the Threading Tool makes passes at the various diameters, in G96 Mode, the RMP of the Spindle will change due to maintaining Constant Surface Speed at these various diameters.

Regards,

Bill

That's what I said?

But my guess was that it falls out of sync if the turret has to accelerate to different feed rates to keep constant pitch when the spindle rpm is not kept constant.

I've only ever heard that "it can't be done" because the tool entry point will shift with no explanation as to why. The only reason I could figure was that it's too difficult to predict how long it takes the turret to get up to speed after it receives the go signal.

If the variation in feedrate acceleration time is too insignificant to affect the tool entry point, then it's just a cop-out from the machine builder isn't it

 

[Vancbiker]

That's what I said?

But my guess was that it falls out of sync if the turret has to accelerate to different feed rates to keep constant pitch when the spindle rpm is not kept constant.

I've only ever heard that "it can't be done" because the tool entry point will shift with no explanation as to why. The only reason I could figure was that it's too difficult to predict how long it takes the turret to get up to speed after it receives the go signal.

If the variation in feedrate acceleration time is too insignificant to affect the tool entry point, then it's just a cop-out from the machine builder isn't it

Well, there are advanced threading functions. It's a Fanuc option on newer controls. Whether or not a builder offers it as standard, or extra cost option, or offers it at all, is up to the builder and of course, the buyer has to add it to the purchase spec. Also many machine sales people would not know nor recognize that their prospective customer might benefit from such an option therefore not bring it to the customers attention. Not sure how that seems a cop out from a machine builder.

 

[Azoth]

Well, there are advanced threading functions. It's a Fanuc option on newer controls. Whether or not a builder offers it as standard, or extra cost option, or offers it at all, is up to the builder and of course, the buyer has to add it to the purchase spec. Also many machine sales people would not know nor recognize that their prospective customer might benefit from such an option therefore not bring it to the customers attention. Not sure how that seems a cop out from a machine builder.

Lol yes pure laziness, IFF it were as simple as "halving the rpm=180° lead change" like angelw claims because then the resolution would be exceedingly straightforward. If you're paying attention, I said it IS more complicated than that. Angelw's anecdotal "evidence" is just causing him to spread misinformation.

If that happened, the reason his thread was 180° off was because the difference in the time taken for the turret to accelerate to each velocity just happened to be the same amount of time it took the spindle to rotate 1/2 turn at the 2nd halved speed (or some integer multiple of that time) so it fell out of sync by 1/2 turn by the time the turret movement was up to speed. If he tried a different set of rpms or a different machine, the results would vary. Still all hypothetical on my side (as far as inertia/mass complicating the desync comp), but flawed logic is always easy to spot so I've no qualms arguing with my inexperience.

But also, good to know they have been able to develop "arbitrary speed threading". Although there is an easy solution that doesn't require but 5 minutes of coding if you had access to the machine's data via some sort of API (same way we manually do it, just let the machine take one air cut and observe itself so it can compensate)

 

[Fancuku]

I've never tried changing spindle speed to re-run the threading operation on the same part but I had to chase threads for a coworker (his thread was undersized) who made them in his machine and this is what i found out.

I made the exact part in my machine and put a mark where the first thread starts on the part and a mark on the jaw corresponding to the mark on the part.

Took my part out, and lined up his part's starting thread line to the mark on my jaw. Re-ran the threading operation and to my surprise I saved the part. No cross threading. What's even more wild is that I was threading at 450rpm and coworker had threaded the part at 650rpm. That surprised me the most because I always believed that changing the RPMs would result in cross threading.

We both used G92 for the thread cycle and his part was made in a 2022 Doosan lathe and mine was made in an early 2000s Hitachi Seiki. I saved all of his 10 parts.

I don't know if this proves that you can change spindle speed and rerun the thread and still be good but it was an interesting experience.

 

[sinha]

You did it correctly, but there is a flaw in your conclusion.
Irrespective of how a thread was made, once you align its threads correctly with respect to the jaw, it would be chased correctly.
After making your "test thread" at 450, you cannot use any other RPM for chasing the thread.

But, I am impressed by your novel idea.

 

[Brian285]

I found this a while ago on the emastercam site, I’ve never tried it myself, just kept it in mind if the need arose.

emastercam.com/forums/topic/88179-lathe-threading-question/

 

[sinha]

I found this a while ago on the emastercam site, I’ve never tried it myself, just kept it in mind if the need arose.

emastercam.com/forums/topic/88179-lathe-threading-question/

View attachment 389954

I do not have too much faith on this scheme, because of several reasons:
1. I have not seen it elsewhere
2. There cannot be such a simple formula for a complex issue which depends on several factors.
3. I cannot believe that a difference of 50 in 300 RPM and the same difference in 1000 RPM would result in the same shift. Had they talked about percentage change instead of absolute change in RPM, it would have been more logical.

 

[pgmrmike]

I do not have too much faith on this scheme, because of several reasons:
1. I have not seen it elsewhere
2. There cannot be such a simple formula for a complex issue which depends on several factors.
3. I cannot believe that a difference of 50 in 300 RPM and the same difference in 1000 RPM would result in the same shift. Had they talked about percentage change instead of absolute change in RPM, it would have been more logical.

A chart like that floats around these parts, but I have never used it. I do it by percentage because it seems logical.

I had a new employee that had a chatter issue. I asked how he was going to fix it and he, rather smartly, said "no problem, I have this chart". I told him to be careful I dont trust the chart. When the part was done he couldnt believe the PD and root width were way out. I asked what happened and he said he knows he didnt mess it up because he said he used the chart. Sigh...made the change and didnt even watch to see if it was in the center, or hitting one flank early. Nothing. 20yr machinist.

As an aside, we do the chuck/thread orientation thing here occasionally. Almost all stub acme so its pretty easy. A little more critical with API threads


On edit: In regard to thread sync from machine to machine, I have had multiple people tell me that once a thread and higbee are cut and timed correctly, that it is transferrable to any machine, that the timing will be correct no matter which machine the same setup and program is used. It seems logical but is not true. All 3 of my lathes are a bit different. It will be close, but slightly different.

 

[EmGo]

Just scooch it in a little with the differential resolvers ...

 

[sinha]

In regard to thread sync from machine to machine, I have had multiple people tell me that once a thread and higbee are cut and timed correctly, that it is transferrable to any machine

Once you unclamp/reclamp, without bothering about the orientation of the workpiece with respect to the chuck, chasing becomes an issue even on the same machine, forget about machine-to-machine transferability.

 

[Hertz]

Hey guys, so what I did for this situation was used the thread chasing function. The nice part about the chasing function I have, is that I can add multiple cuts and not have to do it in just one. So I added the amount of cuts I would take in a normal threading operation, and changed the RPM. Basically just lined up my tool like a normal thread chase, and press the synv button and away it went.

Once you unclamp/reclamp, without bothering about the orientation of the workpiece with respect to the chuck, chasing becomes an issue even on the same machine, forget about machine-to-machine transferability.