load monitor stuff

[deadlykitten]

hello, this monitors Z when drilling :

VLMON[1]=2
go left / cut
go right / in front of part
go left / into the part
go left more / cut some more
go right / in front of part
VLMON[1]=0

i change it to :

VLMON[1]=2
go left / cut
go right / in front of part
VLMON[1]=0
VLMON[1]=2
go left / into the part
go left more / cut some more
go right / in front of part
VLMON[1]=0

because, when tool was out from the part. Z axis effort was so big when direction changed, that machine stopped

this behaviour does not always occur, but when it does, machine stops

in my opinion, is just a local maxim that should be ignored

i would fix it like this :

VLMON[1]=2
go left / cut
go right / in front of part
VLMON_DELAY ( this command should ignore local_maxim/variations for "t" milisenconds )
go left / into the part
go left more / cut some more
go right / in front of part
VLMON[1]=0

kindly !

Similar Threads:

• Need Help!- Okuma Load Monitor Codes
• Simplified load monitor function.
• Problem- Load Monitor on (or not)
• Load Monitor
• Spindle load monitor on Makino MC-100

[deadlykitten]

..

hy, i did not agree at first with your reply from another thread / pls find attach / but after a while it actually ringed a bell / thank you

spikes don't ocure/care about G00 / G01 ... they just exist whenever a movement acceleration changes, like :
....- rapid to feed
....- feed directions

M216 handles 1st line, while code from this thread was in 2nd line

the moment i post it, i did not find it relevant to write all code, but all movements where in G01, and it seems that spike value was greater than cutting value

inside the other thread, from where is the image, spike values were lower than cutting value

i did not use G00 + M216, because there was a drill with 2 inserts, that creates both long + small chips, one type on each insert / flute ... and small chips usually fall of from the flute, when tool is retracted fast/G00, and so they remain inside the hole

so, in this case, i had to break monitoring @ the moment Z feed changed direction, because there was a spike :
VLMON ACTIVE
..cut
..G1 tool out
VLMON INACTIVE
VLMON ACTIVE
..G1 tool back in - starts with spike
..cut continues
..etc

i guess that this means that load_mntrng imune time aplies also at G1/feed start; maybe it not aplies as a controlable parameter ( possible located in Parameters somwhere ), but because of system reaction time ... hmm

[deadlykitten]

in this case :
N1 M216
N2 VLMON ACTIVE
N3 G0 turret comes
N4 G1 cut/drilling Z-100
N5 G0 drill fast to Z3
N6 G0 drill fast to Z-100+0.5
i believe that M216 handles the spikes from N4 start and from N5 start

what about this case :
N1 ( M216 ) ( i guess no more needed )
N2 G0 turret comes
N3 VLMON ACTIVE
N4 G1 cut/drilling Z-100
N5 G1 drill fast to Z3
N6 G1 drill fast to Z-100+0.5
where does the load_mntrg imune time aplies ?

i think only at begining of N4, and not at begining of each movement, so i must use this :
N1 ( M216 ) ( i guess no more needed )
N2 G0 turret comes
N3 VLMON ACTIVE
N4 G1 cut/drilling Z-100
N5 G1 drill fast to Z3
N_ VLMON INACTIVE
N_ VLMON ACTIVE
N6 G1 drill fast to Z-100+0.5
there is also a spike at N5 start, but not as pronounced as the one from N6 start, because N6 line inputs a movement regim change much more pronounced than N5, even they bought, N5 and N6 change Z axis movement sense

so, N5 spike, in some conditions, may not require monitoring process to stop and restart

i met conditiones when N5 actually needed another monitoring process, because tool retract effort was greater than cutting effort, but this is another story ... i just monitored retract movement in another LMadreess, and after a while, because i did not like 2 LMvalues for one cutting process, i used only 1 for bought cutting and retract

kindly !

[deadlykitten]

...

hello mr wizard >:D<

1) the way normal behaviour works, surprised me : under VLMON, G0 effort is ignored ? i thought that only peeks from G0 will be ignored ... so only G1 is monitored ? if VLMON max value will be V_max, and this value is reached under G0, than machine won't stop ? i hope not ... a lot of things can go wrong under G0, well, not as much as under G1, but if G0 is ignored under VLMON, than ...

2) particular cases, slow retraction in front, slow reenter the hole, delays :
....drill with 2 inserts
.............chips fall from the flute inside the hole
.............likely to bend during cuting, so they stop at 5D (far as i know), and hole tolerance increases from 2D to 3D; normal drills are 3 5 7/8D, while this type is 2 3 4 5D, because more length comes with more bending
....tool cuts while retracts
....tool must stay a bit more in front of the part:
.............for the coolant to wash chips
.............for spining rotation ( M axis ) to throw away long chips that are stucked on flutes
....omg, how could i forget this : long 8D tools,

- of course i programed all with 1st sample(G0), and each time i hit into something like this i had to change to G1
- i would really loved to always use default G7/etc cycles, but i can't ... i started to program like this because i hit into particular cases part after part :)

i ask again, please, where does the load_mntr imune time aplies ?
G0 turret X0 Z3
VLMON ACTIVE
G1 cut/drilling Z-100
G1 drill fast to Z3
G1 drill fast to Z-100+0.5 ____________ kindly !

[deadlykitten]

...

hello

That's a bit light in my experience and usually end up around .8.
please, why did you go from 0.4 to 0.8 ?

Do you use "auto set" for your load monitoring values?
you got me here how could you psss, my grandma tolds me

when quantity is big, i write them down, and next time i just input them back ... kindly !

[deadlykitten]

...

hello, i know that automatic +10/20% works fine only with medium tools, that generate medium eforts, while with little / big tools extra caution is needed

i am glad you shared your solution, packed inside that AUTOSET-FIXR, and i wish to present you an alternative one, still under development; pls see attached files

i still work for the automatic toogle mode, between relative and absolute ; i guess relative mode should work inside 15 .. 85 %

i registered with those in a Photoshop contest \o/

however, once interface is redesigned to manage this functionality, maybe you sent it to Okuma + your AUTOSET, and will be included in next OSP update ... if you have a strong contact inside, i think it is possible ...

[deadlykitten]

...

load monitor and more explained in attachement; i hope it covers all your questions

its VLMON[1]=1 when first tool starts, VLMON[1]=0 when ends, VLMON[1]=2 when second tool starts, VLMON[1]=0 when ends and so on for the rest of the tools .. so at 3rd tool start you have VLMON[1]=3 ? pls check this again

Should i manualy change according to the axis the tool works ? inside IGF, right in the windows where you can setup tool, shoud be available for chosing the axis that you wish to monitor ...

Also i dont see VLMON when drilling a hole, I should add one ? ... if you wish/consider, just add one

Another thing..I broke a threading tool a month ago and the machine didn't stop! ... maybe you did not have monitor on that ...also, tool was too little to be sensed by the machine ... machine alwasy monitors efforts and stops at certain values, to avoid crashing/smashing/etc, and this values are greater than required efforts for little tools

could my load monitor values be set very high? I dont know what is high and low..read that stuff to see how to set up limits

kindly !

[deadlykitten]

What's my advantage of using OkumaWiz's AUTOSET FIXR values ?

AUTOSET FIXR is not a stand aloner, but a tuner ... once you'll have no more issues with load monitor, look at post9 for futher explications also file from post9 is filled with coments

Load monitor values are user defined limits to monitor cutting tools at values that are much lower than the machine is capable of producing. 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.

[deadlykitten]

Looks like most of the tools dont have the right monitoring or dont have monitoring at all. I'm gonna fix that as soon as possible!

no need to monitor them all ... only a few; depends .. for example : drills, taps ...

most of them can be heared while cutting .. dimensions start to vary when tools gets unstable .. chip color

if you wish to share your part + tools, we can discuss more precise

I broke a threading tool a month ago and the machine didn't stop! It was my mistake, i set the tool offset X0 and it just wiped half of itself in the part

if you setup the machine and that thing happened on 1st part, right after your setup, than where were you ? always run for each setup as many trials as you wish untill all your doubts are vanished

if your setup was wrong, and you were sure to leave, than ... just stay near that machine until at least 1 part pumps out ... not just stay, but step-by-step your program, put your head on bearings, and inspect active program line on display, than eyes to parts, with your hand on potentiometers ... line was good ? next one ...

move origin in front, so to cut air inspect machine movement ... is it doing what you had in mind ?
simulate programs, not in igf, but on virtual machine .. there is no need that tools and toolholders to be declared in anti-colision, if you know what you are doing

at beginning, testing + 1st part took me a lot of time ... this is how i learned

[deadlykitten]

immune time only occurs when switching from G00 to a feed mode

i really needed to know where this immune time occurs when replacing G0 with G1 ... i used this replacing technique because of multiple cases that i meet, as described at post 7 ... so i runned some tests ( file attached ), and it seems that immnue time occurs also, on Z axis, whenever VLMON[...]=2 is triggered ... perhaps this happens not only for Z, but for all axis ? for S sounds reasonable ... however, my issue was only with Z, so each time a rapid must be replaced, the following code works as it should, AutoSet ignoring raised effort when Z sense is reversed :

VLMON[..]=2
G01 Z-100 ____F.. G95 ( cutting )
G01 Z+3 ______F.. G94 ( tool disengage )
VLMON[..]=0
VLMON[..]=2
G01 Z-100+0.5 F.. G94 ( tool repositioning )

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

[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

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