[DrNos]

Yesterday after clocking out I tried to run a rope thread macro I have written for an Okuma lathe from 1989. I was appalled to see that it processed a loop doing nothing but incrementing a variable at about 1/100th of the speed I had expected. Truly medieval, considering the 6502 processor has been available since 1975.

Is this still a problem with more modern control? Do they intentionally slow down G-code processing speed? Is there any way to get around this problem?

[deadlykitten]

hello doc

Is this still a problem with more modern control?

yes, unfortunately it is ...

Do they intentionally slow down G-code processing speed?

yup, the slower the processing speed, the more expensive the cnc; each new okuma machine is really slow, and it comes with a little fat ninja squeezed inside the electrical cabinet

Is there any way to get around this problem?

maybe ...


do you use :
... G10* XCZ, *=1, 2 or 3 ?, or
... G01 XCZ ( in this case, feed value will not be constant, and a bit of math is required; a wrong feed value may lead to downtime )
...... what code syntax do you use ?

also toolpath discretization may lead to cnc succumb, thus if small segments are used, than the cnc won't be able to reach the programmed feed, and downtime will appear

if segments are normal ( thus the cnc can reach and maintain the programmed feed ) and if feed is too high, some "round corners" may appear : for example, if you wish to turn a square with sharp corners, is better to use a lower feed; using a high feed may lead to round corners ( the rounding may not be simetrical, like a round chamfer )


write 1-2..4 lines of CXZ feed, and use a tick-tock timer to check the duration of those feed lines; real duration should be close to expected duration; if this happens, than your code syntax is ok now you may reduce the length of the segment, and check times again ... at some point, you will encounter cnc succumb ( real time > expected time ); now you may reduce feed, and check the times again ( difference between "real" and "expected" duration should reduce )


have you done such tests ? so to determine the "succumb" zone ? kindly

[DrNos]

Hi there!

...and it comes with a little fat ninja squeezed inside the electrical cabinet

So that explains all the oil it eats...

This is my code for testing if I can do rope threading:

G50S2000
G0X50Z200T0101G97S1000
DIA1=0
LEN1=0
N1 IF [DIA1 EQ 3600] N999
IF [LEN1 GT 50] N999
DIA1=DIA1+10
LEN1=LEN1+0.5
G1X=[SIN[DIA1]*20]+50Z=[200-LEN1]F=.1+ABS[COS[DIA1]]
GOTO N1
N999
M1

It makes the turret move kind of like a ship rolling at sea, but it is really jerky, possibly because of the 10 degree angle increment in each step. With a smaller increment the movement becomes too slow for my liking. The code is also not tuned to the spindle speed yet. It's as far as I got in 2 hours yesterday...

This is what I want to achieve:
https://www.youtube.com/watch?v=XSIcV710ACk

Fanuc control has a G64 code to control smoothing/ accel-decel approximation. Do you know if Okuma has something similar?

[mactec54]

Yesterday after clocking out I tried to run a rope thread macro I have written for an Okuma lathe from 1989. I was appalled to see that it processed a loop doing nothing but incrementing a variable at about 1/100th of the speed I had expected. Truly medieval, considering the 6502 processor has been available since 1975.

Is this still a problem with more modern control? Do they intentionally slow down G-code processing speed? Is there any way to get around this problem?

It's not how fast the control can process your code, it's what the mechanics' of the machine can do, Servo Motor Encoder, low count Encoders, which most old machines have, is going to be jerky as you have experienced

[deadlykitten]

hey doc many complain about the oil ... newer controls have some parameters for that, especially one that will stop the lubrefiation if the axis are not moving; i don't have experience with your controller, but you may ask inside the Okuma forum : https://www.cnczone.com/forums/okuma
* also ask about the accel/decel parameters

i will look over that code of yours asap

until then, maybe this will entertain you :
... your code is a single pass type, thus if you repeat it, it won't begin at same spindle orientation ( is not possible to input an X offset corection, and recut it )
... rough + finish :
https://www.youtube.com/watch?v=Nyrv...fhPKmLuVHNhiLv
https://www.youtube.com/watch?v=E8nC8z5bK50

[DrNos]

It's not how fast the control can process your code, it's what the mechanics' of the machine can do, Servo Motor Encoder, low count Encoders, which most old machines have, is going to be jerky as you have experienced

So machines without high precision encoders can't have something like Fanuc G64?

... that code is a single pass type, thus if you repeat it, it won't begin at same spindle orientation ( is not possible to input an X offset corection, and recut it )
... rough + finish :

Yeah, I intend to read the spindle orientation from e.g. QSPPC and do the sine transform on data derived from there. I am however not sure that in practice I will be able to meet timing demands now that I see how slow the code processing is. - But perhaps it is the slowness of the processing which makes it deterministic?

I should mention I don't have any particular need to make rope threads, and in particular not on this machine. I just want to see what it and I are capable of, for fun.

[deadlykitten]

what is qsppc ?
pls, do you have some documentation for that formula inside your code ? it would help me a lot, spare me some time,etc ...

about timing : you may rough this thread by using a threading code ( S axis), so each pass will be only among Z, but in the end, it will deliver the thread ( or something close to it ); if you wish for an extra finish pass ( to make it more smooth ), during which the machine to move on both X&Z, you may need to use the C axis; finding the common orientation for S and C is tricky many guys don't bother about this common orientation, because they run only the finish pass once, or only the roughing passes

if you wanna run both ( rough + finish ), than finding the common orientation is critical; to do this :
... rough on S axis + finish on C axis and lose time with finding the orientation ( i can explain how, if you wish )
...... truth is that S axis orientation, when threading, changes with the rpm; there are options to keep the orientation constant, regardless of rpm value
... rough and finish only on C, so the orientation will be the same
...... roughing on C axis will put more stress on the servos, comparing to roughing on S axis, but since there is a finish pass ( on C axis ), you may use less passes when roughing with C axis; for example :
......... rough only on S axis : 50 passes
......... rough on C axis + finish on C axis : 15+1 passes



i got it that you do this only 4 fun is ok, i always take fun seriously / kindly


ps : pls, share some documentation for your formula ( i hope there is some ); ... and you don't have G94 or G95 inside your code

[DrNos]

I don't have documentation but this is all from my own understanding so I can explain it. I used to work in IT before switching careers since that wasn't going anywhere.

Basically, when you feed the sine function a number between 0 and 360 it spits out a value between -1 and 1. Sin(90) is 1. Sin(270) is -1. Sin(0) and sin(180) are both 0. Sin(90) in my code is the crest of the thread, and sin(270) is the valley. If I want a 4 mm deep thread, I multiply the output of the sine function with half of 4 mm, so I get +2 mm and -2 mm since 1*2 = 2 and -1*2=-2.
DIA1 increases linearly but the output of the sine function goes quickly past its output of 0 and slowly past its -1 and 1. - The difference between the outputs of sin(0) and sin(1) is much bigger than the difference between sin(89) and sin(90). 0,0175 for the first and 0,0002 for the second, even if the inputs differ only by 1.

For F I use cosine because it gives me a 1 at sin(0), where the output of the sine function changes the fastest and the tool needs to move at the highest speed. Cosine is basically just sine which trails 90 degrees after sine. A much more technical perspective on this would be that cosine is the calculus derivative of sine, and derivatives tell you how fast a function is changing. Either way, I need speed!

Z increases at a constant speed even though F changes! This is because the distance between the previous X,Z and the next X,Z changes too. The apparent speed change of Z is cancelled by the distance that X takes up.


And that was the easy part! Which is why the code is so short. It just demonstrates the basic principle. I still need to synchronize the movements with the C axis, like you said, even though this machine doesn't have live tools. Right now F is tied to rpm/min and the multipliers are way off. Even if the multipliers were right the thread pitch would have to be hand-tuned by setting the spindle speed to a very exact value.

The Okuma LB-12 that I'm allowed to use unsupervised has a threading cycle, so the hardware needs to be capable of synchronizing. QSPPC in the diag. menu has the value of the encoder for the spindle, which goes between 0 and 4096 for corresponding with 0 to 360. If I can read that then I can use it to try to synchronize. Then I need another counter to add to DIA1, so that the program doesn't just dig a straight ditch along Z but instead coil around, like a thread.


I might be able to use the read-ahead function to smooth out the movements, so that X doesn't come to a halt after each G1. Perhaps I can pre-calculate a bunch of variables for the read-ahead to look at... Is this what G101 does? I'm also wondering if the 'high-speed processing' that the manual brags about is only unlocked when you use a canned cycle. If that is the case then I might still be able to get the really fast movements I want...

[deadlykitten]

hy doc / when you go like that, is like how you target same duration for each segment; how segments are not equal, also feed should not be constant; maybe F=.1+ABS[COS[DIA1]] delivers that behaviour, but i am not sure

however, i would strongly recomend you a constant feed, so to deliver a surface with constant rugosity this is pretty essential when machining; there are cases when the feed changes among a toolpath, but those cases is another story ( i can develop if you wish )


even if your cnc does not have live tools, you may use a standard threading code, and simply shift the "clearance point of the Z axis" or the " phase of the spindle " : in both cases, the turret will move only on Z, and not on XZ ( like the code that you wrote ); truth is that code ( except for the feed value ) is mostly used with the C axis; making it work with the S axis is a bit harder

i will be back with more infos about codes for such threads let's fix this 1st, and after that we may go to the read-ahead + code processing speed / take them one by one, don't rush into both at once / kindly !

ps : do you have in mind some dimensions for that rope thread ? X min, Xmax, Z_for_a_full_revolution ? if you wish, provide those numbers, and i will share the actual code

[DrNos]

I think Okuma lets you do threads with multiple starts at arbitrary offsets. Should not be too hard to adapt this code to compute all the starts you need for a rope thread, but one might need to do it in multiple levels.

The 'roughness' only shows up in the X-axis. As you can see in the attached image, the toolpath is a perfect sine wave.

I don't have any dimensions, but from what I understand rope thread is used a lot in oil drilling. The thread allows for a tight seal even when dirty, so it also gets used in gas masks. The Edison bulb socket also has this geometry.

I'm working on a third, really nifty way to do rope threads, based on this:

[deadlykitten]

hy doc

the 'roughness' only shows up in the X-axis : even if you find the math that handles all that stuff, in reality the part must have uniform aspect it is kind of normal ...

that is not sin wave : pls check attached image ( those 2 radius have to be equal ); however, if you wish, i can code the thread for that "shape"

[DrNos]

I think I explained previously how the cancellation of the distance vs. speed works on the Z-axis... Either way, Okuma sees fit to sell their version which in principle works the same way for (I assume) big money.

To me the wave looks like a modified sine wave. The point moves in a circle at a constant speed, same as the function which generates a sine wave. Perhaps if I slow down the upper half of the cycle and speed up the lower half at the right ratio it will look like a pure sine wave? We will see. I'll try to set up LinuxCNC to plot some toolpaths. If it succeeds then this technique could work on much older lathes since circular interpolation is pretty fast.

[deadlykitten]

hello again doc

I think I explained previously how the cancellation of the distance vs. speed works on the Z-axis : yup, i got it sin moves fast arround 0, and slower arround 90, so you use the cos to compute the feed, because cos moves also fast arround 0 ... for me, is ok, i got it, i understand, but you are doing it wrong

even if you use a faster feed when the sin moves fast, the output is not proportional; thus, if sin values changes with x%, feed will change with y%, where y<>x

my dear doc, this is not practical, this is not the proper way to do it

Either way, Okuma sees fit to sell their version which in principle works the same way for (I assume) big money : please, what exactly are you reffering to ?


To me the wave looks like a modified sine wave : consider that you use a sin ( just like your initial code ), or a modified sin, or whatever function that is not linear : all these complex functions are handled into the same manner : optimal segmentation and constant feed, so to get an uniform aspect

i will show you soon how to handle all these

[DrNos]

In the thumbnail I attached, you can verify that the feed in the Z-direction is constant but the feed in the X-direction changes. - While F changes with each iteration of the loop, the contribution of F to the actual feedrate in the Z-direction is constant. If this wasn't the case, the graph would not look like a pure sine wave.

I tried to copy the way that Okuma does it in the video https://www.youtube.com/watch?v=XSIcV710ACk
There, the sine wave is much more 'dense', or at a higher frequency if you will.

This should prove that it is the right method and that I have implemented it correctly. The problem is speed. If I set the angle increment in my sine wave to 1 degree per step, the movements happen at a glacial pace even if I increase the feedrate ( F=.1+ABS[COS[DIA1] * multiplier] ). To get decent movement speed, I need to increase the degrees per step (DIA1=DIA1+10) to e.g. 10, but then the movements become very jerky.

[deadlykitten]

pls check again, because there is no thumbnail attached to your last post, only a video

i know how to do that on the okuma, in 4 different ways, and i will describe them to you ... i intend to share those explanations during the weekend

until then, let's clarify a bit those feeds / kindly !

[deadlykitten]

oh, i got it but is possible to get a sin wave even if feed component in Z direction is not constant ...

check attached

[DrNos]

Oh, I didn't realize. This forum software confuses me a little. Here is the graph in question.



OSP500L-G graph mode.

[DrNos]

oh, i got it but is possible to get a sin wave even if feed component in Z direction is not constant ...

check attached

That looks exactly like the wave .gif! Very encouraging!

[deadlykitten]

ok, i will check again your approach; did you see my last post ?

[deadlykitten]

That looks exactly like the wave .gif! Very encouraging!

yup, there are different methods to compute that sin wave toolpath; for me is late