[deadlykitten]

I typically use the Auto Set to capture the values and then run my AUTOSET-FIXR program to automatically correct the values to useable levels. I've tried multiple times to get Okuma to change away from the base x % values they use since for example at a 10% load it will auto set at 10, 11, and 12 which is too tight and at 100% it will set at 100, 110, and 120 which is too loose. My Program changes the values to Base + a fixed value so that you have a 99% chance of success rather than a 99% chance of failure with the Auto Set.

hello, i reloaded your AutoSet to work for my LB3000ex2 lathe ... off course, if base level is 0, than 1st and 2nd limits will reset.

even if this behaviour would be default on Okuma, i think that is the same amount of time, going inside paramaters and changing "amount 1 & 2 " + " lower & upper limits for base ", or using this code

just change values before ( * ), and let it go

    V1 = 7      ( lower limit for base value  )
    V2 = 14     ( upper ... ... ... ... ...   )

    V3 = 3      ( amount to add for 1st limit )
    V4 = 5      ( ... ... ... ... . 2nd ...   )

    V6 = 1      ( begin at adress V6 )
    V7 = 64     ( end ... ... ... V7 )

     ( * )

    V5 = V6 - 1
    NHERE
    V5 = V5 + 1
    CALL OSUB
    IF [ V5 LT V7 ] NHERE

    M02

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

    OSUB  
          CALL OX
           CALL OZ
            CALL OS
             CALL OC
              CALL OM
    RTS

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

    OX

        CALL OHELP V10 = VLMXB [ V5 ]    V11 = VLMX1 [ V5 ]    V12 = VLMX2 [ V5 ]

        VLMX1 [ V5 ] = V11
        VLMX2 [ V5 ] = V12

    RTS

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

    OZ

        CALL OHELP V10 = VLMZB [ V5 ]    V11 = VLMZ1 [ V5 ]    V12 = VLMZ2 [ V5 ]

        VLMZ1 [ V5 ] = V11
        VLMZ2 [ V5 ] = V12

    RTS

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

    OS

        CALL OHELP V10 = VLMSB [ V5 ]    V11 = VLMS1 [ V5 ]    V12 = VLMS2 [ V5 ]

        VLMS1 [ V5 ] = V11
        VLMS2 [ V5 ] = V12

    RTS

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

    OC

        CALL OHELP V10 = VLMCB [ V5 ]    V11 = VLMC1 [ V5 ]    V12 = VLMC2 [ V5 ]

        VLMC1 [ V5 ] = V11
        VLMC2 [ V5 ] = V12

    RTS

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

    OM

        CALL OHELP V10 = VLMMB [ V5 ]    V11 = VLMM1 [ V5 ]    V12 = VLMM2 [ V5 ]

        VLMM1 [ V5 ] = V11
        VLMM2 [ V5 ] = V12

    RTS

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

    OHELP  IF [ V10 EQ 0 ] NRST    ( n_reset   )
           IF [ V10 NE 0 ] NCNTN   ( n_continue)

           NRST V11 = 0
                V12 = 0
                GOTO NSKIP

           NCNTN IF [ V10 LT V1 ] NSKIP
                 IF [ V10 GT V2 ] NSKIP

                 V11 = V10 + V3
                 V12 = V10 + V4

           NSKIP

    RTS

to make it work for LT200-MY, just change it's main core ... hope it works

G13
G140
CALL OSUB
G14
G141
CALL OSUB

sad, but it won't replace root beer !

[deadlykitten]

NC torque limiter - always ON monitoring for crashes

hello, one operator forgot to remove the part when program finished, and so machine crashed

i saw that X axis effort stopped at 196% ...

please, is there a way to edit this values ? like to stop when effort is 100 or 120 ?

also, where can i find this crash limits ? kindly !

[deadlykitten]

or please, at least to know that this limits cannot be changed ... kindly !

[OkumaWiz]

or please, at least to know that this limits cannot be changed ... kindly !

NC torque limits cannot be changed.

That is what torque limit is for. Use the G29 command in an area where the collision might occur if a part is not unloaded.

G29 PX=60 is more like what you want. 100-120 would be too high.

Best regards,

[deadlykitten]

hello mr. Wizard, this post is about what i did before your answer post 24

i did not expect such a crash ... being an operator can be boring, and so stuff happens

a recent study revealed that accidents on highways occur because they are straight and drivers get bored / sleep, etc

crash effort was X=196% ... 2nd day i feed intentionally Z axis into material, in MDI ( G01 Z=VSIOZ-100 F50 G94 ), and machine stoped at >300% ... i don't know exactly at what value it stoped, but i can tell that i was with eyes on effort values ( attached image ), and Z bar got full

also i checked errors :
1181-11 and 1098-11 on crash
1181-13 and 1098-13 on intentionally feeding
....1181 = following error
....1098 = power off
....11 = X ... 13 = Z axis

so machine behaved like there was a folowing error and it stopped ? i discused this with machine dealer, because it makes no sense .... i mean i prefer machine to stop from a crash error, and not a following error

dealer said that machine :
....when efforts reach a crash limit, it displays 1181
....after, it stops, 1098occurs, but does not display 1098, since there is allready displayed 1181
....also, Z limit is > X limit, because on X limit, turret mass is taken into consideration

i asked for limits values for each axis, and i still wait for an answer ...

i hope that machine stops because of raised effort, and not because of a following error ...
i still wait for crash limits for each axis ... and i wonder why on Z it stopped at an effort >300 %

[deadlykitten]

hello again mr. Wizard, this post is about what i did after your advice from post 24

N1   G00 X375-VETFX Z150-VETFZ
N2   T101010 M66

N3   G00 X108.5 Z53.8
N4   G29 PX=35 
N5   G01 X90 F500 G94
N6   G28

N7   G00 X0 Z10

to wisely use time, i used G29 ( trq limit ) only on a small area, where collision might ocure ... before and after this area i sticked to G00

F500 and PX35 is safe enough to let the machine actually crash again, and again, and again ...

now, how i got to this values :
..... i started with F8000 and PX60, and there was an error at line N5, more precises when movement under G01 finished, not when G01 started ... maybe break was hard and effort got bigger than 60 ... i don't know
..... i increased PX60 to PX100, and it work; i did not yet crashed turret into material, because i did not like the PX100 limit
..... i keeped PX60, and i decreased feed to potentiometers to 80%, and so, at F6400 and PX60 machine worked
..... i crashed it intentional ; crash was softer than the one that ocured 2 days ago, but still powerfull
..... i machined some parts, and dimensions did not change; after the crashed from 2 days ago, dimensions increased with 0.15 .. 0.18, so turret moved a bit, but i can still turn ... next setup is a 7D hole, and i will align the turret between setups
..... i decreased PX from 60 to 20, and machine stoped at line N5, because G01 requires more effort to start
..... so i decreased feed to 4000, than 2000, and i looked at the machine how it moved ... it moved well, but when reaching line N6 it was a sound from the machine that i did not like .... machine was moving, but there was an internal " zbang " at line N6
..... i decrease feed even more, but sound still ocured ; after trials, i understood that i must raise PX; " zbang " dissapeared at PX25, and for safety reasons i addopted 35
..... i moved again the machine, and i saw that it takes too much time to come from "safe position" to " material front ", so i reduced " hot area " from " all travel " to " necessary travel "
..... i moved again the machine, and i adopted F500
..... i crashed it intentional ; crash was light ; safe repeatable ... bingo

feeding at a certain F=feed_value requires a minimal PX/PZ=minimal_value, otherwhise " start acceleration " or " end break " current will stop, because " minimal_value " is too low

if arround this " PX/PZ=minimal_value ", than internal " zbang " occurs ... so machine will move, but something will make it stuck ... to avoid this, must be increased " PX/PZ=minimal_value ", until movement occurs without internal " zbang "

[deadlykitten]

mr Wizard, i want to thank you for your help ... your thinking is too the point ... i do not know if i would have such an idea, like to use G29 also to avoid a crash

today, so far, i did not stuff that i planned ... i am glad i can further protect machine now ... hope sharing this experience will help at least someone

here, have these kneeled crusader as a sign of my respect and these lyrics ... lyrics about you :

Yeah I'm young, but a nigga from the old school
On the dance floor, a nigga doin' old moves

https://www.youtube.com/watch?v=GllEDACUbNo

[deadlykitten]

hello, i have an issue with load monitoring : after "autoset", i got 10 11 12 ... however, when changing to " monitoring ", machine stops before cutting ... to avoid this :
.... i raised imune time from 0.4 to 0.8 > nothing
.... i changed limits from 10 11 12 to 18 18 19 ...

why does machine stops in air, before cutting, on values delivered by " autoset " ?

[deadlykitten]

material is 60mm ; this is a cut operation, with a 3.1width insert, on a blade

OS02

V2 = 0.09*0.8    ( f )

G00 X190-VETFX Z220-VETFZ
T090909 M66
G97 S750 M03 M08 G00 X100 Z-26.3-3.1 M63

G01 X65        F0.067 G95

    VLMON[1]=1
G01 X55        F0.067 G95
    VLMON[1]=0
    X=VSIOX+0.6

    X=VSIOX+2
G97 S1000 M03 M08

CALL OQ02 V3=50
CALL OQ02 V3=45
CALL OQ02 V3=40
CALL OQ02 V3=35
CALL OQ02 V3=30
CALL OQ02 V3=25
CALL OQ02 V3=20
CALL OQ02 V3=15
CALL OQ02 V3=10
CALL OQ02 V3=5
CALL OQ02 V3=3

G00 X65

M05 M09

G00 X375-VETFX Z220-VETFZ

RTS

OQ02

    VLMON[1]=1
G01 X=V3 F=V2 G95
    VLMON[1]=0
    X=VSIOX+0.6

RTS

machine always stops between X65 and X60, even if it did not start to cut

i have modified the program, so to begin cutting at X100

i took the effort diagram from the machine

between X100 and X65, rpm & feed are constant, but on the chart, machine starts with a lot of effort, and it gets lower and stable arround X80

so effort drops from high to low during a 10mm travel; effort is big, but machine is not cutting

this can not be solved by increasing load_monitor_imune_time

i changed code like this ( blue color ) : cut from X70 -> X65 -> X65+7 > X55 ... so i added extra movements equal with 5+7+7=19mm, and after this 19 machine stabilizes ...

OS02


V2 = 0.09*0.8    ( f )


G00 X190-VETFX Z220-VETFZ
T090909 M66
G97 S750 M03 M08 G00 X70 Z-26.3-3.1 M63

G01 X65       F0.067 G95
   X=VSIOX+7 ( @ +7 it works; if lower than 7, than machine stops )

    VLMON[1]=1
G01 X55        F0.067 G95
    VLMON[1]=0
    X=VSIOX+0.6


    X=VSIOX+2
G97 S1000 M03 M08


CALL OQ02 V3=50
CALL OQ02 V3=45
CALL OQ02 V3=40
CALL OQ02 V3=35
CALL OQ02 V3=30
CALL OQ02 V3=25
CALL OQ02 V3=20
CALL OQ02 V3=15
CALL OQ02 V3=10
CALL OQ02 V3=5
CALL OQ02 V3=3


G00 X65


M05 M09


G00 X375-VETFX Z220-VETFZ


RTS


OQ02


    VLMON[1]=1
G01 X=V3 F=V2 G95
    VLMON[1]=0
    X=VSIOX+0.6


RTS

i think i must find out what causes this " high_effort > low_effort behaviour", or maybe i will use 2 VLMON adresses ... i don't know yet

[deadlykitten]

hello, i have an issue with load monitoring : after "autoset", i got 10 11 12 ... however, when changing to " monitoring ", machine stops before cutting ... to avoid this :
.... i raised imune time from 0.4 to 0.8 > nothing
.... i changed limits from 10 11 12 to 18 18 19 ...

why does machine stops in air, before cutting, on values delivered by " autoset " ?

i would not have post this, but tool gets broken at effort=19, so i just wish to monitor at effort=12 .. 16max ; kindly !

[deadlykitten]

to avoid doubts, i used a G75 cycle to cut :

G270
CLEAR
DRAW
N0001 M216
N0002 G00 X500 Z200
N0003 G50 S2000
NAT09
N0100 VLMON[1]=1
N0101 G97 S997 M42 M03 M08
N0102 G00 X65 Z-29.4 T090909
N0103 G73 X5 Z-29.4 D5 L100 F0.072 E0.12
N0104 VLMON[1]=0
N0105 M05 M09
N0106 G00 X500 Z200 T0900
N0107 M215
N0108 M02

recorded values by " autosetting " are 33 36 39 ... this values are way too much

i have attached the effort diagram : process gets stable after 20mm ...

is it possble for load monitoring to work only from a minimal value ?
so machine is not sensitive to little tools ?
why does the effort drops from high to low ? kindly !

ps > so far i can not monitor X axis for attached tool ...

[deadlykitten]

all this starts at post28 ...

i have entered parameters area and set " number of avg. load monitor value collection " to 80, and after i used auto-set to get some values

i changed to monitoring and i have attached the effort diagram .... it obvious that recorded efforts are way too much ...

[deadlykitten]

hello, i have an issue with load monitoring : after "autoset", i got 10 11 12 ... however, when changing to " monitoring ", machine stops before cutting ... to avoid this :
.... i raised imune time from 0.4 to 0.8 > nothing
.... i changed limits from 10 11 12 to 18 18 19 ...

why does machine stops in air, before cutting, on values delivered by " autoset " ?

i removed load monitor at proces start, because of the " drop effort curve ", so there is no monitoring on first 5mm

i set " number of avg. load monitor value collection = 4" and o declare load monitor limits : 11 11 11

machine cuts without stopping this time ... however :

.... let's hope that nothing happens on 1st cut, because there is no monitoring, and material crust is hard, and tool is long and vibrates when engaging the material

.... changing this parameter " number of avg. load monitor value collection " worked, but i don't like the way it works; machine should check at specific intervals, and not by " average number of checks "

.... that " drop effort curve " is still a mistery for me

.... i attached the diagram for the ISO code; monitoring is missing for 1st cut ... is interesting that now, there is no " drop effort curve "

[deadlykitten]

i manage to " monitor 1st cut " and also get rid of " drop effort curve " ( atached diagram )

on the other side, i think i got only 4 load checks during cutting 5mm, because " number of avg. load monitor value collection = 4 " ( nalmvc )

i don't know exactly what this "nalmvc" does ... in this case, 4 checks are done where ? anyone into this ?

i will be back with data about this ... so far i can say that the " drop effort curve " :
.... influences " 1st cut monitor values "
.... it can be delayed
.... it depends on turret position before coming at process start point
.... it depends on aproach speed
.... it drastically influences " autoset values " when tools are little

it's a mess ... i hope to put it back clear

[deadlykitten]

hello, after damaging some tools, and after trials, i can say that there is a particular aspect when monitoring a groove insert

in image 1 is effort diagram for code generated by igf

G270
CLEAR
DRAW
N0001 M216
N0002 G00 X500 Z200
N0003 G50 S2000
NAT09
N0100 VLMON[1]=1
N0101 G97 S997 M42 M03 M08
N0102 G00 X65 Z-29.4 T090909
N0103 G73 X5 Z-29.4 D5 L100 F0.072 E0.12
N0104 VLMON[1]=0
N0105 M05 M09
N0106 G00 X500 Z200 T0900
N0107 M215
N0108 M02

in image 2 is effort diagram for iso code

OS02

V2 = 0.09*0.8    ( f )

 G00 X190-VETFX Z220-VETFZ
T090909 M66

  G97 S750 M03 M08
  G00 X65 Z=VSIOZ
  G01     Z-26.3-3.1 F8000 G94

  G04 F2

    VLMON[1]=1
G01 X55        F0.067 G95
    VLMON[1]=0
    X=VSIOX+0.6

    X=VSIOX+2
G97 S1000 M03 M08

CALL OQ02 V3=50
CALL OQ02 V3=45
CALL OQ02 V3=40
CALL OQ02 V3=35
CALL OQ02 V3=30
CALL OQ02 V3=25
CALL OQ02 V3=20
CALL OQ02 V3=15
CALL OQ02 V3=10
CALL OQ02 V3=5
CALL OQ02 V3=3

G00 X65

M05 M09

G00 X375-VETFX Z220-VETFZ

RTS

OQ02

    VLMON[1]=1
G01 X=V3 F=V2 G95
    VLMON[1]=0
    X=VSIOX+0.6

RTS

in image 1, there is a " drop effort curve ", and values delivered by autoset are way too high

in image 2, there is no " drop effort curve ", and values delivered by autoset are ok; iso code also generates a smooth entrance inside the part, and after the crust is penetrated, cutting specs increase

i think this " drop effort curve " appears because of machine dynamics; it can be avoided by :
...stoping the machine for a while before the cut :
....... press step-by-step and wait
....... or use G04 ...
...changing turret aproach from "diagonal" (X&Z) to "2 axis"(X + Z, or no syncro if you wish)

all this to delay the moment between "turret aproach" and "process start", so there is a window during which, i believe, turret reduces inertia and motors have no more a transit behaviour

window duration depends on :
.... load monitor parameter : nr of average value collection
.... turret approach speed

- this aspect comes into play when values that must be monitorized are low
- also, same load monitor values do not apply if turret has more or less holders on it, so it must be checked each time the setup is started again
- in this case, on G73, auto-set delivered limits to high, and so, is important to know when limits can be trusted or not
- to avoid this check, which is done by inspecting the effort diagram, is required :
...... a function that must ring a bell when cutting value is way much smaller than the load monitor limit
...... a better auto-set function ... kindly !

[deadlykitten]

hello, during autoset, there are recorded several values ... "final limit" is equal with the maximum ? or average ?

i am not sure, but i think is the maximum; if so, this explains why auto-set delivers huge limits on G73

[deadlykitten]

hello, during autoset, there are recorded several values ... "final limit" is equal with the maximum ? or average ?

.... 1 month later ( as in movies ) ....

autoset spams a nr of impulses equal with " number of avg. load monitor value collection ", that can be varied between 4 .. 80

interval is 8msec, so duration of spams is [4-1]*8/1000+4impulses ... [80-1]*8/1000+80impulses = 0.024 .. 0.640 seconds, considering impulses as "instantaneous", thus no duration > at least manuals say so

however, if auto-set is used here :
G0 Z_lot_of_clearance
G1 Z-10 F...

than, cutting length is "lot_of_clearance + 10"; duration for the tool to reach Z0 is >> 0.640, but autoset delivers good " load monitor " limits, so duration of spam is not 0.64, and so, i think that "english text" is wrong translated

so, best thing to do is to watch the effort diagram, at least for 1..2 parts, so to be sure that delivered limits are ok especially on tools that the machine can not feel

huge limits on G73 ...

this happend on different codes, and correcting this involves 1st to detect this behaviour by" effort diagram inspection " or by " tools breaking too much " > this takes time; alternative is " load monitor 2 ", which raises an error if cutting effort is too low, comparing to the base limit

using it inside a cycle, is tricky, because will raise an error, for example during rough turning, when tool goes back to front, to prepare for the next cut

LM2 sesizates inapropiate LM values, while it can not be used into cycles ( at least this is what an Okuma tech center replied )

[deadlykitten]

hello, please, how can i setup LM on mill ? mb66vb, osp300

[deadlykitten]

what kind of monitoring is on the mill :
... if time unit is [ 1 second ] ?
... if there is no 1st & 2nd limit, but 1st or 2nd limit, by choosing alarm A or D ?

what means "alarm A" + "load timer = 1 sec" ? means that after nose breaked, it still goes until timer reaches 1 second ... enough to bend/broke a long tool; well, not always, but may happen

again that "ancient japanese technique" ? or mill operators should be more carefull than lathe operators ?

i guess is better to use the mill only on alarm D ... kindly !

[deadlykitten]

hello about low efforts on liveholders, lb3000ex2 osp3oo : M axis effort for :
... endmill o4 z4, 2500 x 0.08
......... 23 before cutting / rotating free
......... 24 while cutting
... endmill o5 z5, 2500 x 0.10
......... 23 before cutting / rotating free
......... 24 .. 25 while cutting

this endmill sometimes broke, and a few parts will be machined without milling until the operator will see that

i thought of load monitor 2 to handle this case, thus avoid machining incomplete parts

if i put same tool in different liveholders, M axis effort for "rotating free state" will vary, especially for straight / simple holders, because of the coolant tight sleves that create friction on the main arbor

of course, this means updating the base monitoring limits as needed . point