Cycle Time Reduction by Cooper Ferguson

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

Similar Threads:

• Bar feed cycle time over - How do I find the Param to change time allowed b4 alarm?
• Cycle Time
• run time cycle
• Cut off cycle time
• cycle time

[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

[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

[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

[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

[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

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

[deadlykitten]

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

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

[deadlykitten]

Hello mr Wizard good to see you

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

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 :

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"

[deadlykitten]

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 :

   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 :

   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

[deadlykitten]

hello mr Wizard sorry if there are doubts in my posts i will try to clear them now

M203 and M63 are unrelated - both are needed

yes, i know ; from trials, i can say that, if spindle is rotating, this code " G0 X_safe Z_safe M05 M63" and " G0 X_safe Z_safe M05 M203" will allow the spindle to decelerate and stop, while the turret is moving; obviously, i do not know why, but is happening ... there is testing/real trials behind all this posts, that took place during time, not just an hour ago i checked it more than twice ... and i will do it again tomorow

Turn off your tool offset cancel parameter and you will not get T0900 etc. which caused the offset to cancel and graphics to "jump".

if T0900 is eliminated, than turret will be moving to safe position with active corection, so, after next index (for example T040404), turret will move with difference between offset_z9 and offset_z4, thus :
... unnecesary movement, which leads to " broken vector " behaviour
... chance to stab long tools into metal sheet, if turret is behind the spindle

such stuff may be avoided in different manners ; VETF* is one of them

so idea was not to "turn off tools offset", but to keep them using alternative codes

Forget your Algebraic code that tends to confuse operators and other programmers when it's not needed

this alternative solution, to me, seems easier why T0900, or T1200, or ..Txy00, when this T dependant code can be replaced with an unique syntax ? so, like this, there is enough to have a single T code, and use all benefits of 2nd Txy00, without writing it ?

what "other operators and other programmers" think, we will see i will do my best to answer

of course, is confusing until is understood ... and how Okuma enabled acces to such variables, than why not use them ? what is wrong in replacing different code lines with a line that is only repeating ?

Shutting off VLMON during the rapid home will not affect auto-set

i did not said such a thing

Your example screenshot...

that is only a piece of a puzzle idea explained more into "load monitor thread" is that autoset delivers limits too high when is used on default groove/cut off cycle this is an issue, and i am still working on it attached images show the effort diagrams for igf and iso programs it can be seen that igf delivers increased values, when iso is more close to the real thing ... limits can be edited ... this is not about 1st and 2nd limits, but about base limit

this is a common case, because 2.5 .. 3 mm width inserts are used often, and autoset will deliver something wrong, and the solution that i found so far involves using VLMON[...]=0 multiple times, and thus, solving the "load monitor behaviour" is much more important than puting VLMON on "turret away" line

i made a lot of posts on this thing, because autoset deliverd limits too big, and knifes got broken, i was desperate ...

You are also wrong that the VLMON command will operate faster on a line by itself. Why do you make statements like that when you have no idea the actual situation?

i did not said that i am sure i used words like "believe" , "may" ... i am sorry for the confusion

do you know what is the time gain if VLMON is used alone or combined ? what do you mean by "actual situation" ?

however, when i post that i had no idea how to verify ; i will create a program, and put in a loop syntaxes with M13 and VLMON, and there will be real durations to analyze

[deadlykitten]

your levels are complete wrong for the next operation following the rapid

please, why do you think so ?

[deadlykitten]

from trials, i can say that, if spindle is rotating, this code " G0 X_safe Z_safe M05 M63" and " G0 X_safe Z_safe M05 M203" will allow the spindle to decelerate and stop, while the turret is moving

i test it again, and nothing changed; "turret move" and "spindle stoping" are synchronously on all this codes :

go @ safe position M05 M63
go @ safe position M05     M203
go @ safe position M05 M63 M203

off course, better use last one

post 6 : 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

post 22 : 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.

to determine the amount of time potential gained, i wrote 2 programs, one with "SB... M13" and "VLMON=0" in separate lines, and another with "M13" alone and "VLMON=0" into "turret away line" ; programs are attached

each program runned for 100 times; time difference = 1 second, thus ~0.01 per program; thus, such tricks don't trigger economy at all at least on osp300

on the other side, here are some interesting conclusions from trials :

1) if "turret away" code is done with active offset, (thus no offset cancel), than turret moves on Z after indexing with difference between "last tool z" and "activ tool z", thus unnecesary movement occurs

to eliminate that, if offset cancel is used like this G0 X1000 Z1000 M5 M63 M9 M203 VLMON[1]=0 T0400, than M203 is useless, because once the turret reaches final position, clamping occurs, because of the T0400

solutions to this :
.... cancel the offset in a separate line, or
.... use G0 X1000-VETFX Z1000-VETFZ M5 M63 M9 M203 VLMON[1]=0 > thus, a single line instead of 2, and no more "unnecesary movement"

2) load monitor must be closed before M12, otherwise breaking effort will stop the machine; break value is 100 ... 160 % ( depends on rpm, but in all cases is greater than runing smooth ) ; all tests have been done with M axis limits at 200(=max), to avoid this situation

an alternative to use VLMON[1]=0 into "turret away line" may be to stop the M spindle after turret reached safe position; in such a case :
... M spins useless
... such a code can not be used " go @ safe position M203 M109 ", and this leads to time loss

thus, close monitoring before

3) G0 X1000 Z1000 ... if X > "+ variable limit(P)", or X_max, than " broken vector " movement occurs

[deadlykitten]

all posts are based on real trials and production prove them to work; i use a lot and recommend such structures :

[ turning ]
T.. M66 G97/96 S_sense gear M08 G00 X.. Z.. M63
cut
G00 X=V1-VETFX Z..-VETFZ M05 M203 M63

[ milling ]
M110 T.. M66 G00 X.. Z.. M08
SB.. M_sense

 or

M110 T.. M66 M08
SB.. M_sense G00 X.. Z.. M63

or 

M110 M08
T.. M66 SB.. M_sense G00 X.. Z.. M63

cut
M12
G00 X=V1-VETFX Z..-VETFZ M109 M203

V1 should not exceed maximum_x_travel, because unnecessary moves appear

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

but CTR ? all techniques described deliver syncro actions, shorter paths ... so each one trigers [ approach / depart while changing rpm] or [ turret index ] or [ cut M61 ], and each one on it's own it is a piece of a puzzle

a cycle means to start and end in same place ... i am not saying that " buffering " is more apropiate, but you use all off them, and the final result is a CTR

by " buffering " i was not meaning the final result, but each one : because mechanics receives signals from electronics, trigered by internal executable, compiled on software, that reads a row of G codes ... each code line is a comand sent to the machine, and is broken into signals, that are packed and sent ... buffer means a lot of things, includind package size ... from this perspective, it has no conection with the fact that cnc reads in advance ( buffer reading )

so, if you combine more codes into same line, you increase the package of output data > means more buffering

CTR means overall result there should be a term for each action ... if you use M61, this does not mean that you use CTR, but 10% CTR

ps : everything is just a humble suggestion ; nothing more

[deadlykitten]

what are you referring to with the term "Buffering"???

i just saw that some reffer to this as Kamikaze codes