What's new
What's new

Turning internal Rope thread

Hi All:
Do I infer correctly, that the example of the Doosan in the second video must be using the C axis to control the spindle rotation rather than just turning the spindle and counting encoder pulses.
I believe this to be true because a dumb spindle does not normally behave this way...it just turns at a constant, commanded rate.

Seems to me, if true, that driving the spindle as C axis is fundamentally different from just running the spindle at low RPM and capturing encoder counts.
In the C axis instance, is the spindle motor acting exactly like the X or Z axis motor acts...ie is the spindle motor moving to a commanded angular position governed by what the control is explicitly telling it to do.
If that is so, can a lathe without a C axis capability EVER be made to behave this way?
Would you need to change the spindle encoder to something different, and would you need to change the control to allow it to command the spindle with something more than just "GO" at whatever RPM?
Must you have this to do what Alex wants to do?

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
You are correct that the Doosan is programmed using the C to control the spindle rotation.
I can't comment on what would need to change on a 2-axis lathe to accomplish this. I know on some of my older machines with C-axis, the C-axis needs to be engaged by stopping the spindle and then programming a code to shift a gear which engages a servo motor to control the C motion. Newer machines I have don't have this extra motor, and everything is done by the main spindle motor.
 
You are correct that the Doosan is programmed using the C to control the spindle rotation.
I can't comment on what would need to change on a 2-axis lathe to accomplish this. I know on some of my older machines with C-axis, the C-axis needs to be engaged by stopping the spindle and then programming a code to shift a gear which engages a servo motor to control the C motion. Newer machines I have don't have this extra motor, and everything is done by the main spindle motor.
C axis machine have effectively 2 design. most of it have one normal motor acting as spindle and one servo motor for C axis. Some only have a servo motor capable of both. I just guess it came from two point, the torque and speed needed in normal turning compare to the positioning fonction of the C axis and then the budget come on it as servo motor with high speed and torque was and still are pretty expensive.
Anyway I'm still sure that it should be possible to read the angle of the encoder in someway. indexing X axis to that might be possible but and there is a but, it will lead to a delay between angle position and X axis position due to calculation speed.
I'll still keep looking at it when I got some time even it might be not the best choice, but just for the curiosity.
 
Hi everyone,

For those who are interested, I'm updating my progress.
So I'm restarting from the basic, reading Fanuc manual.

Step one to see, check systems parameter.
Parameter 3117 #1 SPP set to 0 the data from the encoder doesn't show up in diagnosis 445 and 449. if set to 1 data from the encoder shows up in diagnosis 445 and 449. (A serial spindle should be used, the parameter shows up after finding the 0 position in other word run M19S0 to find the 0 and it should shows up) On that I'm good.
Creation of a Dummy C axis (no servo motor, only shows C axis position on the system)
Parameter 987 control axes number set to 3
Parameter 1006 3rd axis bit #0 ROTx set to 1bit #1 ROSx to 0 we get a rotary axis type A
Parameter 1020 set 3rd axis to 64 for C named the 2rd axis C.
1653822524885.png
Parameter 1022 set C axis to 0 (0 Rotating axis)

To be continue tomorrow morning Chinese time.
 
Hi Alex-cn:
I'm still trying to understand how you will map what the spindle is doing between encoder counts.
You need to know this if you want to co-ordinate the X axis and Z axis to the
spindle using the spindle position as the master that drives the response of the other axes.
If the encoder reads a single pulse per rotation, you need to infer it's position everywhere else, and you can only fake that by pretending the spindle speed is perfect.

So how good do you think it needs to be to be good enough for what you want to do?
If you could interrogate it with an encoder pulse say every 10th of a rotation would that be better?
Would it be better enough to matter?
What if it was every tenth of a degree...would that make a practical difference?
At what speed would you overwhelm the ability of your controller to process all the data fast enough to benefit you?

Since you cannot make the spindle axis be the slave axis in the relationship (you cannot directly tell it where to go without a C axis servomotor on it), it has to be the driver of the whole system.
So does your scheme basically register an encoder count; wait a time interval,(representing a "known" angular position) and then prompt an X axis move?
I assume that through all this, the control is producing Z axis motion too, and it does so by counting the encoder pulse rate, averaging it somehow and limiting the current to the Z axis motor to keep the Z axis speed in synch with the spindle speed, thereby giving you your approximate feedrate.

Since X and Z are both relevant to determine the geometry the tool tip traces, do you not have to care about the Z axis feedrate in a whole new way?

Again, I know very very little about how this all works as evidenced by the basic nature of my questions, but I'm sure interested to hear the answers.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
 
Hi Alex-cn:
I'm still trying to understand how you will map what the spindle is doing between encoder counts.
You need to know this if you want to co-ordinate the X axis and Z axis to the
spindle using the spindle position as the master that drives the response of the other axes.
If the encoder reads a single pulse per rotation, you need to infer it's position everywhere else, and you can only fake that by pretending the spindle speed is perfect.

So how good do you think it needs to be to be good enough for what you want to do?
If you could interrogate it with an encoder pulse say every 10th of a rotation would that be better?
Would it be better enough to matter?
What if it was every tenth of a degree...would that make a practical difference?
At what speed would you overwhelm the ability of your controller to process all the data fast enough to benefit you?

Since you cannot make the spindle axis be the slave axis in the relationship (you cannot directly tell it where to go without a C axis servomotor on it), it has to be the driver of the whole system.
So does your scheme basically register an encoder count; wait a time interval,(representing a "known" angular position) and then prompt an X axis move?
I assume that through all this, the control is producing Z axis motion too, and it does so by counting the encoder pulse rate, averaging it somehow and limiting the current to the Z axis motor to keep the Z axis speed in synch with the spindle speed, thereby giving you your approximate feedrate.

Since X and Z are both relevant to determine the geometry the tool tip traces, do you not have to care about the Z axis feedrate in a whole new way?

Again, I know very very little about how this all works as evidenced by the basic nature of my questions, but I'm sure interested to hear the answers.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
Hi Marcus,

The encoder send 4096 pulse per turn which lead to 0.087890625 degree. That should be far enough. X should be a function of the angle being read and Z given Z a fix feed rate. Not Z being a function of the angle which might lead to feed rate issue and as well and most importantly the next step. being able to make it with several passes instead in one shot.

But I'll go baby step by baby step.

First read the F*****g angle of the spindle. Since I didn't find a way to read encoder pulse directly, I'm trying now to create a dummy C axis which read the angle of the encoder. Not sure yet of the success of that. but If I manage to do it then I would be able to read the spindle angle with a VAPAC

Second create a macro which link X to the spindle angle X=f(c). that would result in simple cam turning if I had a Z movement

Third I would troubleshot unexpected issues or unpredictable at the time being. Maximum permisible RPM as the W feedrate will be a function of the spindle angle it will limit the max RPM, Capacity of the system to run properly the macro, speed of the system. delay between angle reading and movement execution. The last one is my biggest worry. If the delay between the system read the angle and the tool move accordingly is constant it won't be a real issue, It will lead to the geometric being slightly rotated to the theoretical starting angle. As I should be able to check it, I should be able to predict it and correct it if necessary. But if the delay between the time that the system read the angle and the time that the tool move accordingly is fluctuating for any reason, it will lead to geometric and surface finish issue. Anyway tolerances are wide: 0/+0.25mm on minor diameter; 0/+0.2 on thread depth and ±0.4 on both radius. So I suppose I could live properly with that.

Fourth I would had to the macro the Z movement X=f(c,z) That would result on threading the full profile at once. At that step mathematical will be tough but not impossible.

Fifth troubleshot any incoming issues

Then it would be to increment the number of passes in the macro.

Finally I would play with all those parameter to find the best suitable in terms of geometrical result, surface finish, processing time, tool life and abuse of axis.

Bonus if I got enough time and see promising effects, It would be to increment a variable spindle speed on the top of it.

That's the plan, but without the first step done, I won't spend time in mathematical as without being able to read the spindle angle, all the plan goes down. I'm sure it is possible as other peoples are currently doing it (cf : https://link.springer.com/article/10.1007/s00170-019-03480-0 )

Regards.
 
Hi Alex_cn:
I was under the impression that you only had a single encoder pulse per turn, and that you were going to have to estimate the angular position of the spindle from its average speed and the time between pulses.

Here's why I though that:
This is a snip from post #15:
" the encoder is effectively a single count encoder. anyway theoretically it should be enough. knowing the angle, the feed rate and the Z position I can deduct the number of turn."

So the encoder is actually much more capable than that, and you are effectively making an electronic cam using the spindle rotation as the master as you say, and making the X axis and the Z axis the slaves.

I can see much better now, how you intend this to work...it makes much more sense to me, so thank you for clearing that up.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
 
Hi Alex_cn:
I was under the impression that you only had a single encoder pulse per turn, and that you were going to have to estimate the angular position of the spindle from its average speed and the time between pulses.

Here's why I though that:
This is a snip from post #15:
" the encoder is effectively a single count encoder. anyway theoretically it should be enough. knowing the angle, the feed rate and the Z position I can deduct the number of turn."

So the encoder is actually much more capable than that, and you are effectively making an electronic cam using the spindle rotation as the master as you say, and making the X axis and the Z axis the slaves.

I can see much better now, how you intend this to work...it makes much more sense to me, so thank you for clearing that up.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
Hi Marcus,

I did mean that the encoder isn't an absolute encoder. By that I don't know how many turn the spindle have done and I have to set the 0 position at every start of the machine by an M19 or M19S0 in order the the encoder find it's reference position. But it is 4096 pulse/ turn, accurate enough to make some synchronization. I'm actually reading the Fanuc manual B64694 and B64694-1. It seams there is several possibility.
G81.1 high precision oscillation seams easier to handle though it also seams to have some limits as it's original purpose is for rectification.
G81.4 and G81.5 Electronic gear box synchronization seams more difficult to apply but more capable of strange function of synchronization.
I'll study carefully those G code and give it a try if I'm able to.

If any folks use those G code or have knowledge about it, It would be much appreciate

Regards
Alex
 
If I had that job, I would try hard to do it using code, but I thought I would post an alternative method using internal thread whirling (Low-quality demo. Turn your sound off):

Posted without comment:
 
A) What makes it "Whirling" and not simply thread milling?

B) Nice D-Vibe bar! That's a LOT of tool pressure hanging clear out there!
M8 would be nice, but Leaded stock is forgiving....


-----------------

Think Snow Eh!
Ox
 
A) What makes it "Whirling" and not simply thread milling?
I guess it is all thread milling. Whirling - I think - describes milling by orbiting around the part. So, you are right. It is just thread milling. :)
B) Nice D-Vibe bar! That's a LOT of tool pressure hanging clear out there!
M8 would be nice, but Leaded stock is forgiving....
M8 pumping some dark cutting oil.
-----------------

Think Snow Eh!
Ox
 
  • Like
Reactions: Ox
Well, there is something different about an actual OD Whirling head.
It's not just a thread mill.


-----------------

Think Snow Eh!
Ox
 
Hi

Whirling is about OD threading. I actually produce anchor bar with OD thread by thread rolling process.
For ID thread milling is a possibility. I'm actually thinking to had a live tool on the machine this would make thing easier and faster. I have to consider tool supply as that thread is not common one it will require customize tool. Will it be efficient from the cost point of view ? might be.

Concerning the full profile insert, It has been considered. Beside the cost. It should work perfectly on R38 and R51 which had bigger internal diameter but on R32 it will without any doubt, tool deflection.
 
Well, there is something different about an actual OD Whirling head.
It's not just a thread mill.


-----------------

Think Snow Eh!
Ox

An OD whirling head does not revolve around the part in the manner that a thread mill does.
The whirling head is stationary in X, Y, and Z, the part rotates about C and feeds in Z.

At least on a Swiss with whirling head. I've never seen whirling heads used in any other kind of machine, but I'm sure they probably exist.
 
You could probably use one between centers if the thread was a bear otherwise I s'pose.


------------------

Think Snow Eh!
Ox
 
This video shows what I have in mind. First, of course, you would need to use trig to properly radius the crest and root of the thread to match the specs:

 
  • Like
Reactions: Ox
Hi David_M:
Apparently the OP is already doing that with successive G32 passes and it's taking way too much time.
In his first post he describe how he is doing it with a macro which looks like it picks the proper start point for each G32 pass.
I haven't looked at it closely, but he describes decent success except for the cycle time.
What he wants to do is the same rope threading canned cycle that a high end Okuma can do, and he shows the method in the link to the video also in his first post.
Have a look at the video...it's a crazy way to make a thread.
He is hoping to make a cheap lathe without a C axis do what the Okuma can do.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
 
Hi, Marcus.

The Okuma looks impressive with its cam action. I can see how the cam motion could break up harmonics with a small boring bar working internally.

The process looks very fast in the demo. However, in practice, the metal removal rate will be about the same as a G32 in a loop using a macro (this is just my very humble opinion).

I say stick to the offset G32s but separate the roughing and finishing. With the roughing, change tactics and significantly increase the G32's Z stepover amount.
I would try a larger radiused tool loaded up to prevent chatter. Push it hard to get rid of more metal faster.

Hey, I think the following machine was built from the ground up to make parts like the OP's:

Leistritz LWN 120 IW
 
Last edited:
I don't understand what I am seeing there.
It sure looks like the only action is C/Z back and forth.
But that should yield nothing other than a smooth bore, and that's certainly not what they are promoting there I don't think.

How doo you produce a thread in C/Z with Z+/Z- motion?

???


----------

Think Snow Eh!
Ox
 
Hi Ox:
Looks to me like a goofy variant of thread milling.
If I'm seeing it right, the cutter in the thread milling bar can be adjusted on the fly for diameter and also oscillates in Z to nibble out a full width thread gullet with a smaller tool.
I assume the benefit is that you can stuff the biggest possible threading bar into the hole, open out the cutters when you have it all the way in, and make discontinuous chips you can flush out the back end as you reverse mill the thread in one shot.

I'd be really curious to see what a cutter for this looks like, especially for a coarse pitch thread with steep sidewalls like an Acme thread.

There's got to be some form distortion if you threadmill, no matter how sophisticated the machine.

That's my guess, but it's just a guess.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
 
Last edited:
Hi David_M:
I agree with you...the principal constraint is that you can't use a big stiff toolholder so you can't push it like you can for an external thread.
If you want to waggle it back and forth in X like the Okuma does you have to make the bar skinny enough to accommodate the oscillations.
Waggling it back and forth in Z like the Leistritz does eliminates that drawback, and of course the little chips from milling are easier to manage than the long strings from single point boring.

It's a cool thought experiment for sure, but it does make mandrel forging or swaging look awfully attractive.
Problem for the OP is that he's trying to find the best way forward on a budget...and it sounds like his budget does not include the coin for fancypants Leistritzs or Okumas, never mind some swaging or forging monstrosity.
I can't imagine what it would cost to develop the process for mandrel swaging it...probably even a lot more than that multi million dollar Leistritz.

Cheers

Marcus
www.implant-mechanix.com
www.vancouverwireedm.com
 








 
Back
Top