[deadlykitten]

hello let's discuss a bit this common code used to send the turret at index postion :

rapid @ X > soft_limit Z... ( M203 M09 Txy00 etc )
... broken vector occurs, leading to unnecesary movement across Z

soft_limit is not a round value, being particular to the cnc
CAM is usually customized to hit a round value above the soft_limit
also IGF default values behave in the same way

solutions :

1) rapid @ X=common_variable Z... Txy00 ( M203 M09 etc )
... initialize a common_variable with the soft_limit value, and don't use it for anything else

2) rapid @ X+VPVLX-VBZOX Z... Txy00 ( M203 M09 etc )
... this code is general, and does not need a common variable
... avoids the need to declare and secure a common_variable on each lathe
... avoids the need to edit the common_variable each time the cnc is aligned

3) rapid @ X=local_variable Z... Txy00 ( M203 M09 etc )
... put this somewhere near the begin of the program : local_variable = VPVLX - VBZOX
...... avoids the need to calculate the soft_limit each time a retreat movement occurs

4) rapid @ X=local_variable-VETFX Z...-VETFZ ( M203 M09 etc )
... this code eliminates the need to cancel the tool

---

of course, nobody cares about a bit of unnecesary movement if it works, is great ...

the solutions shared are nothing on their own ; just a piece of a puzzle

don't worry, codes had been tested

    LVXP = VPVLX - VBZOX
    V1 = 0

  ( * )

    G00 X+LVXP-VETFX Z150-VETFZ M203
    CALL OCAN Q12

M02

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

OCAN

    V1 = V1 + 1
    T  = V1 * 10101
    X200 Z100
    X+LVXP-VETFX Z150-VETFZ M203
    CALL OWRT

RTS

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

OWRT

    FWRITC t.txt;A

    PUT VSIOX
    PUT '    '
    PUT VSIOZ
    PUT '    '
    PUT VETFX
    PUT '    '
    PUT VETFZ
    PUT '    '
    PUT VAPAX
    PUT '    '
    PUT VAPAZ

    WRITE C

    CLOSE C

RTS

[deadlykitten]

hello all the previous post is about eliminating unnecesary movements when turret goes up, to safe position, thus before the index

now i wish to talk about unnecesary movements after the index

example 1 )
... retreat @ X+ limit, Z=abc (or +T=cancel active tool)
... G00 X+ limit, Z=abc T=new

such code is generally generated by cam or igf, and is pretty comon :
... at the end of the operation turret retreats to home
... at the begining, turret is sent at home, so to index

it may generate a compensation movement on the Z axis, because control will keep same Z value when correction changes

indexing from a longer drill to a short drill will move the turret a bit to left

just be carefull if turret is near the left side of the machine, so not to crash the tools into the metal sheet

there may be some solutions to this; i just wanna highlight the case; my solution will be shared here : http://www.cnczone.com/forums/okuma/...ptive-ctr.html

example 2 )

same, after a turret has index, or more precise after corection has changed ( thus corection may be changed without indexing the turret : for example using a holder with 2 tools, or a tool with 2 diameters, etc ), control will try to compensate for differences

control never compensates on its own, thus unpredictable, but only when a positioning movement occurs

previous example is pretty common, since ( index+home position ) is the way to start an operation

also a C axis comand may move the turret : thus, if you were planing to index, and after that to approach, you may see that there is a turret movement durring C indexing; normally, if there is a lot of clearance, you should not worry, but if you wish to eliminate this movement, please consider this code :

M110
G0 C... X=VSIOX Z=VSIOZ : a C axis comand that also blocks the turret

---

again, such tricks are to smooth the cnc movement, especially when crafting lots of parts

i dont regard this as a few time gain, thus i will craft more parts, because cycle time is reduced

no ... i do it to help the cnc maybe respect to the cnc, but, well, is just a metal box kindly !

[deadlykitten]

hello this one eliminates broken vector behaviour on mills

generally, a broken vector appears when a safe position is comanded outside soft limits

a broken vector is :
... visible when movement to ( from ) safe position involves syncro at least on X&Z axis
... not visible when movement occurs on a single axis ( X for lathes, Z for mills ); in this case, however, a delay occurs

eliminating a broken vector behaviour, and also keeping a full travel to the soft limit, may be done by this code : G00 Z + VPPLZ - VTOFH [ VTLCN ] - 50, which computes the difference between positive_soft_limit and Z_position_of_active_reference_system

"-50" in this case means that safe plane is at 50mm under soft limit

bound this code between VINP* variables, ( showed to me by mr Wizard), and result will be full control on safe plane position + faster execution of positioning movements

it is not such a big thing, but is faster than CAMs defaults : G00 Z999..9999 ( always greater than soft limit ) kindly !

[deadlykitten]

G00 Z + VPPLZ - VTOFH [ VTLCN ] - 50

hello, i am sorry, but there is a problem with this code .... i used it for months, but i noticed today an issue with it

how VMRI requires G15H*, also VTOFH [ VTLCN ] requires G56H*

i discovered this by mistake, and so far i had no problems, because i was always using :

    G56 HA ( tool )
    G15 H1 ( table )
    G00 Z + VPPLZ - VTOFH [ VTLCN ] - 50 ( go up at absolute point )

if G56 HA is after G00 tra-la-la, than machine will not move as it should

a solution is :

    G15 H1
    G00 Z + VPPLZ - VWKAZ + VWKBZ - 50 (*1)
    G56 HA
    M03 S+VC1 ( M08 )
    G00 X0 Y0 Z250
    G00 Z + VPPLZ - VWKAZ + VWKBZ - 50 (*2)
M02

even if G56HA is located between (*1) and (*2), both (*1) and (*2) will end up with same phisical position of the Z axis

---

this is another example of "team vs team"

there is no equivalent on mill for VETF* variable from lathes ...

on a lathe is impossible to issue a T comand without activating the tool corection

a mill requires T + G56 to activate corection

---

i use "G00 Z + VPPLZ - VWKAZ + VWKBZ - constant" only when machining single parts ; on series i have a different approach, which does not involve Z+_soft_limit

kindly !

[deadlykitten]

hello all its been a while since i started using the LVXP, so to remove unnecesary movements when turret is traveling to safe position among X axis ( this thread, 1st post )

today i thought to use a 2nd variable, so to improve things also for the Z axis

until today, all my codes for sending the turret to safe position where like this :
G00 X+LVXP-VETFX Z150-VETFZ (*) , or Z=random_value

now i use G00 X+LVXP-VETFX Z+LVZP-VETFZ, and the result is that i can change Z value for all safe positions inside a program, simply by initializing LVZP right at the begining of a program; this is how the code looks like :

    LVZP = 150
    CALL OLVZ
    G00 X+LVXP-VETFX Z+LVZP-VETFZ
    operation 1
    G00 X+LVXP-VETFX Z+LVZP-VETFZ
    operation 2
    G00 X+LVXP-VETFX Z+LVZP-VETFZ
    operation 3
    etc

OLVZ is there to provide a bit of safety : it will compare LVZP with the longest tool on the turret ( + a safety clearance ), and stop the lathe if LVZP is to small; thus value for LVZP is not generated by the software, but only checked by software

on my lathes, Z_offset=0 represents the turret frontal

at this moment i use a safety clearance of 10 mm if someone will put inside the lathe a longer tool without measuring it, than the turret will crash, but this would happen anyhow, so ...

OLVZ ( checking Local Variable Zet )

  NOEX LV01 = -5678

  CALL OHLVZ LV02 =  0
  CALL OHLVZ LV02 = 20

 IF [ LVZP GE LV01 + 10 ] NEND
       NLOOP M0 ( ups )
       GOTO NLOOP
  NEND NOEX

RTS ( . . . . . . . . . . . . . . . . . . . . . . . . . )

OHLVZ ( help 4 OLVZ )

        NOEX LV03 = LV02 + 12
  NLOOP NOEX LV02 = LV02 +  1
        IF [ [ VTOFZ [ LV02 ] GT LV01 ] EQ 0 ] NJUMP
        NOEX LV01 = VTOFZ [ LV02 ]
  NJUMP IF [ LV02 LT LV03 ] NLOOP

RTS ( . . . . . . . . . . . . . . . . . . . . . . . . . )

kindly



(*) actually, my safe position code is more complex, but i wrote it like this so to keep things simple at this level; an update will follow inside the thread where i reveal the codes that i use :

http://www.cnczone.com/forums/okuma/...ptive-ctr.html

[deadlykitten]

OLVZ is there to provide a bit of safety : it will compare LVZP with the longest tool on the turret ( + a safety clearance ), and stop the lathe if LVZP is to small; thus value for LVZP is not generated by the software, but only checked by software

hello / sometimes OLVZ may trigger an error, even if all is ok in reality

it happens when :
... turret tools are changed for a new setup
... newer tools are shorter comparing to previous tools ( eq : switching from "long drills setup" to "turning tools setup" )
... there is a turret post that has been used on previous setup, but, on newer setup, this post is empty ( dummy, etc )

if "Z offset value" for this post is greater than all other "Z offset values", OLVZ will react and stop the lathe

thus there is a remnant offset, which is too big

i handle this case by flashing ( reseting ) all tool corections ( offset, wear, radius ), before measuring the newer tools and starting the new program; kindly

  CALL ORST LV01 =  0 ( resets primary   offsets : between  1 and 12 )
  CALL ORST LV01 = 20 ( resets secondary offsets : between 21 and 32 )


M02 ( . . . . . . . . . . . . . . . . . . . . . . . . )

ORST ( reset tool corections )

        NOEX  LV02 = LV01 + 12
  NLOOP NOEX  LV01 = LV01 +  1
        NOEX VTOFX [ LV01 ] = 0 VTOFZ [ LV01 ] = 0 ( VTOFY [ LV01 ] = 0 )
        NOEX VTWOX [ LV01 ] = 0 VTWOZ [ LV01 ] = 0
        NOEX VNSRX [ LV01 ] = 0 VNSRZ [ LV01 ] = 0
      ( NOEX VP    [ LV01 ] = 0 ) (*)
  IF [ LV01 LT LV02 ] NLOOP


RTS ( . . . . . . . . . . . . . . . . . . . . . . . . )

 (*) ( VP does not exist; it is there to simbolize a system variable used to read/write P value )
     ( P value : the compensation quadrant, for tool nose radius )

[deadlykitten]

hello i wish to share a few cases ( frequently used codes ) that lead to downtime ( tens of a second to seconds )

consider that cutting operation just finished, turret is at point A ( attached image ), and is going to home position

if this code is used : G00 X=a_value_much_greater_then_X_positive_limit Z=whatever, then the movement won't be straight, but executed in 2 lines (AC+CD); CD = downtime
* this case is pretty common; those 2 lines create a "broken vector"

if this code is used : G00 X=a_value_equal_to_X_positive_limit Z=whatever, then the movement will be :
... AC on a cnc with interpolated rapids
... AB+BC on a cnc without interpolated rapids ( again, a "broken vector" )
* so far i have not seen many programmers using an X coordinate equal to machine capability; this is harder to do, because this value is machine specific, and even on 2 identical machines, the X+ limit may not be the same ( 380.031 vs 379.933 ); however, it is possible to code it, by using system variables

thus, a broken vector occurs :
... when X > X+ soft limit
... on non-interpolated rapids
...... or both


when going to safe position, a broken vector = segment 1 + segment 2, where :
... segment 1 = movement among X&Z axis
... segment 2 = movement among Z axis only

---

in some cases, tool corection is canceled, and also the turret (curvic coupling) is unclamped : G00 X Z T0500 M203; there is a potential problem with this code, especialy when there is also a "broken vector"

M203 begins it's execution almost at the same time when "segment 1" begins it's execution

when the turret reaches X positive limit:
... curvic coupling may clamp back any time
... "segment 2" begins it's execution

if "segment 2" is :
... too long, then the curvic coupling may be already clamped back when "segment 2" finished execution, and in this very case, you will lose the M203 benefit ( 0.4 - 0.8 seconds ); this behaviour is caused by the T comand, that is present on the same line with M203
... shorter, then the curvic coupling will remain unclamped, having the turret ready for the index sequence

such a behaviour ( loosing the m203 benefit ) has a big chance to appear on a lathe without interpolated rapids, and far Z safe position

to handle it, it is needed to remove the T, thus replace G00 X? Z250 T0500 M203 with G00 X+VPVLX-VBZOX-VETFX Z250-VETFZ M203 ( or other equivalent variants ); this last code uses system variables, so to always target X+soft_limit, and, as a consequence, on machines where the rapids are :
... interpolated, it removes the broken vector behaviour
... not interpolated, it assures that M203 benefit is not lost, regardless of where is located Z safe position

also, using " - VETF* ", it is achieved the same effect like using Txy00 ( tool corection cancel ), because VETF* stores active tool corection

kindly