[c63amg]

Hello,

I am looking for a solution to a recently discovered issue with this machine. Here is what happened. With the machine running, the operator made an offset to the tool that was at the time doing the machining. He accidentally SET the tool length offset to -.100mm instead of ADD. The next line of the program the machine crashed. I realize the machines are intentionally like this from factory but for us this Is a huge risk. My question is, is there a way to make it like a fanuc where the machine will not pick up the offset till the next time it is called to do so. Not on the fly like It is right now.

kind regards,

[deadlykitten]

put him to write, and avoid reading more from this reply
following are working on lb3000ex2 ... hope they fit on mb4000

solution 1 )

T010101
rough cicle ( 1 )
T000100
*1 if tool offset changes occur while machine is in this area you may crash something

lets tune up !

V_OFFSET [21]=V_OFFSET [01] ( 1 )
T010121
rough cicle ( 2 )
T000100
*1 in offset tables, at 21 input value from 01; please someone TELL the variables those V_OFFSET is only ilustratative, but not correct
*2 if operator changes something at offset 01, machine will do nothing; however, if he changes offset 21, maybe a crash will occur

so, you must be sure that he will not accidentaly change this 21 ...

as you can see/ as you know, there are 12 tools, with 12*2 main offsets (1.jpg), while in the table are 32 offsets(2.jpg)

if you want to run smooth, and backup each tool offset, in 2.jpg should be (12*2)*2 offset.

so you use for 1st and 2nd offset values from 1 ... 24 (1.jpg), while in the 2.jpg table you have 25 ... 48 to play with, and this 25..48 are not displayed in 1.jpg, so this reduces the chances for the operator to modify them, but he could still enter there ...

so, just finf the good V_OFFSET and work like above

if you work with all 12 tools, on bought offsets, you will have only 32-12*2=8 backup offsets in 2.jpg, so this will work just fine for 32/2=16 offsets, and 16=8*(1st + 2nd offset), or 12main tools + 4x2nd offsets; however, in 1.jpg you may have displayed as 2nd offset numbers from backup table, that will not reflect any tool working, but a backup, and the operators may mess with them because they can see that they are changing withou him doing nothig, and maybe will change them to 0 ....

solution 2)

T010101
CALL OLG01 (OLG02 ... OLG24)
something
T000100

....OLG01 ( consider this inside a *.ssb )

( check VETFX / X active OFFSET )
....V100=VETFX-V100 ( *1 )
....IF [ [ ABS [ V100 ] LE 0.250 ] EQ 0 ] GOTO N0001 (*2)
....CALL ODSP1 or ODSP2 or ODSP3 or ODSP4 ( *3 )
....N0001
....V100=VETFX ( *4 )
( 1 - calculate difference from previous value )
( 2 - compare this difference with some tolerable limits )
( 3 - throw a warning )
( 4 - backup for next time)

( check VETFZ / Z active OFFSET )
....V101=VETFZ-V100
....IF [ [ ABS [ V101 ] LE 0.250 ] EQ 0 ] GOTO N0002
....CALL ODSP1 or ODSP2 or ODSP3 or ODSP4
....N0002
....V101=VETFZ

....RTS


....CALL ODSP1
....(VUACM[1]='sample_MAXlength') (16 chars)
....VUACM[1]='BE CAREFULL'
....VDOUT[991]=999
....RTS

....CALL ODSP2
....MSG(BE CAREFULL)
....RTS

....CALL ODSP3
....M00(BE CAREFULL)
....RTS

....CALL ODSP4
....M0 (BE CAREFULL)
....M0 (BE CAREFULL)
....M0 (BE CAREFULL)
....RTS

solution 3)
- if it's tired send him home
- if it's unsure, put him to write down and verify written values; don't allow him to skip writing; ask his superviser to verify his list of offsets
- big/small crashes occur from time to time ... decide to keep or fire, but think twice before last option, and allow him to learn / allow her to learn
- what about all miss-world operators ? you will put more effort into making them stay

[OkumaWiz]

The machine does NOT immediately pick up the offset. It waits until the offset is called again in the program. Normally poor programming causes this issue since every time they go to a new fixture offset, they also call up the tool again. Verify that the program only calls up the G56 Hxx immediately after the tool change and ONLY then. Much safer for the operator that can make typo's since the reaction time will be much more forgiving.

Deadlykitten is also correct that you can verify offset amounts in the program or even "lock" them to a fixed value. I prefer the first method since locking them to a value makes more work by requiring program changes much more often when length values change.

Best regards,

[tea hole]

Will need to verify on my p300 mill, but I believe it does in fact Real time monitor the offset.
If not the tool, at least the work offset is.

The lathe and mill are so different in so many ways but simplest to explain is that the mill has a Z offset and a radius comp value.
The lathe can have, potentially, an X, Y, Z offset plus a radius comp value and a p value.

Potentially times 2 to 4 because of a second spindle and the wear offset option if I remember correctly.

How does anyone prevent an operator err.

It is possible that I'm incorrect but I feel like I've had this issue with an operator who liked to change offsets while the tool was running. After he destroyed a few fixtures he was "reassigned" if you will. I believe to Taco Bell. Maybe his reassignment was from something different.

As for if there's a parameter to change that, I'll check. I have screenshots of all the parameters and will sort through them while sitting around sipping scotch tomorrow.

[OkumaWiz]

You are correct that fixture offsets are "live" and will take effect on the next block. It is the same on both lathe and mill.

It's ok to change offsets while running since they become effective the next time they are called. Do not change zero set while running because it becomes active on next block.

[deadlykitten]

at mill, 4 example, i take photos of origins table ...and offsets i write down

i only use cameras and keyboards, instead of my hand-writing-skills ... i use them for other purposes

[deadlykitten]

He accidentally SET the tool length offset to -.100mm instead of ADD. The next line of the program the machine crashed. I realize the machines are intentionally like this from factory but for us this Is a huge risk. My question is, is there a way to make it like a fanuc where the machine will not pick up the offset till the next time it is called to do so. Not on the fly like It is right now.

hello c63amg, i have runned this program on mill, and while it was performing, i changed HA value for the " in spindle tool "

 G56 HA
 G15 H1

 G00 X0 Y0 Z0
 S500 M03

 NHERE

     G01 X-100 F15 G95
     G01 X+100

 GOTO NHERE

 M02

Machine did not move among Z; i changed HA again, and still nothing ...
After " reset + restart ", machine moved with the difference between "actual HA" and " HA @ last program start " ... so all changes in between have been ignored

I remembered today your problem, and so i run some tests, because " on the fly " did not sound credible ...

" HA / tool length ", at least on my machine, is read from table only when " G56 HA " appears; interface allows changing table values anytime, while program reads them at certain moments ... so, i guess, there was a " not on the fly " mistake

To avoid this, consider next example : if tool length is not in target 40 ± 0.5, than machine stops ; kindly !

 G56 HA
 G15 H1

 IF [ ABS [ VTOFH [ VTLCN ] - 40 ] LE 0.5 ] GOTO N01
                                            GOTO N02
  N01    ( nothing to worry about )
      GOTO NSKIP

  N02 M0 ( feeling lucky ? than continue ... )
      GOTO NSKIP

  NSKIP ( here or after cycle )

 G00 X0 Y0 Z0
 S500 M03

 NHERE

     G01 X-100 F15 G95
     G01 X+100

 GOTO NHERE

 NSKIP ( here or before cycle )

 M02

[deadlykitten]

The lathe can have, potentially, an X, Y, Z offset plus a radius comp value and a p value. Potentially times 2 to 4 because of a second spindle and the wear offset option if I remember correctly. How does anyone prevent an operator err.

( * ) operator errors prevention on lathe ( * )

turning possible errors:
.... X / Z offset
.... tool wear X / Z ( limited by software to -1 ... +1, so may be skipped if ±1 domain is safe )
.... tool wear X / Z : this can be omited, and all corections to be inserted into offsets value
.... nose-r
.... P ( i don't know how to read this value ... someone, please ? )
............thus : [ X / Z offset ] + [ nose-r X / Z ] > 4 values
.... nose-r can be verified under a general condition : r ≤ 1.2, if reasonable
............thus : [ X / Z offset ] > 2 values

milling possible errors:
.... X / Z / Y offset
.... tool wear X / Z : same story as above
.... nose-r : i don't know how this works on lathe; i don't use it when i program mill operations
........thus : [ X / Z / Y offset ] > 3 values

- like this, there will be only offsets for each tool
- let's verify offsets for a live tool, under M axis :

 T010101
 CALL OCHK V1 = VTOFX [ VETON ]   V2 = - 40   V3 = 0.35
 CALL OCHK V1 = VTOFZ [ VETON ]   V2 =   ?    V3 = 0.35

- let's verify offsets for a groove knife

 T030303

 CALL OCHK V1 = VTOFX [ VETLN    ]   V2 =   ?              V3 = 0.35
 CALL OCHK V1 = VTOFZ [ VETLN    ]   V2 = -12
 CALL OCHK V1 = VTOFZ [ VETLN+20 ]   V2 = -12+insert width

 T030303
  ...
 T030323
  ...

( V1 - value to check        )
( V2 - limit to compare with )
( V3 - admisible deviation   )

 OCHK 

 IF [ ABS [ V1 ] - V2 ] LE V3 ] GOTO N01
                                GOTO N02
  N01    ( nothing to worry about )
      GOTO NSKIP

  N02 M0 ( feeling lucky ? than continue ... )
      GOTO NSKIP

  NSKIP

 RTS

[deadlykitten]

( * ) operator errors prevention on lathe ( * )

this works on mass production ... a simpler way would be to lock " CALL " and " SET ", and allow acces only to " ADD " , but this 3 buttons work as a group : group locked / unlocked

[OkumaWiz]

c63amg are you even here anymore?

[deadlykitten]

this thread is about how to prevent wrong offset corrections; for example, after a tool is measured at the senzor, is very easy to select Z_offset and add -1.5 instead of +0.15

my answers in this thread were from a theoretical perspective

today i just finish a setup on a lathe, where some tools gets close to chuck, at less than 1.5mm; so here is the code, or, if u wish, the practical part, not the theory

in the "intro" part of each operation, after turret reached the safe position, and before the index, i check the offset, by calling a soubroutine

    go @ safe position
    CALL OCHK LV01 = 10 LV02 = 4.294-0.5
    T101010

the soubroutine "oCHECK" is called with 2 parameters ( local variables ) :
... turret post for current operation, thus, if next tool is at post 4, than LV01 = 4
... allowable limit for Z_offset

the soubroutine checks z_tool_correction for the next tool, and if something is wrong, execution is stopped

OCHK

  IF [ VTOFZ [ LV01 ] + VTWOZ [ LV01 ] GE LV02 ] NJUMP

      N1 M0
      GOTO N1  

  NJUMP                © teahole :)

RTS

like this i check all tools that may crash simple & safe

ps : anytime a crash may occure; such codes just reduce chances on some particular cases, but, who knows ?

[deadlykitten]

[ lathe osp300 ] add can not input a "value" bigger than a "limit", that can be set; thus, if "limit=1", than there will be no big corections
[ mill osp300 ] "limit" is not longer "editable" from "tool page", and default is 999, or however big; this may lead to "your case"

is a "team lathe" vs "team mill" issue

[deadlykitten]

changing the correction during a cycle has a low chance to update it instantly, but still there are cases which may lead to a crash : mills during manual intevention do not always come back at some point as before manual intervention, while a lathe is always sharp with this

thus, you may crash a mill by manual intervention , without the "IL+some button" that allows "G15H..." manual translation - i don't know the official terms 4 this action

also, mills on restart are not linear interpolated, thus axis won't reach the point before manual intervention at same time

you can not blame an operator if something like this happens; you may be upset on him, but since this behaviours are not naturall, than it may take time for someone to adapt ... time means 2-3 crashes ? hope they are not hard

[deadlykitten]

latest version for checking operator errors ( osp 300 L )

... CALL LV01 =... LV02 =... LV03 =... LV04 =... LV05 =...
...... LV01 = turret_post
...... LV02 = 1_for_X / 2_for_Z
...... LV03 = minimal admisible value
...... LV04 = value tolerance ( = T; max admisible value = LV03 + T )
...... LV05 = 1_for_primary_offset / 2_for_secondary

examples :
... exterior knife, at post 11 (LV01), primary offset ( LV05 ) :
...... X offset ( LV02 = 1 ) : 72.820, tolerated 72.820±1
...... Z offset ( LV02 = 2 ) : 0.117, tolerated 0.117±1
...... CALL OCHK LV01=11 LV02=1 LV03=72.820-1 LV04=2 LV05=1
...... CALL OCHK LV01=11 LV02=2 LV03=0.117-1 LV04=2 LV05=1

... live drill, in post 5, X generally at -40, tolerated±0.5; Z offset tolerated±3
...... CALL OCHK LV01=5 LV02=1 LV03=-40-0.5 LV04=1 LV05=1
...... CALL OCHK LV01=5 LV02=2 LV03=53.698-3 LV04=6 LV05=1

and so on

procedure steps :
... update offset link if secondary offset is desired
...... on my lathes, 2nd offset = turret_post + 20
... get value to compare; read X corection or Z corection, as desired
...... this may be updated for Y, and R
... check if value is in desired tolerances

OCHK ( post ** value type : X Z ** min ** T = max - min ** 1 offset primar , 2 secundar )

    IF [ LV05 EQ 1 ] NEND1       ( update offset link if secondary offset is desired )
         LV01 = LV01 + 20
        NEND1

    IF [ LV02 EQ 1 ] N1          ( get value to compare; read X corection or Z corection, as desired )
    IF [ LV02 EQ 2 ] N2

        N1 LV02 = VTOFX [ LV01 ] + VTWOX [ LV01 ]
           GOTO NEND2

        N2 LV02 = VTOFZ [ LV01 ] + VTWOZ [ LV01 ]
           GOTO NEND2
    
        NEND2

    IF [ [ [ LV02 GE LV03 ] AND [ LV02 LE LV03+LV04 ] ] EQ 1 ] NEND3       ( check if value is in desired tolerances )

        N3 M0
           GOTO N3

        NEND3

RTS

[deadlykitten]

.

[deadlykitten]

hello again the procedure described a few posts ago avoids operator errors by checking that an input value is inside a domain

input value may be : x,y,z offset, radius, wear, etc ...

procedure works only for x & z offset

in the end, a lot of values may be checked like this; effect :
... more comfort, less stress, and not only for the operator
... clearances may be reduced

i would say that the method delivers "absolute virtual protection":
... " virtual " can not be excluded, since the cnc does not have eyes
... " absolute " because i don't think there is a better method, other than checking a value to be inside a domain, excluding senzors

[deadlykitten]

thus, this method involves a "minimal" and a "maximal" value, to define the "domain"

this post is about reducing load of this method

of course, when there is no load ( method is not used ), also there is no safety

thus reducing load means finding a balance between safety and load

key is to reduce safety to a minimal admisible value, that seems comfortable

there are this variants :
... 1 ) use the "min" & "max" values; thus the operator is assisted as best as possible
... 2 ) use only "min"; thus the operator is still assisted
... 3 ) use fix values; thus the operator is avoided
... 4 ) avoid this method; thus the operator is responsable

i will go through each case:

case 1) code for it has been explained so far in previous posts

case 4) means to not use such procedured

case 2) is based on treating each tool in particular

for example:
... an external knife may be checked only for:
...... X offset to be > a minimal value; if X offset<minimal, it may crash, thus the procedure avoids that; if it will be too big, than it will cut air
...... Z offset to be :
......... > minimal value if it cuts in front of the part ( p3 )
......... included in a domain ( case 1 ) if it cuts towards spindle ( p4 ), so to avoid crasing it into the spindle
... an internal knife:
...... X offset may be checked in a domain ( case 1 );if it's X offset value is too big, insert will crash in part; it it's too low, holder will crash in part
...... Z offset may be checked only to be grater than a minimal value( p2 ); again, if value will be too low, this may lead to a crash, and the procedure will avoid that; if value will be too big, than the tool will cut air

in the attached image :
... checking a value to be within a domain is represented by "mM" ( min MAX ) = case1
... checking a value to be greater than a minimal values is represented by "m" = example of case 2

using only minimal value check for Z may lead to a crash in the tailstock; low chances, but still this is possible, especially when W is not at home, but closer to the spindle this is why in attached image i wrote "mM" for the Z+W=Z+taistock

sugestion for use, as shown in attached image :
... X offset
...... external knifes checked "m"; no problem if they go too high
...... internal knifes checked "mM"; they should be restrained, because of working in a hole
... Z offset, without a tailstock near the spindle, when turret max Z position won't hit the tailstock
...... frontal tools only "m"; all others "mM"

there are the limit cases, when a tool may be considered as well in "m", as in "mM"

case 3 ) for example a bar puller can be locked; thus it's offsets will always be the same pretty good 4 mass production

[deadlykitten]

this post is about reducing load of this method

this is an example of load reducing, for a program with 8 operations; going full checks :

1 mM mM ; 100 100
2 mM mM ; 100 100
3 mM mM ; 100 100
4 mM mM ; 100 100
5 mM mM ; 100 100
6 mM mM ; 100 100
7 mM mM ; 100 100
8 mM mM ; 100 100

reducing some checks :

1 m. mM ; .50 100
2 mM mM ; 100 100
3 mM mM ; 100 100
4 m. mM ; .50 100
5 m. mM ; .50 100
6 m. i. ; .50 ..0
7 m. mM ; .50 100
8 i. i. ; ..0 ..0

... m : offset > minimal value
... mM : maximal value > offset > minimal value
... i : offset is input from code

theoretical load :
... mM : 100%
... m : 50%
... i : 0%

there is a gain of ~35%; real time means 0.1 .. 0.5 seconds probably

[deadlykitten]

"mM" code example : pls check previous posts

"m" code example

OCHK2 ( post ** tip valoare : X Z Y ** min  ** 1 offset primar , 2 secundar )
      ( LV01 **         LV02        ** LV03 **           LV05               )

    IF [ LV05 EQ 1 ] NEND1
         LV01 = LV01 + 20
        NEND1

    IF [ LV02 EQ 1 ] N1
    IF [ LV02 EQ 2 ] N2

        N1 LV02 = VTOFX [ LV01 ] + VTWOX [ LV01 ]
           GOTO NEND2

        N2 LV02 = VTOFZ [ LV01 ] + VTWOZ [ LV01 ]
           GOTO NEND2
    
        NEND2

    IF [ LV02 GE LV03 ] NEND3

        N3 M0
           GOTO N3

        NEND3

RTS

"i" code example ( a bar puller ) :

    VTOFX [ 6 ] = 0
    VTWOX [ 6 ] = 0
    VTOFZ [ 6 ] = 44.5
    VTWOZ [ 6 ] = 0

[deadlykitten]

main idea is not about reducing load, but being safe with a method that is much faster to implement than CAS kindly !