Cycle Time Reduction by Cooper Ferguson - Page 2


Page 2 of 4 FirstFirst 1234 LastLast
Results 13 to 24 of 45

Thread: Cycle Time Reduction by Cooper Ferguson

  1. #13
    Registered OkumaWiz's Avatar
    Join Date
    Apr 2009
    Location
    United States
    Posts
    1049
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by broby View Post
    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,

    Experience is what you get just after you needed it.


  2. #14
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by OkumaWiz View Post
    I'm not saying that it's not possible to index, rapid, cut, before the turret is clamped in the perfect scenario
    how ? hypothetical ?

    Quote Originally Posted by OkumaWiz View Post
    ... 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

    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  3. #15
    Registered OkumaWiz's Avatar
    Join Date
    Apr 2009
    Location
    United States
    Posts
    1049
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by deadlykitten View Post
    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,



  4. #16
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello mr Wizard .. i never meant to contradict you

    Quote Originally Posted by OkumaWiz View Post
    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 ?

    Quote Originally Posted by OkumaWiz View Post
    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

    Quote Originally Posted by OkumaWiz View Post
    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

    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  5. #17
    Registered broby's Avatar
    Join Date
    Apr 2006
    Location
    Australia
    Posts
    812
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    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.

    Last edited by broby; 08-10-2016 at 02:32 AM.


  6. #18
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    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

    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  7. #19
    Registered broby's Avatar
    Join Date
    Apr 2006
    Location
    Australia
    Posts
    812
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    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.



  8. #20
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    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 !

    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  9. #21
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello, also, check this code ( CTR when leaving ) :

    Code:
    turning operation
    go @ safe position M05 M63 M09 ( XZ + spindle break )
    if M63 is missing, than turret moves after spindle stops

    ps : beer is still ok

    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  10. #22
    Registered OkumaWiz's Avatar
    Join Date
    Apr 2009
    Location
    United States
    Posts
    1049
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by OkumaWiz View Post

    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.

    ,

    From post #2.

    Even better coding is:

    G0 X1000 Z1000 M5 M63 M9 M203 VLMON[1]=0

    turret will unclamp and spindle will decelerate while rapid occurs to clearance position while load monitor is being turned off.

    Best regards,

    Experience is what you get just after you needed it.


  11. #23
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Hello mr Wizard good to see you

    Quote Originally Posted by OkumaWiz View Post
    From post #2 :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
    i think by this post you were refering to S variations during turret retreat, after operation finished ; if so, when reading it, i did not take it into consideration, because, on osp300, S changes are quick, so i always program necessary rpm after reaching " safe position ", and thus, not when traveling to it

    from some point of view, "stoping the spindle" is something else, comparing to " preparing neccessary rpm in advance "
    from another point of view, both involve " changing rpm", so they are alike

    Quote Originally Posted by OkumaWiz View Post
    Even better coding is: G0 X1000 Z1000 M5 M63 M9 M203 VLMON[1]=0
    i only posted the " example " i could bet that you would underline the M203; from trials, on osp300, M63 is not required when M203 is present

    these variants may be used :

    Code:
    go @ safe position M05 M63 ( * )
     or
    go @ safe position M05 M203 ( * )
     or, the safer way
    go @ safe position M05 M63 M203 ( * )
    
    ( * ) = ( +M09 and/or + close_VLMON )
    i did not expect the VLMON; i think this is the "stem of the cherry on top" > is like a "light CTR touch" : less time economy than other techniques , but well, code gets shorter

    at such level, i believe that is better to not involve the VLMON, because machine may react faster when reading it in a single line, and not in a CTR line, but this is beyond " mere mortals control ", and duration involved is like an eye blink ( fast, not the slow type ) ... all other techniques have visual impact / how would one say that is ok to leave "M13" alone (few posts ago) and use "VLMON" in CTR ? can this be demonstrated ? ... they trigger short ( or the shortest ) duration behaviours

    from another perspective, i avoid VLMON into CTR; this is because general code is :
    .... [ safe position ] [ T ] [ S / SB ] [ approch ] [ cut ] [ safe position ], or
    .... [ safe position ] [ T S / SB approch ] [ cut ] [ safe position ], if CTR used

    VLMON trigers the [ cut ] zone, and sometimes may be needed more than a single instance of "VLMON[...]=0" ; pls see attached image( this image is from another thread, about load monitor ) ... so using the last "VLMON[...]=0" into the "turret away line" is the last thing to do when :
    ... "autoset" delivers wrong values ( this is about tools that machine "can not feel very well" and is a subject for another thread )
    ... load monitor structure is inside a subroutine, thus containing "VLMON[...]=0"

    Attached Thumbnails Attached Thumbnails Cycle Time Reduction by Cooper Ferguson-02-jpg  
    Last edited by deadlykitten; 08-11-2016 at 10:00 AM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  12. #24
    Registered deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    2462
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello, about using VETFX / Z when turret leaves - in post 9 i covered some general aspects ; now i will target on examples, to be more concludent

    indexing may be something like this :

    Code:
       G00 X=V1    Z200
    
       T090909
       G00 X...    Z...
       cut
       G00 X=V1    Z200    T0900
    
       T040404
       G00 X...    Z...
       cut
       G00 X=V1    Z200    T0400
    or however else; in most cases :
    ...... tool offset is canceled when turret leaves ( Txy00 ) ; thus, if tool is changed, than program must be edited in 2 places > VETF* solves that, eliminating last corection, so tool offset cancel is done with a unique syntax, without T : G00 X=V1-VETFX Z200-VETFZ
    ...... if V1 is greater than "+ variable limit(P)", or X_max (if you wish), than approach movement is not diagonal, but 1st among Z and after it goes diagonal; also, about "straigth&diagonal / compound move / non linear vectors" just take a look on attached image

    if tool offset had not been canceled after previous operation, than same " broken vector " occurs at approach movement of actual operation; using the VETF* syntax eliminates the "broken vector" because of not canceling tool offset, so only "G00 non-linear interpolation mode" remains; so, a structure like this may be used :

    Code:
       G00 X380-VETFX Z200-VETFZ
    
       T090909
       G00 X...    Z...
       cut
       G00 X380-VETFX Z200-VETFZ
    
       T040404
       G00 X...    Z...
       cut
       G00 X380-VETFX Z200-VETFZ
    this example delivers same behaviour as the previous one

    decorating it with CTR codes ( like a christmas tree ) is another story

    VETF* = VTOF* [ VETON ] + VTWO* [ VETON ] ( = active offset + afferent wear , * = X Z ), and thus, turret safe position is always the same kindly !

    ps > economy & gain: eliminates turret moving between indexes, if it would occur ... this depends on initial structure used turret retreat line is not depending on T, so operator intervention and CAM structure, are reduced delivers absolute (= constant) positioning ( thus safe to index from longer tool to shorter tool, if turret is behind the spindle ) same control with less code

    Attached Thumbnails Attached Thumbnails Cycle Time Reduction by Cooper Ferguson-01-jpg  
    Last edited by deadlykitten; 08-11-2016 at 10:03 AM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


Page 2 of 4 FirstFirst 1234 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Cycle Time Reduction by Cooper Ferguson

Cycle Time Reduction by Cooper Ferguson