Okuma System Variables

New to Okuma. I'm wondering if there is a system variable for the X code command in the last block, and the Y code command in the last block. I've looked through my manuals, but with no luck. Any help would be much appreciated!

hy :) look for vsio* for lathe, or vwka* & vwkb* for mill (* = x or y), but be carefull, because those don't always return the coordinate from the last block, but the comanded target point, which may be a different thing: is harder to read coordinates from a code that works in compensation, or in interpolation, or a cycle, or to detect if last block did actually triggered a motion among a certain axis, etc

please, what do you wish to achive ? g91 can't deliver ? kindly :)

Like kitty meows - not sure what you are trying to accomplish, but VSIOX will capture your target position, so you could always store that to a variable for your use...V1=VSIOX, V2=VSIOZ. If you are looking for the actual position, then you may want VAPAX for actual machine position, but then you may want to use VZOFX and VZSHX in order to get it back to actual position numbers rather than machine coordinates. V1=VAPAX-VZOFX-VZSHX. This is sometimes used after feeding with torque skip and then reading the position after it stops.

Best regards,

I forgot to mention that I am using an Okuma MA600 milling center, with an OSP-P300M controller. The example below is the standard format that is posted out by the post processor, which I do not know how to edit. It is at the beginning of all my programs. Sometimes when I start a new program, the incorrect work offset is active, so when line N1 is read, it doesn't actually position the spindle correctly. I can edit the sub program on line N2, because it is stored in the machine. Since I cannot edit the post processor, I am trying to re-establish the correct work offset from within the sub program, and then have it re-position the spindle in the correct location (the X and Y from N1). That's why I was wondering if there is a variable that stores the last commanded X and Y value, so I can reference line N1 from within the sub program..

(POSITION PROBE)
M05
G94
N1 G00 X4.5 Y-3.1

N2 CALL OPBPL PSO=### PFZ=### PTY=###

hy, so inside opbpl is, let's supose g15 h5, but, when program starts, your machine is in a h<>5 .... to make it work, i supose your program should look like this :

(POSITION PROBE)
G15 H5 ( supossing that g15 h5 is also inside opbpl )
M05
G94
N1 G00 X4.5 Y-3.1

N2 CALL OPBPL PSO=### PFZ=### PTY=###

is it ok so far ? if yes, then why don't you edit manually that code ?


however, when probing, at least 2 wcs should be used, one for initial positioning & probing, then storing results in another wcs

is possible also to use a single one, for both pre & after probing state, but this requires a bit of caution, like :
... always re-initialise the wcs before probing
...... or
... be sure that wcs shift is within a tolerance that won't lead to a crash, like always probing inside a trusted vecinity :) like a circle on a stick : it can move arround, but still being restricted

Out of curiosity, what CAD/CAM system are you using?

The Okuma remembers the last position it was at but if you call out a new Work offset, you will want to re-position with each work offset change. I normally write the cutting positioning code as a sub program. You first call up the tool, set RPM etc., and then call the sub. This way it is very easy to repeat on multiple sides of a tombstone fixture. Sample code:

( ******* OPERATION 5: CONTOUR ******* )
( TOOL 4: .75 ROUGH ENDMILL )
( 3/4 INCH FINISH END MILL )
( CS#1 - XY PLANE )
NT4 ( FINISH MILL BOTTOM BOSS )
N44 G111 T4 Q5
N46 G15 H6
N48 S3929 M3 M300
N50 G90 G95 G17 G0 X-.7387 Y-1.1726
N52 G56 H4
N54 Z.1
G15 H6 X-.7387 Y-1.1726
N56 CALL O2
N58 Z.1
G15 H5 X-.7387 Y-1.1726
N60 CALL O2
N62 Z.1
G15 H4 X-.7387 Y-1.1726
N64 CALL O2
N66 Z.1
G15 H3 X-.7387 Y-1.1726
N68 CALL O2
N70 Z.1
G15 H2 X-.7387 Y-1.1726
N72 CALL O2
N74 Z.1
G15 H1 X-.7387 Y-1.1726
N76 CALL O2
N78 Z.1
N80 M9
N82 G0 Z50.
N84 M1
( ******* OPERATION 10: CONTOUR ******* )
( TOOL 5: .5 COUNTERSINK )
( 1/2 SPOT DRILL 60 DEGREE )
( CS#1 - XY PLANE )
NT5 ( CHAMFER TOP BOSS EDGES )
N86 G111 T5 Q7
N88 G15 H1
N90 S4584 M3 M300
N92 G90 G95 G17 G0 X-.0209 Y.4478
N94 G56 H5
N96 Z.1
G15 H1 X-.0209 Y.4478
N98 CALL O3
N100 Z.1
G15 H2 X-.0209 Y.4478
N102 CALL O3
N104 Z.1
G15 H3 X-.0209 Y.4478
N106 CALL O3
N108 Z.1
G15 H4 X-.0209 Y.4478
N110 CALL O3
N112 Z.1
G15 H5 X-.0209 Y.4478
N114 CALL O3
N116 Z.1
G15 H6 X-.0209 Y.4478
N118 CALL O3
N120 Z.1
N122 M9
N124 G0 Z50.
N126 M1

If you follow this pattern, you can number search to NT4 and then Interlock + cycle start to start with the needed tool #4. All needed work offsets, positioning ,tool call, offset call, RPM etc are called up as needed before jumping to the cutting sub. It also makes program proveout WAY easier since after you've done the first work offset, then only thing to prove out is each work offset location and you are just repeating proven code. It also makes tweaking feeds and speeds easy since you only fix it in one place and it corrects all repeats. Subs are just stored after the M2 so you only load 1 program. Since you use subs, programs are much smaller.

Note this sample code uses a "custom tool change macro" that will eliminate 90% of your tool change faults...see below:

$TOOLCHECK.LIB%
OTCHK
( SET GCODE PARAM. G111 TO OTCHK )
( AT TOOL CHANGE KEY IN G111 T= TOOL NO. Q = NEXT TOOL EX: G111 T1 Q2)
IF [ VTLCN EQ PT ]NST1 (ACTIVE TOOL)
IF [ VTLNN EQ PT ]NRT1 (NEXT TOOL)
IF [ VTLNN EQ 0 ]NOT1 (NEXT TOOL)
M64
NOT1 T=PT
NRT1 M06
NST1
IF [ PQ EQ EMPTY ]NEND (IF READY TOOL EMPTY/JUMP )
IF [ VTLNN EQ PQ ]NEND (IF PREP TOOL IS AT NEXT TOOL POS./JUMP)
IF [ VTLNN EQ 0 ]NTT1 (IF NEXT TOOL HAS NO VALUE)
M64 (NEXT TOOL POT RETURN)
NTT1
T=PQ
M356 (NEXT POT ADVANCE)
NEND G56 H=VTLCN
D=VTLCN
RTS
PQ DEF: WHEN P IS ATTACHED TO A LETTER IT BECOMES READABLE
%



Hope this helps with what you are trying to accomplish.

Best regards,