[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...

[kurmay]

Hi DrNos

Okuma LookAhead function isn't working good in the iteration. But i would recommend writing the program at least as much as possible.
try this codes in same line
DIA1=DIA1+10 LEN1=LEN1+0.5
it can work faster.

[deadlykitten]

or maybe NOEX DIA1 = DIA1 + 10 LEN1 = LEN1 + 0.5

[kurmay]

or generating code for fastest speed

this sample is excel file

[DrNos]

why should "the contribution of F to the actual feedrate in the Z-direction be constant" ? why ? what's the catch ? what's the run dude ? ( azaelia banks - 212 )

I don't know how to explain it better... The X and Z components get separated into two parts with respect to F. It works and behaves like I want; it's just too slow.

Hi DrNos

Okuma LookAhead function isn't working good in the iteration. But i would recommend writing the program at least as much as possible.
try this codes in same line
DIA1=DIA1+10 LEN1=LEN1+0.5
it can work faster.

I had a similar idea! I should be able to test it this Friday.

or maybe NOEX DIA1 = DIA1 + 10 LEN1 = LEN1 + 0.5

What does NOEX do?

or generating code for fastest speed

this sample is excel file

I was thinking about something in-between the two strategies you suggested. - Run the loop to populate the registers with 127 values and then have an 'unrolled' loop full of G1s. The loop could repeat every rotation, or every other rotation of the spindle, provided I can convince the machine to give up its threading-cycle secret sauce.

[deadlykitten]

hey doc, i thought you are lost with a patient

look man, what i really do here is delay my answer, pls consider that i have allready delivered such custom threads, and the technique works "as it should"

there is a tiny conflict : " as it should " <> " It works and behaves like I want "

computing those X&Z components within respect to F is not a fundament for machining

pls consider these examples; all of them require same time to complete ( 1 minute ) :

    G01 X100                                            F50 G94 G91
    G01                           Z50                   F50 G94 G91
    G01 X + 2 * SQRT [ 2500 / 2 ] Z + SQRT [ 2500 / 2 ] F50 G94 G91
    G01 X + V1                    Z + V2                F50 G94 G91 ( V1 / 2 ) ^ 2 + V2 ^ 2 = 50 ^ 2

somehow, one way or another, we have to fix this variable F that you use; after that, is possible to move on without any doubts about it


it's just too slow : because you succumb the cnc; there is a rule for minimal segmentation and coresponding F; you can not simply input whatever segmentation and whatever feed, and expect the cnc to perform no ... it does not work like that


NOEX is not required to compute code for custom threads; it may boost your code, but it won't work, because specialized threads are not loop-generated; more precise, the loop should not content only cutting movements; the only way to deliver a specialized thread, by using a loop, is to use at least 1 positioning movement within that loop; the loop creates downtime, and this downtime will affect how the cnc behaves :
... if there are only cutting movements, you will put a break on their execution, and surface rugosity will increas, and tool wear/friction may appear
... if there is at least on positionong movement, than all those negative effects should hit into the positioning movement, not into the cutting movement


about that video that you shared at post 3, and you try to reproduce : you won't be able, because that is a specialized machine : the way it works goes beyond basics, and few people have seen such a lathe in reality ... or maybe you have one ?




ps : you may find a code attached ( it works similar to the videos from post 5 ); truth is that it has "tricks" : i can explain them, but i strongly suggest small steps ... you have rushed small steps Doc, small steps : about that variable feed, i will be back with an example, and i hope that it will make some light

[deadlykitten]

hey doc, me again feed is always tangent to the cutting toolpath

so the controller calculates automatically the feed ratio for each motor / did i pushed the right button ? kindly