osp300L : kitty's tailstock codes

[deadlykitten]

this one sends the tailstock at retreat position; i use it :
... to be sure that the tailstock is at home before machining
... when the tailstock is used to set how much the material comes out from the chuck

CALL OS01 LV01 = retreat_position LV02 = active_line_from_tailstock_table

OS01

    M156
    G195 SP = LV02
    VTSRT [ LV02 ] = LV01
    M55
  ( M157 )

RTS

those M156 and M157 are not necesary to be bought present; depends ...

Similar Threads:

• Need Help!- Okuma OSP5000 Programmable tailstock codes
• Kitty MC2 Yasnac I80M head scratcher!
• Kitty MyCenter 1 Late 80's to 2000 vintage
• Need Help!- G codes and M codes for Mazak Quick Turn T-2
• Hello Kitty Model

[deadlykitten]

this one is more general

CALL OPNL LV01 = ... LV02 = ... LV03 = ...
...... LV01 : 0 for leaving to home, 1 for coming to clamp
...... LV02 : forces a temporary X+limit wherever is the turret
...... LV03 : active_line_from_tailstock_table

examples :
... normal clamp ( turret must be up ) : CALL OPNL LV01 =1 LV02 = 0 LV03 = 1
... fast leave, right after the tool cut and had gone to clearance position ( turret random on X ) : CALL OPNL LV01 =0 LV02 = 1 LV03 = 1
... 2nd (multiple) clamping positions : CALL OPNL LV01 =1 LV02 = 0 LV03 = 2

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1

    IF [ LV05 EQ 0 ] NEND

    IF [ LV02 EQ 0 ] NSKP1
         LV04  = VPVLX
         VPVLX = VAPAX - 0.1
                     NSKP1

  ( M05 )
    M156
    G195 SP=LV03

    IF [ LV01 EQ 1 ] N1
                 GOTO N2

        N1 M56
             GOTO N3

        N2   M55
             M157
             GOTO N3

                  N3

    IF [ LV02 EQ 0 ] NSKP2
         VPVLX = LV04
         LV02  = 0
                     NSKP2

    NEND

RTS

LV05 is a general on/off

...... LV05 = 0 is good when testing operations, if testing can be done without the tailstock; it allows the program to keep the tailstock lines, but it behaves like there is no tailstock
...... LV05 = 1 is for nomal mode

[deadlykitten]

hello again i will explain a bit ; code is something like this :

... if test mode, than skip all
... if desired, force X+ limit at current X
... activate desired line in tailstock table
... if go to work position / clamp is desired, than M56 / else M55
... restore previous X+limit

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1

    IF [ LV05 EQ 0 ] NEND       ( if test mode, than skip all )

    IF [ LV02 EQ 0 ] NSKP1      ( if desired, force X+ limit at current X )
         LV04  = VPVLX
         VPVLX = VAPAX - 0.1
                     NSKP1

    M156
    G195 SP=LV03                ( activate desired line in tailstock table )

    IF [ LV01 EQ 1 ] N1         ( if go to work position / clamp is desired, than M56 / else M55 )
                GOTO N2

        N1 M56
             GOTO N3

        N2   M55
             M157
             GOTO N3

                  N3

    IF [ LV02 EQ 0 ] NSKP2      ( restore previous X+limit )
         VPVLX = LV04
         LV02  = 0
                     NSKP2

    NEND

RTS

CALL variants are described in previous post

[deadlykitten]

the folowing code handles a particular case : M55 comand, tailstock key is wrong position, another M55 comand is issued, for a different home position : the control behaves like how the last M55 was not there, thus tailstock won't move it may lead to a crash; or if you wish, this particular case does not have low chances to appear

blue lines represent new code, that handles this case :


... if test mode, than skip all
... if desired, force X+ limit at current X
... if X <> X_max than warning
... activate desired line in tailstock table
... if go to work position / clamp is desired, than M56 / else M55 + some checks
... restore previous X+limit


all new code is skipped during a restart, because otherwise it won't perform well for example will check a "random" cnc position before restart, and not "in code behaviours / positions"

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1 ( LV05 = 0 > code is not executed; good when testing )
             ( LV05 = 1 > normal execution )

    IF [ LV05 EQ 0 ] NEND

    IF [ LV02  EQ 0 ] NSKP1
         LV04  = VPVLX
         VPVLX = VAPAX - 0.1
                      NSKP1

    IF [ VRSTT NE 0 ] NSKP2                    ( skip this check during a restart )

    IF [ ABS [ VPVLX - VAPAX ] LE 0.2 ] NSKP2  ( if X <> X_max than warning )
         N0 M0 ( turret is not at X_max )
         GOTO N0
                                        NSKP2

    M156
    G195 SP=LV03

    IF [ LV01 EQ 1 ] N1
                GOTO N2

        N1   M56
             GOTO N4

        N2   M55

             IF [ VRSTT NE 0 ] N3                             ( skip this check during a restart )

             IF [ VTSSV EQ [ VSZOW+VBZOW+VTSRT[LV03] ] ] N3   ( some checks )
                   NLOOP M0 ( key in wrong position )
                   GOTO NLOOP

             N3 M157
                GOTO N4

        N4 IF [ LV02 EQ 0 ] NSKP3
                VPVLX = LV04
                LV02  = 0
                            NSKP3

    NEND

RTS

about "if X <> X_max than warning" i hope things are clear

about "some checks", that code verifies if tailstock position after M55 is the desired one, thus it checks if the tailstock moved

i will explain this structure a bit later; i got to go

ps : all this mess can be avoided: please, cam someone check from code if key is in good position ? kindly !

[deadlykitten]

quick note : OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP ) means that OPNL can be called with 3 local variables

what this variables do, is exaplain for each one between "**"

   0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP
       LV01      **             LV02                               ** LV03

a more detailed description for those is in post 2 of this thread

the update of this code, that handles the particular case, does not mess with this variables, or if you wish, it does not change "CALL variants"; it just updates the engine

using Oname ( explanation 1 ** explanation 2 ** explanation 3 ** ... ) helps seeing things faster

[deadlykitten]

about "some checks", that code verifies if tailstock position after M55 is the desired one, thus it checks if the tailstock moved

i will explain this structure a bit later; i got to go

    IF [ VTSSV EQ [ VSZOW+VBZOW+VTSRT[LV03] ] ] N3
          NLOOP M0 ( key in wrong position )
          GOTO NLOOP

variables for W axis :
... VTSSV : absolute position / W position relative to encoder origin / NC Tailstock Position - Machine coordinate
...... read variable; can not be input from interface
... VSZOW : relative origin / W-axis Zero offset- Standard (setup screen) / zero edit screen
...... read / write
... VBZOW : absolute origin / encoder origin / W-axis Machine Zero - Base system (parameter) / sys para 2, base zero offset
...... read / write
... VTSRT[arg] : retract position from line "arg" of tailstock table / NC Tailstock Retract Position
...... read / write

the expresion should be updated with " VZSHW ( relative origin shift / W-axis zero shift ) ", but generally this is 0 thus no shift amount

also, unlike other axis, there are low chances that the " VSZOW " is changed; this low chances are bigger than the chances to edit "VSZOW"

i may update just to be safe, or i may just show a warning if VZSHW<>0

there is another way to check if the tailstock moved :

    IF [ VSIOW EQ VTSRT [ LV03 ] ] N3
          NLOOP M0 ( key in wrong position )
          GOTO NLOOP

... VSIOW : W-axis command target point ( program coordinate system )

it may work or not, but generally speaking, VSIOW is unstable, thus unsafe to use, because it updates automatically with "target value=home" after M55 was executed, even if the tailstock did not reached the "home" position; this update is a bit delayed because of control reaction time

thus the condition "VSIOW EQ VTSRT [ LV03 ]" :
... may be evaluated as true if the VSIOW updated until the read buffer reached that line
... state ( value of truth ) is same as if VSIOW update event occured

i think i should inspect a bit more this VSIO* (* X / Z ) variables, since i am using them a lot when disengaging tools from material; however, maybe not, because i don't think that there is a case where X or Z axis will not move, but the VSIO* will update in advance; from my experience, i can tell that VSIO* may create problems not because of "update in advance", but because of "delayed update", like when combining the VSIO* with radius comp codes, but this is another story

so even if 2nd condition looks simpler, don't fall : is a trap

[deadlykitten]

ps : all this mess can be avoided: please, cam someone check from code if key is in good position ? kindly !

please, i don't have experience with VDIN / VDOUT; could this save the day ? could such a code return the key state ?

[deadlykitten]

IF [ VTSSV EQ [ VSZOW + VBZOW + VTSRT [ LV03 ] ] ] N3

ok, now i will explain how i end up with this :

... link : http://www.cnczone.com/forums/okuma/...able-list.html
... W axis was at 650
... V1 = VTSSV returned 10371.3
... i tried to find the conection between 650 and 10371.3
... my "- variable limit(m) " is 9720.3 ( image 1 & 2 )
... a bit of math will tell 9720.3+650+1=10371.3, thus VNVLW+VSIOW+1=VTSSV
... question : from where that 1 ?
...... it may be from the fact that "- variable limit(p) " = -1 ( image 1 ), or
...... after some digging, i saw that "- variable limit(m) " - "base zero offset"=9720.3-9400.3=320
...... well, "- variable limit(p) " and "base zero offset=VBZOW" are related through the "VSZOW : relative origin", and VSZOW=321
...... 321-320=1 : here was that "1"

thus
VNVLW+VSIOW+[VSZOW-[VNVLW-VBZOW]]=VTSSV >
VNVLW+VSIOW+VSZOW-VNVLW+VBZOW=VTSSV >
VSIOW+VSZOW+VBZOW=VTSSV

VSIOW is not necessary to be reffered as VSIOW, but as a "position among W" axis, like :
... VTSWP [ x ] - work position from line "x"
... VTSAP [ x ] - approach ... ... ...
... VTSRT [ x ] - retract ... ... ...

so now a "position among W" may be checked

[deadlykitten]

so even if 2nd condition looks simpler, don't fall : is a trap

one more thing : " MDI " + " reset " +
... + "V1 = VSIOW" > V1 / VSIOW will not reflect a "position among W";
... + " M156 or M157 " + "V1 = VSIOW" > it will work

so far i have no reason to verify this difference since i don't use VSIOW, from stability issues described in a previous post


... i tried to explain as best as i could
... such things take time, and is good to share what & why , instead of only posting a code
... maybe few have time & patience for messing with this, maybe no one will ever use it, but in the end i must protect my cnc's; it was not ok that moment when i saw that M55 does not perform well :
...... maybe most will check and change the key position, and go on ...
...... maybe some will understand the potential danger

i will update the code for the "VZSHW<>0", and i will share some images to help understanding such procedures kindly !

[deadlykitten]

VZSHW <> 0 would change the condition like [ VTSSV ± VZSHW ] EQ [ VSZOW + VBZOW + VTSRT [ LV03 ]

i may run a few trials, and correct this pretty fast, but :
... VZSHW is volatile : on reset, is lost
... thus if someone just updated VZSHZ, and also wishes to update the VZSHW, he must be carefull and avoid reset
... there are more chances to simply correct :
...... VSZOZ instead of VZSHZ
...... values inside tailstock table, instead of VZSHW
... using VZSH* corections, volatile on reset, means a few parts, not a serie, and the "CALL OPNL LV..." is intended for lots of parts; on few parts is easier to write M55 / M56

thus i won't update the condition, because i don't see a case where a W_origin_shift should be handled by a volatile VZSHW

instead, i will simply put a warning

... if test mode, than skip all
... if desired, force X+ limit at current X
... if VZSHW <> 0 than warning
... if X <> X_max than warning
... activate desired line in tailstock table
... if go to work position / clamp is desired, than M56 / else M55 + some checks
... restore previous X+limit

    IF [ VZSHW EQ 0 ] NSKP1
        NLOP1 M0 ( VZSHW <> 0 )
        GOTO NLOP1
                      NSKP1

i just changed my mind; that condition will slow down the control; i will replace it with :

... ( if VZSHW <> 0 than warning )
... . initialize VZSHW with 0


now this should perform faster this is it :

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1 ( LV05 = 0 > code is not executed; good when testing )
             ( LV05 = 1 > normal execution )

    IF [ LV05 EQ 0 ] NEND

    VZSHW = 0                                  ( initialize VZSHW with 0 )

    IF [ LV02  EQ 0 ] NSKP1
         LV04  = VPVLX
         VPVLX = VAPAX - 0.1
                      NSKP1

    IF [ VRSTT NE 0 ] NSKP2                    ( skip this check during a restart )

    IF [ ABS [ VPVLX - VAPAX ] LE 0.2 ] NSKP2  ( if X <> X_max than warning )
         N0 M0 ( turret is not at X_max )
         GOTO N0
                                        NSKP2

    M156
    G195 SP=LV03

    IF [ LV01 EQ 1 ] N1
                GOTO N2

        N1   M56
             GOTO N4

        N2   M55

             IF [ VRSTT NE 0 ] N3                             ( skip this check during a restart )

             IF [ VTSSV EQ [ VSZOW+VBZOW+VTSRT[LV03] ] ] N3   ( some checks )
                   NLOOP M0 ( key in wrong position )
                   GOTO NLOOP

             N3 M157
                GOTO N4

        N4 IF [ LV02 EQ 0 ] NSKP3
                VPVLX = LV04
                LV02  = 0
                            NSKP3

    NEND

RTS

[deadlykitten]

i only write such procedures once, and after a while a forget all this structure ... who remembers code char by char ? but the idea remains

from outside, is all quiet; this are the lines from a program that goes automatically, in a loop:
... CALL OPNL LV01=0 LV02=0 LV03=1 ( W @ safe before begining )
... CALL OPNL LV01=1 LV02=0 LV03=1 ( W comes after the 3rd operation )
... CALL OPNL LV01=0 LV02=1 LV03=1 ( W @ safe after almost cutting the part; turret does not go X_max )

when the program is finished, i send the tailstock to W_max, because i put the bar inside from the chuck, not from the back of the cnc
... CALL OPNL LV01=0 LV02=0 LV03=3 ( W @ safe position from line 3 )

since starting this thread, this codes had been in production for more than 6 shifts, with parts duration of 155 seconds

i don't share codes without testing them responsibly

[deadlykitten]

i will share some images to help understanding such procedures kindly !

here so to see behaviours ( up left is the " call variant " ); kindly !

ps : green lines in code represent execution line ( control / buffer will read and execute )

ps : green background text on the right side, where coments are, represent that the explanation from that image is not included in previous images; thus check the images in order

ps : i think this is the last post in this thread

[deadlykitten]

i think this is the last post in this thread

no, faith twisted things ... again

tailstock moves as default only if turret is up

when i move the tailstock, without rising the turret, i just declare a temporar X limit at current position

so far so good

... but there are moments when tailstock does not move, even if turret is at upper limit yes, there are ... is not the first time i hit into such a case, and the chapter is " machine working in step by step but not in continuous mode "

this is a lag situation

[deadlykitten]

this is a lag situation

i have update the code to handle this case : looping until confirmation signal is received ( blue color ) :

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1

    IF [ LV05 EQ 0 ] NEND

    VZSHW = 0

    IF [ VRSTT NE 0 ] NSKP1

    IF [ LV02  EQ 0 ] NRPT
         LV04  = VPVLX
         VPVLX = VAPAX - 0.09

    NRPT IF [ ABS [ VPVLX - VAPAX ] GT 0.10 ] NRPT

    NSKP1 M156
          G195 SP=LV03

    IF [ LV01 EQ 1 ] N1
                GOTO N2

        N1 M56
             GOTO N4

        N2   M55

             IF [ VRSTT NE 0 ] N3

             IF [ VTSSV EQ [ VSZOW+VBZOW+VTSRT[LV03] ] ] N3
                   NLOOP M0
                   GOTO NLOOP

             N3 M157
                GOTO N4

        N4 IF [ VRSTT NE 0 ] NSKP2
           IF [ LV02  EQ 0 ] NSKP2
                VPVLX = LV04
                LV02  = 0
                            NSKP2

    NEND

RTS

[deadlykitten]

looping until confirmation

this is the log :

	         0	         0	         1
	         1	         0	        12
	         0	         1	         1
	         1	         0	        13
	         0	         1	         1
	         1	         0	        13
	         0	         1	         1
	         1	         0	        11
	         0	         1	         1
	         1	         0	        13

and it says :
... each time turret was up, 12 .. 13 loops were required until machining could continue
... each time i forced a limit, thus without rising the turret, it was no lag

i disabled the log and continued like nothing happened of course, i use last procedure shared

[deadlykitten]

i think i made a mistake : that behaviour may not be lag, but diff : maybe i check ipw with a tighter tolerance than normal M55/56 does

i have to think of a way to detect what is causing this behaviour all i know is that this does not always happen, but only sometimes ...

[deadlykitten]

hello this is the latest variant

1) i have edit the code written with blue from 3 posts ago, not because it does not work, but because when there is a problem, the infinite loop does not stop the program inside of it, so to see that the loop is the program, but in another place ... i think this behaviour is because of the read_ahead

i replaced the infinite loop with an M0, that is triggered after loop has been issued 25 times

2) procedure stops if low_thrust_travel > 5.55, thus it is saying that i may gain some time by adjusting moving approach position closer to work position

OPNL ( 0 >>> , 1 <<< ** 0 check for X+ limit , 1 don't / force X+limit ** SP )

    LV05 = 1 ( LV05 = 0 > general on/off switch )

    IF [ LV05 EQ 0 ] NEND

    IF [ VTSAP [ LV03 ] - VTSWP [ LV03 ] LE 5 + 0.5 + 0.05 ] NSKP1
         NRPT1 M0 ( "low thrust travel" too long )
               GOTO NRPT1

    NSKP1 VZSHW = 0                 ( you know )
          LV06  = 0                 ( init counter )

    IF [ VRSTT NE 0 ] NSKP2

    IF [ LV02  EQ 0 ] NRPT2
         LV04  = VPVLX              ( force X+ limit )
         VPVLX = VAPAX - 0.09

        NRPT2 LV06 = LV06 + 1
              IF [ LV06 LT 25 ] NSKP3
                   NRPT3 M0 ( turret is not in X+ limit )
                         GOTO NRPT3
              NSKP3 IF [ ABS [ VPVLX - VAPAX ] GT 0.10 ] NRPT2

    NSKP2 M156                      ( center work interlock off    )
          G195 SP=LV03              ( reference table line )

    IF [ LV01 EQ 1 ] N1
                GOTO N2

        N1 ( IF [ VRSTT NE 0 ] NJUMP                                                     )
           ( LV06 = ABS [ VTSSV - VSZOW - VBZOW -VTSWP [ LV03 ] ]                        )
           ( IF [ [ [ LV06 LE VTNOK [ LV03 ] ] OR [ LV06 LE VTPOK [ LV03 ] ] ] EQ 1 ] N4 )
           ( NJUMP                                                                       )
             M56
             GOTO N4

        N2   M55

             IF [ VRSTT NE 0 ] N3

             IF [ VTSSV EQ [ VSZOW+VBZOW+VTSRT[LV03] ] ] N3
                   NRPT4 M0 ( key must be in tailstock position )
                   GOTO NRPT4

             N3 M157                ( center work interlock on )
                GOTO N4

        N4 IF [ VRSTT NE 0 ] NSKP4
           IF [ LV02  EQ 0 ] NSKP4  ( restore previous X+ limit )
                VPVLX = LV04
                LV02  = 0
                             NSKP4

    NEND

RTS

[deadlykitten]

        N1 ( IF [ VRSTT NE 0 ] NJUMP                                                     )
           ( LV06 = ABS [ VTSSV - VSZOW - VBZOW -VTSWP [ LV03 ] ]                        )
           ( IF [ [ [ LV06 LE VTNOK [ LV03 ] ] OR [ LV06 LE VTPOK [ LV03 ] ] ] EQ 1 ] N4 )
           ( NJUMP                                                                       )
             M56
             GOTO N4

hello again this code mentioned in the quoted text i have never explained ...

sometime ago, i was trying to avoid the situation where IL+cycle would restart the program without the tailstock engaged
... and i succeded

however, there had been some side-efects, like tailstock reclamping after it had allready clamped

at that moment i decided that instead of checking if a force restart ( IL + cycle ) is safe, i could simply forget about it, and use normal restart method and VRSTT to skip code portions, but not critical points, so to remain safe and reduce restart duration

such code paragraphs i did not delete, but i keep them between brackets, so to always remember ... kindly !

[deadlykitten]

... one more thing : when i detect Z0 using torque_skip comand, and the program uses a tailstock, i use this code to update tailstock positions :

CALL OINIP LV01=67.764+VSZOZ-100.348 LV02=0.5 LV03=600 LV04=1, where :
... LV04 = table line
... LV03 = retreat position
... LV02 = +/- tolerance
... LV01 = work position
...... work position is shifted automatically : 67.764 is W position for Z100.348

here is the procedure :

OINIP ( work position ** +/- tolerance ** retreat position ** table line )

    VTNOK [ LV04 ] = LV02             ( negative tolerance )
    VTPOK [ LV04 ] = LV02             ( positive  ... ...  )
    VTSWP [ LV04 ] = LV01             ( work     position  )
    VTSAP [ LV04 ] = LV01 + LV02 + 5  ( approach  ... ...  )
    VTSRT [ LV04 ] = LV03             ( retreat   ... ...  )

RTS

as it can be seen :
... procedure initializes approach position, so to gain minimal "low thrust travel"
... procedure overwrites table values, regardless of their initial value
... i could lower LV02 ( +/- tolerance ), from 0.5 to 0.2 or even smaller, but there is no so much time gain

it all begin with Wizards words :

But if you set the new Z origin, it is some difference from the previous #. This amount should be added to your W for the tailstock axis as well and should follow along with Z origin.

Should be accomplished easily by shifting Zero Set numbers automatically. Even a kitten can do it... :-)

... it is a year since than well ... all the best and thank you mr Wizard ...

ps : even a kitten can do it >>> kitty's tailstock codes