Cycle Time Reduction by Cooper Ferguson - Page 2


Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 52

Thread: Cycle Time Reduction by Cooper Ferguson

  1. #21
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by deadlykitten View Post
    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 !
    now i do please stand by

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  2. #22
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello again link : https://www.okuma.com/blog-cycle-tim...axis-unclamped



    if you are experiencing problems :
    ... even if M147 is used, consider a delay timer so to let the breaking mechanism fully engage
    ... without M147 :
    ...... if clearances are low, consider a delay timer to let the axis get in default droop, even if G64 is used
    ......... actually "using G64" means that "you dont use G65", since G64 is default state at power on
    ...... if clearances are low, you may avoid the timer by using G65 ( just like mr Ferguson said )
    ...... using droop control means more precision, and if you dont wish to use it, and still be sure that no interference will occur, simply increase the clearances

    and last but not least, if C axis is struggling to hold position :
    ... check attached files ( SPINDLE SERVO DATA SELECTION FUNCTION )
    ... if it still fails, than you may need intervention underthehood : especially for heavy parts



    personally, i dont use drilling cycles, because of some limitations :
    ... you can not adjust rpm after a specifc depth
    ... you can not use multiple feeds
    ... you can not use variable pecking depth, etc
    ... cycle have extra/unnecesary movements

    kindly !

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  3. #23
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    i guess i should say that i attached a file, but is obvious ...

    hmm

    a guy just came at me last week to hire him : 12years experience within machining/metals/cnc field, etc

    he seems to know some technology and programing from the machine panel, and some Gcodes

    he does not now CAM, because his boss did not wanna buy such stuff, and the cncs where he works are all old ...

    anywhay, this guy is from another town, and i asked him why changing the town, after 12y in same place ?

    .... there is a girl in this/my town you know ...

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  4. #24
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hy CTR codes that i use :

    T : active tool
    S : rotation ( S or M axis )
    R : rapid

    1) turret is at safe position, next operation is :
    ... turning :
    ...... T S R M66 M63 : concomitent ( spindle start ) + ( index start + rapid approach after index )
    ... milling :
    ...... M110 T : concomitent ( C axis engaging start ) + ( index start )
    ...... S R M63 : concomitent ( spindle start ) + ( rapid approach start )
    .... bar puller :
    ...... M19 T M66 : concomitent ( orientation start ) + ( index start )
    ...... M19 T M66 R : concomitent ( orientation start ) + ( index start ); ( rapid ) is executed after
    ......... otherwise, if ( orientation start ) would be syncro with ( rapid ), a crash may occur, for example the jaws of the chuck when rotating may hit a tool on the turret if spindle is allready oriented, than a tool may have the frontal between jaws closer to chuck frontal

    2) turret should go to safe position ( actual operation > next operation )
    ... R M203 M05 M63 ( turning > milling ) : concomitent ( rapid start ) + ( hydra unclamp ) + ( spindle starts decelerating )
    ... R M203 M109 ( milling > turning ) : concomitent ( rapid start ) + ( hydra unclamp ) + ( C axis disengage )



    other codes, proved to work, but i dont use them :

    1) turret is at safe position :

    ...T M65 R : on the fly index
    ...... i dont use it because zbang

    2) turret should go to safe position

    ...M05
    ...R M110 M203 : concomitent ( rapid start ) + ( C axis engage ) + ( hydra unclamp )
    ...... i dont use it because it performs slower than the example showed to switch from turning to milling

    ...M05
    ...R M110 M203 T M66 : concomitent ( rapid start ) + ( C axis engage ) + ( hydra unclamp ) + ( index start, thus indexing while moving )
    ...... this code does on-the-fly index, but not when turret is approaching, but when leaving
    ...... i like to call this code ping-pong, because it is ok when turret is sent between spindles
    ...... i dont use it because i dont have a 2nd spindle

    ...rapid@X+limit M203 T : concomitent ( rapid start ) + ( hydra unclamp ); index is done after turret reached X+limit
    ...... i dont use it because i dont like T comands, thus next tool preparation on the retreat move of actual operation
    ...... normally, such syntax is used with T to cancel active tool, not to call next tool
    ...... but is not necessary to cancel active tool before calling next tool

    kindly !

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  5. #25
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello all another thing that i do, when OD roughing for example, is eliminating feed movements that are only towards X+

    normal movement inside a rough cycle is :

    1) ... approach
    2) ... x- at 1st cut position
    3) ... z-
    4) ... x+
    5) ... x+ & z+ ( tool disengage from material )
    6) ... z+ back at clearance
    7) ... x- going back at X for 1st cut
    8) ... x- going futher at X for 2nd cut
    9) ... and so on

    this is what i do :

    1) ... approach
    2) ... z-
    3) ... x+ & z+ ( tool disengage from material )
    4) ... z+ back at clearance
    5) ... x- going at X for 2nd cut
    6) ... and so on

    even if Z surface is bumpy, next tool may perform smooth

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  6. #26
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    Quote Originally Posted by deadlykitten View Post
    ...... M19 T M63 : concomitent ( orientation start ) + ( index start )
    ...... M19 T M63 R : concomitent ( orientation start ) + ( index start ); ( rapid ) is executed after
    ......... otherwise, if ( orientation start ) would be syncro with ( rapid ), a crash may occur
    i just have encountered a case where chuck orientation and rapid should be executed concomitent; this is the code : R M19 M63, where R stands for rapid : G00 X... Z...

    it seems that M63 is not only for spindle rotation answer signal ignore in S mode, but also in M19 mode

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  7. #27
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  8. #28
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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 !

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  9. #29
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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 !

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  10. #30
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  11. #31
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  12. #32
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  13. #33
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    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 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) 
    
    hello if i may, let's boost that code, making it to perform faster; stuff shared in this post is pretty osp-specific confirming the T command inside another block, may lead to shaving few tens of a second

    removing comments, sequences, adding code identation :

    Code:
        G00     Z800 G97 S1102 M63
            X52 Z800 T020202   M65 M66
            X52 Z052 T020202
    removing arguments

    Code:
        G00   Z   G97 S M63
            X Z T       M65 M66
            X Z T
    replacing G00 with "rapid"
    replacing XZ with "ip" ( in-position )
    removing spindle codes ( S G97 M63 ), because, what is to come, does not involve the spindle

    Code:
        rapid ip
              ip T M65 M66
              ip T
    pseudocode for 1st line

    Code:
        home position
        rapid ip T M65 M66
              ip T
    adding the "cutting" code

    Code:
        home position
        rapid ip T M65 M66
              ip T
        feed  ip
    moving the 2nd T, so to shave a few tens of a second

    Code:
        [ sample 1 ]
    
    
        home position
        rapid ip T M65 M66
              ip
        feed  ip T
    
    
        [ sample 2 ]
    
    
        home position
        rapid ip T M65 M66
              ip
                 T
        feed  ip
    explanation :
    ... approaching is done in 2 segments :
    ...... during 1st segment, turret will rotate until rotation angle get's into in-position
    ...... 2nd segment won't begin it's execution, unless turret rotation servo is in-position; this is because M65 is one-shot, and not modal
    ... when 2nd segment begins it's execution, turret begins to clamp
    ... turret has to be clamped before begining the "feed" movement, but it is not critical to be clamped before executing the 2nd rapid, thus is not critical to have the T comand where it was before
    ... if T comand is in line with the 2nd rapid, then the 2nd rapid will begin it's execution only after the T was confirmed, thus only after clamping occured
    ... if T comand is after the line that contains the 2nd rapid, then there is a chance to achieve CTR, especially when 2nd rapid is long enough for the turret to clamp during the execution of that 2nd rapid


    in other words, moving the 2nd T does not mean that a code will perform faster it means that it may perform faster ... some ctr codes are about probability, so, the code has to be written in such a manner, that, when the chance occurs, it will shave time

    i tried to explain this as simple as i could; i hope this is usefull there is an image attached, with data from trials ...





    for those ones, that could follow until here, i will continue with this code :

    Code:
       home position
       rapid ip T M65 M66
       feed  ip T
    that sample is what the dynamic indexing codes, that i use, are capable to deliver : on the fly index + approach among a single segment

    there are some requirements to implement this, and one of them, is handling a special case, that does not always occurs : turret continues to rotate when it should be clamping : if heavy tools are used, even if the rotation servo believes that it is in-position, in reality, the extra-mass of holders has inertia, forcing the turret to rotate an extra few degrees : as a consequence, turret may still be agresively rotating when the feeding begins, breaking cutting edges, etc

    to handle this, is needed to change the cynematic specs of the turret rotation motion :
    ... rotation speed
    ... heavy tools parameter activated

    such behaviours varies from one lathe to another, and, even for same lathe model with same osp, there are differencies between models manufactured across years, because osp is continuosly updated / kindly

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  14. #34
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hy broby

    From what I gather, you do not work in a mass production workshop, making thousands upon thousands of parts, where saving fractions of a second really make an impact
    since when i started programing cncs, mostly, i have had long terms setups : 2-3 weeks to 10-11 months; is like listening, on repeat, to the same song ... at one moment, it gets into your head

    in such a situation, 2 things may happen :
    ... you get bored, and monotony, will kill you
    ... you try to get the best out of this oportunity, in order to improve your methods

    Have you seen any return on the humongous time spent figuring all this out?
    of course, i have seen
    ... previous post shows how to squize even more from M65; those attached charts shows time in ms, and it can be seen that in some cases there are achieved reductions of 0.2s
    ... thread " send turret at X+_soft_limit " shows how to remove the broken vector, and how to avoid the downtime caused by canceling the tool with T0100
    ... thread " optimal clearances " shows how to reduce clearances, and scratches a bit the surface of using M66

    there is more, and i have other tricks, that i just did not shared yet; for example, if you use G87, G85 ( default cycles ) after M65, you won't be able to apply the techinque from previous post, because you will need to repeat the T comand line, only once, inside the 1st feed line, and good luck with testing that on machine cycles also okuma osp cycle have auxialary movements ... i have seen recently a fanuc that does not has such extra-movements, but i no longer care, because i program without cycles, without extra-movements, etc

    At the end of the day, production lines are all about the Tak time between processes
    you are right, but so far, for years, i did not had been in such a situation; but i am aware, and my next goal is to speed up small production batches there are differences between small batches and long term setups, and i don't have experience with small batches

    i mean i can program and deliver stuff on my own, but i can not compare to someone that does this on a daily-basis ... but maybe i can compare with persons that raise questions about long terms setups, data logging, stability on long term, etc

    however, one thing is certain : if i would have been in a situation to deliver small batches, then i am sure that i was pretty busy, and not having the time to dig into okuma's specifics

    Don't get me wrong, there is a lot of good information mixed in through all the waffle, but wow, you make it hard to understand at times
    i am not a native english speaker ...

    he's the entire fault finding section of Okuma's R & D department
    come on man, i don't believe that my threads shows that i am highlighting osp faults ...


    however, thank you both for all your tips so far / kindly

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  15. #35
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hy broby, truth is that the long series setups allowed me to focus on soubroutines that do not target the cutting operations, but what happens in between. Yes, i do a lot of testing, and is hard to shave few more tens from a program which is allready tuned, without messing with the cutting specs ...

    as a result, for a simple face & drill program, i may use a bunch of soubroutines, that are always there : ctr, safety, data logs, comunication with 3rd party software, etc

    i know that some of my posts may go to deep inside a rabit hole, but, at this moment, there are 2 things :
    ... complexity that i share when posting is lower then the complexity that i use when creating programs; i try to restrain when posting
    ... so far, i have never shared actual time gain for a setup, but one day i will; i have such data, but i did not shared it, because it involves all the things that i use, not only ctr, and i wish to connect all these things inside a single unit, at that moment, i will share the potential overall time that can be saved + other benefits

    my main problem is not the code behaviour, but the time that i loose with code customizations, and, when i have a bit of free time, i continue to develop, and things never come out good from 1st try / kindly

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


  16. #36
    Member deadlykitten's Avatar
    Join Date
    Jun 2015
    Location
    Antarctica
    Posts
    4131
    Downloads
    0
    Uploads
    0

    Default Re: Cycle Time Reduction by Cooper Ferguson

    hello all mr Cooper Ferguson did a very nice job, at least with the ctr blogs ( www links at post 1 )

    meanwhile, okuma had described almost all of their ctr functions, in more details, inside their latest revisions of the special functions manual ( pls find the *.pfd attached ) ; i like that they show plenty examples for modal M63, and that their codes are indented

    also, inside this thread, there are a lot of ctr codes samples, from experimented members, that deliver





    so far so good / now, i wish to show you a few things; more exactly, i realized that ctr codes is a bit of a gamble ...

    all g-codes ( including ctr ), are always changing their execution duration, and also the moment when the execution begins; a program that cuts air, may execute with different durations if 2 consecutive times are identical, then the 3rd may be different ...

    please, let's take a look at image 1 :
    ... left : a linear code with 6 blocks, that performs 6 actions
    ... right : a ctr code, with 2 blocks, that performs same actions, but faster
    * that image shows what ctr codes are all about, at least theoretical

    in practice, things are a bit different; please, let's take a look at image 2 :
    ... left : each action executes during a time that is never constant; the hatch that i draw over each action, shows the probabilistic time interval during which that action will execute
    ... right : ctr actions may not begin at same moment, thus the moment when actions begin is always changing; considering a base line, some actions will begin sooner, or later; also, between actions, there is a gap, mostly designed to process the confirmation / ipw position / etc, and, in reality, that gap means that motion will stop, or close to stopping, or discontinue

    i hope that things make sense so far

    the problem with gambling appears ( more precisely it's effects are increasing ) when ctr actions have a deviation time which represents an important fraction of the base time: for example, if an operation requires 10±0.1 seconds, then is all ok, but an operation that requires 0.3±0.05, or 0+0.2 is a problem, because the time-chart is no longer repetable; in image 3, is shown such a case, with actions that require execution time of few tens of a second, but, because of " overall execution time deviation " and " unstable start moment ", in the end, the ctr code may not always deliver 100% ctr behaviour

    debuging a code with unstable overall execution time, requires patience

    a good ctr code should deliver the shortest execution duration, regardless of overall execution time deviation / kindly

    we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...


Page 2 of 3 FirstFirst 123 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