[deadlykitten]

hello, here are this 2 :

Okuma | Cycle Time Reduction | Spindle/M-Spindle
Cycle Time Reduction | Indexing Turret | Okuma

does anyone has an idea about this " There’s a lot to cover and a lot more time to save with my next couple topics too: Fixed Cycles, and LAP Cycles (Lathe Automatic Programming) " ? kindly !

[OkumaWiz]

Cooper is a great guy and did a decent job of explaining CTR function. His initial post left out the M203 which is GREAT for saving cycle time. His second post reveals it nicely. He did however leave out the other part of this which is to put your T command on same line as the XZ move. This will allow the turret to clamp the curvic coupling as it rapids towards the part when you have the servo turrets.

I tend to avoid the M65 & M66 due to the increased danger factor and find that using the M203 is as fast since the turret can typically reach it's limit by the time the coupling is unclamped and can reach the part by the time it is re-clamped.

The M63 command is CRITICAL to reducing cycle time and should be used during ALL RPM changes that can be combined with a move until the machine is running "smooth as silk" with no waiting or pauses.

M203 followed by XZT = about 1.5 seconds saving per index. M63 is good for varying amounts but can as much as it takes your spindle to go from full stop to max RPM to full stop. Usually good for a minimum of 10 seconds/program - usually more.

Inside of the canned cycles, another savings can be achieved by adjusting the clearance values in the peck drilling cycles. I think that this is what he was referring to. Both the standard drilling and the M-drilling cycles have default clearance values. These are set at .05 from the factory, but the cycles can be reduced by decreasing the setting. Typically .02 is what I use so that there is still clearance in case of a chip at the bottom of the hole, but the extra .03 really does nothing more than add cycle time. There are also clearance values for the LAP cycles, but the default .01 is a decent value, so Cooper is probably referring to the advantages of using the canned cycles from a programming standpoint and the flexibility gained by using them. It's great to just change a DOC in a LAP/drilling cycle rather than have to re-do all the moves in long hand G-code.

Best regards,

[deadlykitten]

Cooper is a great guy and did a decent job of explaining CTR function

yeah, me too ... i mean i also think the same about Cooper he has that charismatic G code expression

He did however leave out the other part of this which is to put your T command on same line as the XZ move. This will allow the turret to clamp the curvic coupling as it rapids towards the part when you have the servo turrets.

he said something about this in the 2nd blog ... please see attached / however, he was presenting this during the M65, so maybe is confusing, because is like you must 1st understand what M65 does, and also understand that coupling does not care about it ...

also, Broby revealed the posibility of using this syntax a few time ago ...

N1008 X52 Z52 T020202

syntax is something, coupling ( machine behaviour on the syntax ) is something else ...

me, for example, i discovered this by mistake, just yesterday ... i was mesing with M86/87

if you are in manual mode, and while turret is indexing, you push Z_left button, than turret goes left after indexing+clamping ... i thought to eliminate this clamping_delay inside the program, but when the program runs, machine is clamping during rapid by default

for example, here :

T ( indexing )
G0 X.. Z.. ( clamping during movement )
G97 ..
G01 ... ( at least 0.5seconds must take between T and G01, so for the clamping to occur before feed )

generally, i go like this : T... M66 G0 X... Z... M63 G97...

when i saw that this is default, at least on osp300, i remembered that paragraph from Cooper, the one that i posted

so, sometimes, tricks are presented during other tricks ... a bit from here, a bit from there, and you got the final image

Inside of the canned cycles, another savings can be achieved by adjusting the clearance values in the peck drilling cycles

drill with peck : cut,+Zclearance, cut, +Zclearance ... please, from where do you change the clearance ?

however, generaly, this move (+Zclearance) is done in rapid, so to break the chip spiral ...this tensions the tool ... when i peck, i use feed so breaking with less stress

i must say that i hit into a lot of stuff that default cycles won't deliver, so i code a lot on G ... now, for example, a drill enters after another; entrance rpm=100, so to have a smooth entrance

I think that this is what he was referring to

also, i share same curiosity ... let's contact this guy let's tell him about time reduction on VRSTT i would ask him about low precision on roughing and default or desired precision on finish operations ... all the best

[deadlykitten]

about this paragraph ( pls see attached ) : confirming T ... i agree with it, but i don't use it ...

"i agree with it" because, if clamping did not occur, than an error will raise when G1 should be executed; T repeating acts like a guardian if rapid is finished before clamping ocurs, than clamping will be finished during the 2nd T ...

"i don't use it" because rapid duration is long enough

this means that is good to use it, but is not a must

N1006 G0 Z800 G97 S1102 M63 (Rapid to tool change position on Z axis only, Setting up spindle speed for next operation)
N1007 X52 Z800 T020202 M65 M66 (move to next start point on X axis, KEEPING tool firmly on Z axis home position to ensure safety, use M65 to specify free turret indexing when not home and M66 to not confirm tool change has done)
N1008 X52 Z52 T020202 (IMPORTANT!... Confirm tool index by re-specifying the same tool number)

... it may mean that Cooper is Broby ...

[deadlykitten]

hello , check this one :

go @ safe position
M110 T040404 M66 G00 X0 Z5 M08
SB=V1 M13

there are 2 syncros in same line : [ S>C + index ] & [ rapid + clamping ]

M807 is not required

starting the coolant pump when turret is at safe position, allows full presure when M spindle starts

and, offcourse, this variant :

go @ safe position
M110 T040404 M66 M08
SB=V1 M13 G00 X0 Z5 M63

kindly !

ps : beer is ok

[OkumaWiz]

Turret indexing command repeat is not needed. When G01 is executed, turret clamp is checked automatically and will fault if not seen within .5 second. Repeating the T command only slows things down.

More speed can be gained by combining your SB= command on the same line with the turret index.

G0 X1000 Z1000 M203
G0 M110 T040404 X0 Z5 M8 SB=1000
M13

I skip the M66 and go to the limit since it can get you into trouble in the case of a tool indexing past the spindle that may stick out longer than the tool being called and the offset being used. It's OK as long as ALL your tools can clear when indexing. Changing your +Z variable limit accomplishes the same thing when you set it so that all of your tools can clear.

Best regards,

PS> Cooper is in the US and Broby is in Australia I believe.

[broby]

Can DEF confirm that 1. I am NOT Cooper and 2. I live in Australia!

[broby]

Turret indexing command repeat is not needed. When G01 is executed, turret clamp is checked automatically and will fault if not seen within .5 second. Repeating the T command only slows things down.

Wow, dangerous move in my opinion.
You are correct that the machine checks the turret is clamped before executing the G1 command, but unless you are planning on feeding from your index position to the start point of your cycle, then you really need to confirm that the correct tool is in place BEFORE moving to the start point.
i.e. if you move at rapid to a suitable tool change position (which I have always set at a point where ALL tools will clear the Machine/Job)
then execute a unrestrained tool change whilst moving to another position
then move at rapid to the next start point
If this is done without confirming your next tool is in place, then you may well still be indexing into position by the time the machine gets to the start point.
The reason I rapid to a safe tool change position is thus: If for some reason a tool change position confirmation switch is faulty and the turret keeps spinning, then you risk only stirring the air inside your machine.
If you choose a tool change position only 10mm away from your job (might be changing between a Roughing tool and a Finishing tool) and you also have some long tools in the turrent and something fails, you will end up repairing way more than just a faulty switch.
But hey... YOUR machine, YOUR Risk!

[deadlykitten]

hello mr Wizard ... i saw you like boats/waterskiing, so how are the waves ?

More speed can be gained by combining your SB command on the same line with the turret index

yup, nice idea ; CTR targets combining stuff :
... with longer duration : M203, T index, S from 0 to whatever, etc
... with shorter duration : SB from 0 to whatever, M110, M109, etc
... syncro timing/precision, as M61
... M13 is just an impulse to begin SB at a previous read rpm > so there is some time economy, but not as big as the others ... this is why i called it "the cherry on top"

... it can get you into trouble in the case of a tool indexing past the spindle that may stick out longer than the tool being called and the offset being used. It's OK as long as ALL your tools can clear when indexing. Changing your +Z variable limit accomplishes the same thing when you set it so that all of your tools can clear.

i noticed this behaviour : machine keeps same Z after indexing, and thus, in the particular case that you described, it means trouble ... so, in "this way", is required more caution

i eliminated this "requirement for futher caution" by controling the indexing position like this :
... G0 X375-VETFX Z150-VETFZ > thus :
......... after indexing, machine won't compensate Z offset difference, so it won't move
......... it means a better control of the index position, that is not relative to tool offset, but to the turret absolute position
......... this is why all my index examples are with that code in this thread i avoided this syntax, and replaced with " go @ safe position", so to focus on CTR and not on index tricks

I skip the M66 and go to the limit

after a safe position, trigered with G0 X375-VETFX Z150-VETFZ , which in most cases will send the turret in the X_max_limit, i use M66 ; this sounds crazy, but, you know, as someone said " experience is what you need when you ... or something like that " ... here is why :

... if turret indexes at X375, than there is a difference between "G0 X375 Txx0000 ( this cancels T corections ) " and "G0 X375-VETFX (while Txxyyzz is still active)" ; 1st syntax will send the machine always at 375, while the 2nd will mess with mathematics ( positioning error ) as how much is "X375-VETFX", and may deliver X375-0.002, because of cnc reaction time and stuff, so this will miss the index position with 0.002 > M66 will solve it
... sometimes, i do not index at X_max_limit; once i finished coding cutting toolpaths, i target and syncronize index position between operations; thus:
......... always, the "end position" of an operation is the same as the "start position" of the next one
......... "start" and "end" position of same operation are not always identical

so, M66 covers bought cases :
... indexing at random X
... indexing at max_X without Z corections between tools

this is not about this thread, but since the problem poped-out, i just replied

PS : eliminating turret moving to compensate difference between tools Z offset counts as a CTR technique? if so, than is ok to post it into this thread ... i think it may be considered so

[deadlykitten]

hello, also check this codes

1) C>S once operation finished ( with / without M203 ) :

M110
....
go @ safe position M203 M109

2) faster indexing at custom angle; this one :

go @ safe position 
VSZOC=VSZOC+120 ( for example )
M110 T040404 M66 G00 X0 Z5 M08 SB=V1
M13

instead of this one :

go @ safe position 
M110 T040404 M66 G00 X0 Z5 M08 SB=V1
M13 C120

kindly !

[deadlykitten]

but unless you are planning on feeding from your index position to the start point of your cycle

hy what is the probability for this case ? can you share some relevant examples/setups ? why feeding to " cycle start point (CSP)" and not rapid ?

if is really needed, than why not rapid at 10mm from CSP, and after, feed only those 10mm ?

if there is no room for 10 mm, are you indexing that close to the material ? and if so, why not increase the distance, and rapid instead ... so there will be same time

and finally : if there is no room to increase the distance between safe position and CSP, can you share such an example ? it may mean "get a bigger machine"

i.e. if you move at rapid to a suitable tool change position...
then execute a unrestrained tool change whilst moving to another position ...
then move at rapid to the next start point ...

if this means :

cut finished
go safe position
go close to CSP on rapid + M65
go rapid at CSP

than you need, to be safe, a T confirmation before the last line ( if indexing may occur on 2nd rapid) ... but please, can you share some relevant examples / setups ?

and why not index at safe position and use a single rapid move ? what is the difference ? kindly !

[deadlykitten]

if you move at rapid to a suitable tool change position
then execute a unrestrained tool change whilst moving to another position
then move at rapid to the next start point
If this is done without confirming your next tool is in place, then you may well still be indexing into position by the time the machine gets to the start point

if i understood ok, than this code does just that (safe position, rapid M65, rapid):

G00 X375-VETFX Z250-VETFZ
T101010 M66 ( G97 S=V1*0.7 M42 M03 M08 ) G00 X=VSIOX-20 Z250-VETFZ-10-111.337 ( M63 ) M65
G00 X0 Z5

so, after the safe position, there is a rapid for X20 and Z10, that should be short enough so the clamping not to occur

clamping, in this case, does not occure on 2nd rapid, but the machine stops after 1st rapid, indexes, and continues on the 2nd rapid with the correct tool in place

so indexing during 2nd rapid is not a normal behaviour

The reason I rapid to a safe tool change position is thus: If for some reason a tool change position confirmation switch is faulty and the turret keeps spinning, then you risk only stirring the air inside your machine.

is like the rotary mechanism did not stop at a certain angle, but continued ... far as i know, there is a tolerated error, but if that also fails, than turret will become a fan

( . . . . . . . . . . . . . . . . . . . . . . . . )

all this are particular cases with low probability
... what if that fan goes directly into the part ? without using any CTR codes ?
... what if someone feeds from Z800 to Z5 ?
... what if someone uses 2 rapids when turret comes ?

what i mean is that CTR requires caution, and this is more than enough; particular cases, errors, this is something else if someone with less experience on such techniques will read those particular cases with low probability, than will finish with a messed up head, because will consider those cases as normal behaviour, and will straggle to understand them, and in the end will develop an unnatural way of programming, being satisfied that what he does is the best way to do it ... is inconclusive to give such counterexamples

[OkumaWiz]

Wow, dangerous move in my opinion.

!

You are correct if you are using the M65 which ignores the turret position as well as the clamp signal. but if there is no M65 this is not the case. If XZT commands are used on the same line with the Okuma servo turret machine, turret rotation angle is confirmed before rapid move begins, so the only danger is that the turret may not be clamped when a G1 is activated. It only takes about .75 seconds to clamp, so if you are coming from the limit and are approaching with some clearance, the turret is clamped and confirmed before any cutting begins.

If you have the older non-servo machines, The turret angle and clamp are confirmed before the rapid begins, so you are still safe unless you use the M65. Bottom line - avoid the M65. The G1 command triggers a .5 second timer that checks to see if the turret is clamped. If the turret remains unclamped with the G1 active, the machine will go into a turret clamp fault state after .5 second.

I'm not saying that it's not possible to index, rapid, cut, before the turret is clamped in the perfect scenario, but if you are squeaking micro-seconds off of a cycle, you need to know how the machine works in order to maximize your time savings. It will definitely take more time to "re-confirm" the clamp than to understand that it takes .75 to clamp and that it can be done during the rapid and the approach.

My own rules:
Always rapid to limit using M203 (turret unclamp)
Always put XZT on the same line (turret clamps during rapid to part AFTER INDEXING and in some cases during approach - make sure the 2 add up to at least .75 sec)
Never use M65 (that way you will not "still be indexing" during a move.
Always be safe.

That means knowing how your machine works BEFORE you try to implement CTR in a program. Okuma used to make you sign a waiver when getting CTR because it allowed the ignoring of the STM's come first rules. Those days are gone and CTR has become standard on all sub-spindle/twin spindle machines. Even with out CTR, the M203 and XZT commands will still work on all Okuma servo turret machines.

Hope this clarifies the way the Okuma "Thincs"

Best regards,

[deadlykitten]

I'm not saying that it's not possible to index, rapid, cut, before the turret is clamped in the perfect scenario

how ? hypothetical ?

... if you are squeaking micro-seconds ...

program duration varies ... somewhere arround 0.1..0.5 seconds @ each 60 seconds; same part comes with different machining duration, and this deviations, for a 3 minutes program ( ~ simple part) are at a larger scale than 0.1 ; maybe 0.3 .. 0.5, if not 1 second at least, so targeting time economy under 0.5 .. 1 is not so relevant

i am not saying that someone @ cnc zone actually does that, but i meet people that were taking such economies very serious, but generally they don't see the big picture, as that the impact on program duration is small / however, this does not mean that they are wrong

is messed up, but is real as you and me, and is happening a lot of times: this is the explanation : people without technical experience often require controversial tasks ... some just to prove "who is the boss", while others (a few others) have knowledge and see things from a perspective that is not staggered if productivity is at 50% for a few days ... this is elite from this perspective, CTR is useless, because overall, is not so important

[OkumaWiz]

how ? hypothetical ? Let's move 1" away from a part using M203, and index from #1 rougher to #2 finisher using M66. If approach move is small, you will be cutting before the turret is clamped.



program duration varies ... somewhere arround 0.1..0.5 seconds @ each 60 seconds; same part comes with different machining duration, and this deviations, for a 3 minutes program ( ~ simple part) are at a larger scale than 0.1 ; maybe 0.3 .. 0.5, if not 1 second at least, so targeting time economy under 0.5 .. 1 is not so relevant

i am not saying that someone @ cnc zone actually does that, but i meet people that were taking such economies very serious, but generally they don't see the big picture, as that the impact on program duration is small / however, this does not mean that they are wrong

is messed up, but is real as you and me, and is happening a lot of times: this is the explanation : people without technical experience often require controversial tasks ... some just to prove "who is the boss", while others (a few others) have knowledge and see things from a perspective that is not staggered if productivity is at 50% for a few days ... this is elite from this perspective, CTR is useless, because overall, is not so important I've worked with customers where 1 second translates into $50000/yr, so if I can save 1.5 seconds per index and index 10 times during a program, I've just saved 15 seconds. That's worth $750,000 to them annually. Now if you are a job shop that runs 5 parts, you will spend more time "optimizing" that you will save so it may not be as important.

Now if you have a Cad/Cam system, just put it in your post and all indexing optimization is automatic from now forward.

Best regards,

[deadlykitten]

hello mr Wizard .. i never meant to contradict you

Let's move 1" away from a part using M203, and index from #1 rougher to #2 finisher using M66. If approach move is small, you will be cutting before the turret is clamped.

i was refering to a general behaviour, not such a particular case : 2 OD knifes, maybe one near the other, so to index only one post hope there will be no error on G1 while turret is not clamped

even more, replace 1" (25.4) with 5mm should be more than enough

if we go this way, than why not 1 holder for bought ?

I've worked with customers where 1 second translates into $50000/yr, so if I can save 1.5 seconds per index and index 10 times during a program, I've just saved 15 seconds

on my lathes, or, however, on newer lathes, 1.5 seconds is the duration for [rapid-index-rapid-index], so, i guess this comes into consideration on slower machines

That's worth $750,000 to them annually

what about increasing specs with 10..15% and looking for a 10% discount at tools supliers ? is more palpable than CTR

[broby]

Mr Kitty Kat...
You are, I suppose, entitled to your opinion... but you seem to be of the opinion that a saving of $750,000 by adding in CTR is not worth the effort?!?
As stated, CTR comes standard on the machine, no need to "negotiate" a saving on tools, or inserts or anything else for that matter, the saving is there for the taking.
Mind you, negotiating for these savings would be icing on the cake.
You are obviously do not have a business where making many thousands of parts is part of your business, so why not let those that do, take advantage of the benefits of CTR.
Whilst I have never worked a job where I had untold thousands of parts to machine, I have managed to save huge amounts of cycle time over the span of the job, to the point where we have finished the required parts at least a day or two ahead of the projected finish time.
If I were a boss, or a share holder, and found out that your laziness in not implementing CTR on the production line had cost savings in the order of $750,000 then I guess you would be looking for work elsewhere very quickly!
For job lots of only a few items, and you are manually programming, then I would not bother, but as OkumaWiz states, if you have a CAM package, put it in the post and your job is done for life, 1 part or 1 million parts.
Regards.

[deadlykitten]

Hello everyone

so far, in this thread, had been discussed CTR techniques; now, i think, we should discuss the impact for such actions

let's begin with this questions :
... please state CTR importance in a production segment
... please state major factors in a production segment
... please compare CTR with major factors

... please define the " production segment " and "costs" / what's your perspective on this ?

PS > personally, i preffer "buffering" instead of CTR

[broby]

Pretty damn obvious...

CTR = Cycle Time Reduction = Reduce the amount of time a job takes to machine.
Impact of this on production?? Pretty damn obvious! If you can reduce the time spent machining (and I have seen reductions of up to 50%) on any given job, then your machine can spend time machining the next job... i.e. making more parts per shift than your competition = more profit for you.

Major factors? Way to broad a subject to discuss here in the context of CTR.

Tooling costs are a large factor, but then if your machine is sitting there NOT cutting material and is waiting for tool changes and or spindle speed changes, then tooling cost does not really enter the equation.
i.e. the tools will still cut for the same time, once cutting commences, otherwise you are cheating your production. i.e. no matter what else you do to reduce cycle time, the cutting conditions should be the same.

As part of cycle time reduction, that has nothing to do with smart tool changes or speed changes, I will always optimise the depth of cut to eliminate/reduce the number of fluffy cuts.

BTW what the hell are you referring to with the term "Buffering"??? damn man you come up with some odd things at times.

[deadlykitten]

i took 2 operations, turning & milling, and code them : normal and CTR ; difference is 3 seconds, thus 1.5 seconds/index i do believe that there is more than only 1.5 sec/index on older lathes

definetly "yes for CTR" for many small & simple parts

if things go complex ( heavier parts, low tolerances, interventions for measuring, cleaning, corections ), than is not such a big thing

i log data when machining, and thus i see how stable a setup is ; otherwise, you may look at a lathe, and say that "is ok if it's spinning", but over 1 shift there are issues that the operator treats as normal, and don't thinks to report

i wish to finish this tool, and share it, because it shows what is happening into a quantifiably manner, by timing real operations, an so, productivity can be analyzed faster, not at shifts end, or by charting data for production over 1 week, but dynamycally, for each part

this targest something beyond the CTR, that tells you this :
... setup is ok, just put the CTR on it
... setup has CTR, but for nothing

on the other side : if after on year, you realize that internal cost was p$/hour, this does not mean that if you run a setup without CTR, and you lose 5 hours, than you actually lost 5p $; only case where this is possible, is if you have only one cnc with small parts all the time, while, in reality, production segments means much more than that

and if someone is still not convinced, than please consider this : CTR, i don't know if available also on other machines, or only Okuma, is not a critical factor, because production can be delivered without it, so just don't calculate it into cost/hour, but consider it "pure profit" ... and when year ended, CTR profit should be <0.5% ; if CTR profit is important, like >2..3%, than it means that :
... all productivity is stable, and maybe you are in heaven ? so all other costs are minimized and under control
... you deliver small parts as mass production
... machines are old, cycles are short, and CTR really matters

I doubt this is happenig; however, congratulations to the one that fits case 1 or 2 kindly !