Cycle Time Reduction by Cooper Ferguson - Page 4


Page 4 of 4 FirstFirst 1234
Results 37 to 45 of 45

Thread: Cycle Time Reduction by Cooper Ferguson

  1. #37
    Registered
    Join Date
    Oct 2006
    Location
    usa
    Posts
    16
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Any thoughts on reducing a 15 second tool change on a multus?



  2. #38
    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 corey

    1) staging tools; something like this :
    ... operation ( sequence ) begins
    ... tool a is prepared by the ATC
    ... arm swings and tool is loaded inside spindle
    ... next tool is prepared by the ATC, and during this sequence, the program also continues ( thus ATC_movement and working_cabinet_movements are executed simultaneously )
    ... this is based on ingoring the ATC response, thus the program continues without ATC restrictions
    ...... the best way to achieve this is by a tool change macro: pls check post 1 & 2 in here : http://www.cnczone.com/forums/okuma/316654-forum.html
    ...... i will share soon inside there other codes, gathered from arround the world
    ...... good when crafting series

    2) speeding up the traveling to safe position : generally the shortest path, being sure that no interfere occurs + fast rapids + B&R sincro ( B stands for B axis, R stands for rapid, thus rotate the head while travelling to change position )

    3) check heavy tool atribute, maybe arm velocity is always reduced, without being required / kindly

    Last edited by deadlykitten; 11-15-2017 at 06:11 AM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  3. #39
    Registered
    Join Date
    Jan 2018
    Location
    United States
    Posts
    2
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Hey guys. Cooper Ferguson here. Just happened by this thread last night and figured I should join. A little late to the party, I know. Better late than never?



  4. #40
    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 Cooper, i am glad you joined i am sure that your experience can enlight many of us / kindly !

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


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

    Default Re: Cycle Time Reduction by Cooper Ferguson

    check this out :

    Code:
        T+LINK*10101 M66 G97 S+V1 M42 M03 M08 G00 X2*13.25 Z-3 M63 F+V2 G95 G41 K-1 M65
    ... positioning for comp toolpath executed :
    ...... with imaginary vector ( disables comp lead-in movement )
    ...... without rpm confirmation
    ... [ 'on the fly' index ] & [ variable safe positions ]
    ... last but not least : feed specs & coolant





    safe positions are relative to actual turret position; if this position is :
    ... unknown, then indexing is executed at a position with increased clearances
    ... known, then indexing is executed at a position with low clearances + maybe_M65 ( during approach )


    i hope that this explanation is as simple and clear as possible, thus i try to transmit the idea with minimal explanations / kindly !

    Last edited by deadlykitten; 05-23-2018 at 07:06 AM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  6. #42
    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
    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
    hello mr Wizard

    SB is non-execution code, and requires 8-50 ms to be processed, regardless of where it is located

    however, the block "G0 M110 T040404 X0 Z5 M8 SB=1000" requires more then 50ms to be executed, before continuing to next block, so, indeed, using SB like you said, leads to a bit of time gain

    M13, on his own, requires circa 150-350ms ( acceleration chart attached ), and this leads to a visible stop, thus the turret will wait for the SB to speed up, so next code should perform faster, because the approach duration is comparable to ( bigger than ) the live-axis acceleration time

    Code:
    G0 X1000 Z1000 M203
    M110 T040404 M08
    G0 X0 Z5 SB=1000 M13
    attached codes show that 130-180ms can be gained like this, for an rpm range between 250 2500

    also, adding M63 will shave an extra 20ms, but i don't know exactly what it is ignoring; attached

    things depends on scenario, machine, etc, but at least for osp300, so far i have not seen codes that perform faster

    Code:
    G0 X1000 Z1000 M203
    M110 T040404 M08
    G0 X0 Z5 SB=1000 M13 M63
    attached codes are not using the broken vector behaviour / kindly

    Attached Thumbnails Attached Thumbnails Cycle Time Reduction by Cooper Ferguson-01-png   Cycle Time Reduction by Cooper Ferguson-02-jpg   Cycle Time Reduction by Cooper Ferguson-03-png  
    Last edited by deadlykitten; 02-06-2019 at 06:16 PM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


  7. #43
    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 broby View Post
    Code:
    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 M66 to specify free turret indexing when not home and M65 to not confirm tool change has done)
    N1008 X52 Z52 T020202 (IMPORTANT!... Confirm tool index by re-specifying the same tool number) 
    You MUST confirm that the selected tool is in position prior to moving in to the start point for machining as you can imagine the crash occurring if the turret is still rotating when positioned near the part/chuck!
    hy broby i know that text that i quoted is from 2016bc, but there is a case when confirming T can be done "at the start point ( clearance position )", instead of " prior to moving in to the start point "

    for example, if there is a single long drill, and all other tools are normal face knifes, i can use next code without worries :

    Code:
        home position
        G00 X0 Z2.5 T=drill M65
        T confirm ( only confirmation, no linear movement occurs )
        // in this case, at this position, i can rotate the turret for a full revolution without worries
    it is only a particular case, and, even if it works, it does not occur frequently, so maybe it does not sound reasonable to be used in reality



    ok, now, please, let's consider another example : there are 2 identical face knifes ( T1_rough & T2_finish ), and all other tools are long drills; only when i index from T1 to T2, i can use this code :
    Code:
        cutting with T1
        home position
        G00 X0 Z2.5 T2 M65
        T2 confirm ( only confirmation, no linear movement occurs )
        // in this case, at this position, i can rotate the turret for a 360/12 degress, thus only for a single index
    again, it is only a particular case, and, even if it works, it does not occur frequently, so maybe it does not sound reasonable to be used in reality


    so, even if there are cases that allow confirming T at clearance position, instead of " prior to moving to clearance position", their probability of occurrence is questionable; main answer is "better be safe than sorry", so, looking from this perspective, your approach, your code, seems ok



    the dynamic indexing code, that i developed, is a "live?" code, that adapts even after small offset changes, like 0.001 ( uses system variables ), and "decides" where to send the turret for next index sequence, and also checks if it can perform an on-the-fly index, by using M65; in other words, it raises the probability of occurence ... and onestly, i don't know where it will index precisely, and this "unpredictible" side is what i like about it ( there are safe boundaries, that are always changing )


    Quote Originally Posted by OkumaWiz View Post
    Repeating the T command only slows things down
    yup, this is true, there is a downtime created by repeating the T command

    since how i can confirm the T at clearance position, and not before approaching it ( i can approach+M65 without broken vector), i simply reduce the downtime by repeating the T command inside a block that contains a feed movement

    Code:
        home position
        G00 clearance position T M65
        G01 T=confirm
    

    even if a code is using M65 and it is collision-free, there are some things that need to be considered, so to speed up the cycle time, but this is a story for another time / kindly

    Last edited by deadlykitten; Yesterday at 10:03 AM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


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

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Well, I suppose if you are confident that EVERYTHING is programmed correctly, machine is performing CORRECTLY and the Stars are aligned in your rising moon, the pond out back is OK and the frog is not hungry, then by all means, go for this type of action, me...? I would like to take no chance that the operator has done something silly, or that a tool change limit switch has not failed (seen this a few times now) and know that the machine will be around for some time yet. I have seen a long tool index into a spinning chuck, not a good outcome, with the result being the turret casting cracked and the machine written off... why? Faulty tool change limit switch, tool change done too close to the chuck and BANG! (none of this done by me either!)



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

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hy broby please, what is a limit switch fail ?

    if you are confident that EVERYTHING is programmed correctly
    yes, i am, and future add-ons should deliver more time gain & less configuration time, but i need time to reach that level

    I would like to take no chance
    it seems risky, actually it is very risky this is a piece of a puzzle, and going faster without safety may not end good

    i have taken into consideration fails from both operator or machine; obviously, not all of them, but at least those ones that i am aware

    i did mistakes, novice operators do mistakes frequently, and also experimented operators do mistakes; maybe not so often, but after a while, long shifts, extra-hours, etc

    machine settings :
    ... turret index @ 65%
    ... heavy tools
    ... lower servo torque
    ... rapid key at slow position

    g-code preamble :
    ... checking machine state ( Coff, Yoff )
    ... checking axis position ( turret position, tailstock position, etc )
    ... checking tailstock table for compulsory values
    ... checking initial safe position & comparing it to all offsets, so to ensure an initial clearance >=15mm (eq)
    ... axis monitoring @ 80% by default
    ... logs are started :
    ...... program & tools offset : absolut value & change history (*1)
    ...... zero's detected by torque functions (*1)
    ...... axis load (*1)(*2)
    ...... parts counter

    safety checking g-code procedures (*1)
    ... all operator input through panel is verified to be within safe (±0.5mm eq) tolerances ( offsets, zeros, variables, etc )
    ... preparatory programs

    applications for ease-of-use
    ... alternative input interface ( 1 keystroke away )

    only a few of all these safeties can be implemented on a cnc <> okuma

    even so, stuff happens, but i have more peace of mind when i am away / kindly


    (*1) such functions i turn on, only for long setups; 2+ weeks
    (*2) still working on it

    Last edited by deadlykitten; Yesterday at 01:27 PM.
    Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg


Page 4 of 4 FirstFirst 1234

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