[rdhoggattjr]

Does anyone know of a page or way to view VS* variables without having to store them in a VC* variable?

[OkumaWiz]

There is not a way to display system variables without transferring them to common variables. That being said, some of them have their won display pages such as zero set variables, Zero Shift variables, tool offsets, tool radius etc.. Which system variables are you trying to display and why? We may be able to help you depending on what you are trying to accomplish.

Best regards,

[rdhoggattjr]

The system used common variables Eg VS1 to VS200

[OkumaWiz]

Please clarify.

[rdhoggattjr]

We have HMC mill's with p200 and p300 controls. Some of the variables i use are the common variables that are there for system to use. I guess like system global variables.

OTCHG (START CHANGE TOOLS)
CALL OANTL (FIND TOOL NUMBERS)
IF [PNT NE EMPTY] N10
PNT=0
N10IF [VS200 NE PAT] N50
IF [VS199 EQ PNT] NRTS
N50IF [VS199 EQ 0] N100
IF [VS199 EQ PAT] N100
M64
N100CALL ONGPS PAT=PAT (CHECK NG TOOL PAUSE)
T=PAT M6
N150IF [PNT EQ 0] N200
IF [VTLD3[PNT] GT 10] N200
T=PNT
N200
NRTS RTS

There just like common variables but there used by aftermarket addons so they don't have to use up common (VC) variables to store things.

There nice in some ways because you can't change them from the common variables page. We used to have a guy that would write zero's to the common variables every night because he said he didn't like that they didn't all match.
When he did that the machine would alarm out because my subprograms would lose there data.

[deadlykitten]

hy rdhoggattjr

There just like common variables but there used by aftermarket addons

this code works on osp300L :

    NOEX V1    =      0
$        VS099 = 111111 
$        VS99  = 222222
$        V1    =  VS099 ( v1 will be 222222 )

VS* may be sometimes like common variables, but it is indeed much more :
... VSET : is like an instruction, allowing to declare variables inside sdf
... VCAC* : is like a boolean, returning spindle state : S or C mode
... VS27, VS28, VS29, VS30 : is like a common variables, inside renishaw probing macros

- system variables are linked with the controller; they are initialized by it
- common variables are not linked with the controller; they are not initialized by it, but by the user / programmer

when you use VS* like that, you are entering an area that may be protected, so you have to be sure:
... that the controller is not using those syntaxes, or
... that the controller is using those syntaxes, but the way that you are using them is not interfering with the controller

to avoid such potential dangerous situations, then use common variables, or local variables ( they can no be changed from an input panel )

your program has a few types of variables :
... system variables VTLD3
... local variables PAT , PNT
... off limit ( system or local ) : VS199 , VS200
if possible, use a single type of variable

pls be aware:
... about PAT , PNT : until a while ago, it was not allowed to use local variables that begin with P
... about VS199, VS30 : is not allowed to use local variables that begin with V

that code that you shared, is a lucky hit, or created by someone who knows the interferences

I guess like system global variables

system variables are global

We used to have a guy that would write zero's to the common variables every night because he said he didn't like that they didn't all match.
When he did that the machine would alarm out because my subprograms would lose there data

that seems to be a tool change macro, that uses also tool groups ; why do you need to lock the variables, so to make it work ? why do you can not rely on common variables ?

whatever exception exists, it must be handled by the code, and the code itself should stand-alone, whatever the common variables values are ...

there is an exception case with your code, so you wish to avoid common variables : what is that exception ?

also, somewhere, i believe you lose traking the data, so you need to read the VS* value / kindly

[rdhoggattjr]

hy rdhoggattjr



this code works on osp300L :

    NOEX V1    =      0
$        VS099 = 111111 
$        VS99  = 222222
$        V1    =  VS099 ( v1 will be 222222 )

VS* is like common variables, but also much more :
... VSET : is like an instruction, allowing to declare variables inside sdf
... VCAC* : is like a boolean, returning spindle state : S or C mode
... VS27, VS28, VS29, VS30 : is like a common variables, inside renishaw probing macros

- system variables are linked with the controller; they are initialized by it
- common variables are not linked with the controller; they are not initialized by it, but by the user / programmer

when you use VS* like that, you are entering an area that may be protected, so you have to be sure:
... that the controller is not using those syntaxes, or
... that the controller is using those syntaxes, but the way that you are using them is not interfering with the controller

to avoid such potential dangerous situations, then use common variables, or local variables ( they can no be changed from an input panel )

your program has 2 types of variables : system variables ( VS*, V**** ) and local variables ( PAT , PNT ); if possible, use a single type of variables

pls be aware, about PAT , PNT : until a while ago, it was not allowed to use local variables that begin with P

that code that you shared, is a lucky hit, or created by someone who knows the interferences



system variables are global



that seems to be a tool change macro, that uses also tool groups ; why do you need to lock the variables, so to make it work ? why do you can not rely on common variables ?

whatever exception exists, it must be handled by the code, and the code itself should stand-alone, whatever the common variables values are ...

there is an exception case with your code, so you wish to avoid common variables : what is that exception ?

also, somewhere, you lose traking the data, so you need to read the VS* value / kindly

It is a tool change macro. This macro is about three levels in, but in an older version of my subs I use to store current and next tool numbers in VC variables and they would set them to zero.
That's why I switched to using VS variables for some things.

Before I use any I search through both the Renishaw probing macros and the Okuma probing macros to make sure that there not using them.

[deadlykitten]

if the program will be there for :
... a while, i store actual and next, inside the program
... a short time, i no longer bother with the next tool ( no more prestaging tools )

if you have 10+ tools, you will edit 10 variables ? or 10 actuals + 10 next, and how you manage it inside the program ?

why don't you edit the program ? kindly

[rdhoggattjr]

if the program will be there for :
... a while, i store actual and next, inside the program
... a short time, i no longer bother with the next tool ( no more prestaging tools )

if you have 10+ tools, you will edit 10 variables ? or 10 actuals + 10 next, and how you manage it inside the program ?

why don't you edit the program ? kindly

We use the variables to store characteristics about the tools, like default tool lengths, number of flutes, tip radius, diameters and more. It's all used to run auto tool measurement and tool breakage detection on our pallet system machines. They get updated through txt files at tool changes.

[deadlykitten]

okey, so there is more then a tool change macro

tool length & diameter : good when measuring
radius : for comp codes

please, where/how do you use the "number of flutes" characteristic ? and what other characteristics are you using ? and what type of tool measuring system are you using ?

They get updated through txt files at tool changes.

please, will you share such a file ?


now, back to you : if you send data, in order to auto-measure or detect broken tools, why do you still need to check the vs** variable value ? i mean, is like you are one step ahead, with tool preparation/measure/detect, but you are one step behind with the tool change macro ...


i am sorry, i can not help you : you can not check the system variable value directly ( unless you store it in a file, or record it inside a common variable ), and i also can not sugest you a solution, or an alternative, because i can't locate the problem

i believe that there is something that you can speed up, so to avoid checking the vs**, but i need more details / kindly

[rdhoggattjr]

okey, so there is more then a tool change macro

tool length & diameter : good when measuring
radius : for comp codes

please, where/how do you use the "number of flutes" characteristic ? and what other characteristics are you using ? and what type of tool measuring system are you using ?



please, will you share such a file ?


now, back to you : if you send data, in order to auto-measure or detect broken tools, why do you still need to check the vs** variable value ? i mean, is like you are one step ahead, with tool preparation/measure/detect, but you are one step behind with the tool change macro ...


i am sorry, i can not help you : you can not check the system variable value directly ( unless you store it in a file, or record it inside a common variable ), and i also can not sugest you a solution, or an alternative, because i can't locate the problem

i believe that there is something that you can speed up, so to avoid checking the vs**, but i need more details / kindly

It was just for faster debugging of the macros.

I use number of flutes for measuring face mills and inserted tools that I don't want to spin to find high flutes. I also need flute angle to spindle orientation for tool alignment in the holder. The system is a mixture of Okuma and Renishaw macros depending on how it needs to measure the tool.

[tea hole]

I believe the answer is no.
Under gauging results is the only place i'd expect to find them if anywhere, but i haven't looked in that screen for a while and i don't have a mill handy to check.
That said, there is a note in the gauging manual which states:

*under "common variables for storing gauging cycle results"*

"Note that referencing of the common variables indicated above is not allowed in the usual common
variable reference method. To use the data stored in these common variables, move it to other
common variables that can be referenced.
To reference the end face gauging result in the X-axis direction, move the data to VC1, for example,
by specifying “VC1 = VS29”, then read common variable VC1 in a part program."

So with at least 99% confidence, the answer is no.

That said, depending on the control series, i'm not sure if the VS variables are variables which can be read via the API using an app.
If you can do that, you can read them and post the values to a spreadsheet looking screen to display them, think AutoComp. Though i'm not an app writer or software programmer.

Another stop gap, depending on the control series, is that you can store VS variables to local variables.
Local variables can be displayed on some of the newer series of OSP controls.

Therefore you'd have:
NUM1=VS2
NUM2=VS5

and though you wouldn't be able to display VS2 or VS5 directly and real time, you could view it sort of using local variables.

Hope that answers that for ya.

[deadlykitten]

if you wish to debug the macro, simply write down the values that you wish; try this, it separates the values with tabs, so you can paste the content inside *.xls :

ODD ( data dump ) ( call it from within the tool change macro, or close to it )
    FWRITC data.txt;A
    NOEX PUT VS200 PUT '    ' PUT VS199 PUT '' PUT PAT PUT '' PUT PNT
    WRITE C
    CLOSE C
RTS

i hope it helps

i was a bit confused ... i believed that you wish to use common variables all the time, so to input actual and next tool, from the cnc panel; now, that you only wish to debug, it makes more sense

however, even so, i believe that you could use only common variables, and make the program work, even if someone edits the common variables from the panel : it should work, as long as you initialize the variables from within the program; well, if someone changes them during a tool change sequence, then, you know, bad luck but still, this does not happen often ...

I use number of flutes for measuring face mills and inserted tools that I don't want to spin to find high flutes.

please, can you explain this a bit ? for example, if you have a tool dia80, z6, you will somehow measure the angle between the tool and the toolholder, so to know the orientation angle of the spindle, so to measure it directly at it's highest point ?

I also need flute angle to spindle orientation for tool alignment in the holder.

please, explain a bit more

also, from that file : what is 1337, FL , ROT , TI , BRLI , B , S , R , RD1 , RD2 , RD3 ? kindly

[rdhoggattjr]

please, can you explain this a bit ? for example, if you have a tool dia80, z6, you will somehow measure the angle between the tool and the toolholder, so to know the orientation angle of the spindle, so to measure it directly at it's highest point ?

We have some large tools (8" reamers and 6" facemills) that we don't spin when we measure them because they are that big. So the machine takes the number of flutes and rotation of the body of the face mill to check each flute for the highest one and uses that as the length offset.

also, from that file : what is 1337, FL , ROT , TI , BRLI , B , S , R , RD1 , RD2 , RD3 ? kindly

machine number, number of flutes, rotation of flutes, cut time before auto measurement, amount of tool breakage before tool is considered broke, check for breakage, spin tool during measurement, swap tool on tool life time out, and RD1, RD2 and RD3 are redundant tools that it can swap too.

[deadlykitten]

hy, is it ok for you to use the fwritc, so to debug your soubroutine ? do you need something else ? you could also use :
... local variables, and check a table that displayes them; pls check post 27 : https://www.cnczone.com/forums/okuma...variables.html
... common variables, check their value, and when is all ok, switch back to VS*

Before I use any I search through both the Renishaw probing macros and the Okuma probing macros to make sure that there not using them.

nice job did you looked into the msb files ?

however, when you use a custom name variable, a custom syntax, there are restrictions :
... no function names, no comparison or boolean operators
... no extended addres characters
... no reserved local variable words
... no local variables that begin with O, N or V
* possibly others; if you are intersted, check the list below

if somehow you enter inside a conflict area, you should not worry as long as you know that you don't interfere with the control; for example, i have messed with the oo30 inside the msb, and some VS variables, also inside the msb file, so to ' tune ' a few things

We have some large tools (8" reamers and 6" facemills) that we don't spin when we measure them because they are that big. So the machine takes the number of flutes and rotation of the body of the face mill to check each flute for the highest one and uses that as the length offset.

8" reamer ? is it a bt30 machine ? if i may, is it going inside a blind, or a through hole ? and why don't you use a simpler tool, like an excentric ?

so tools with flutes are aligned, rotary, in respect to spindle orientation ... nice job

i guess you are using a renishaw touch setter, not a fancy laser ...

what about avoiding in machine-measurement ? have you considered that ? you could tranfer offset values inside the machine, and only measure, in order to detect if it's broken; like this, you could avoid the in-machine measuring time ... or you wish to target directly a finishing dimension ? you don't probe, and recut ? only one cut, and that's it ? just asking ...

kindly

1A

1B

2A

2B

AA

AB

ABS

ACOS

AG

AN

AND

ARC

ASIN

AT

AT

ATAN

ATAN2

BA

BC

BCD

BHC

BIN

BOUNS

BR

BT

CALL

CAMCV

CASCME

CASCTL

CB

CC

CD

CF

CHD

CHFC

CHFR

CL

CLEAR

CLOSE

CONEI

CONEO

COPY

COPYE

COS

CP

CQ

CR

CT

DA

DA

DB

DB

DC

DEF

DELETE

DFIX

DFUP

DGRDX

DGRDY

DO

DRAW

DROUND

DS

EMPTY

END

EOR

EQ

FA

FA

FB

FB

FC

FI

FIX

FMILF

FMILR

FOPENA

FOPENB

FUP

FW

FWRITC

GE

GET

GOTO

GRCI

GRCV

GRDX

GRDY

GRER

GROF

GRON

GRSK

GRST

GT

HA

HA

HB

HC

HI

HJ

HK

HORN

HP

HS

HS

IA

IB

IF

KA

KA

KB

KB

KW

LA

LAA

LB

LCONI

LCONO

LD

LE

LK

LMV

LMW

LPRINT

LT

LW

MD

MG

MGS

MITCAN

MN

MOBOR

MOD

MODIN

MODOUT

MODRL

MODSF

MOEND

MOPLD

MOREM

MOTAP

MSG

MT

MTM

MTS

NE

NOT

NP

OF

OG

OR

OS

PA

PCIR

PMIL

PMILR

PREG

PRINT

PRINTF

PRMDI

PRMDO

PRSOL

PTANXT

PTPRET

PTRETT

PUT

PW

PX

PXD

PXE

PXF

PZ

PZD

PZE

PZF

QA

QA

QB

QC

QD

RA

RB

RC

RCIRI

RCIRO

READ

RGEND

RH

RH

RI

RJ

RLDPN

RM

RMILI

RMILO

ROUND

RP

RS

RSQCO

RSQRI

RSQRO

RSTRT

RT

RT

RTI

RTMCR

RTMDI

RTS

RW

SA

SAVE

SB

SB

SC

SC

SCALL

SCALLE

SCALLS

SCALLSE

SCRIPT

SIN

SLOAD

SP

SPHRI

SPHRO

SPRINT

SPRINTF

SQRT

SQRX

SQRY

SS

SYNC

TA

TAN

TANXT

TAPR

TB

TC

TD

TDG

TE

TFA

TFB

TFC

TFP

TFQ

TFR

TG

TG

TH

THEN

TL

TLCO

TLFOFF

TLFON

TLFR

TLOK

TM

TN

TN

TP

TPRET

TR

TRDL

TRDT

TRETT

TS

TSG

TT

TW

UA

UB

WA

WB

WHILE

WP

WRITE

WW

XA

XB

XD

XE

XF

XS

ZA

ZB

ZD

ZE

ZF

[rdhoggattjr]

Thank you for the info
I came across that thread in my search. interesting read. I don't deal in lathes much so it was neat to see some of the diffences between the two.

nice job did you looked into the msb files ?

Yeah

if somehow you enter inside a conflict area, you should not worry as long as you know that you don't interfere with the control; for example, i have messed with the oo30 inside the msb, and some VS variables, also inside the msb file, so to ' tune ' a few things

I have done the same, but I saved the msb macros to another file and changed "OO30" and so on to "OT30" as to not mess with the factory msb's

8" reamer ? is it a bt30 machine ? if i may, is it going inside a blind, or a through hole ? and why don't you use a simpler tool, like an excentric ?

CAT50. Through hole in cast iron. We moved the parts from another machine that was giving fits and didn't want to retool.

so tools with flutes are aligned, rotary, in respect to spindle orientation ... nice job

i guess you are using a renishaw touch setter, not a fancy laser ...

Yes. From what I have heard lasers can mismeasure if there is lint or even coolant on the tool.

what about avoiding in machine-measurement ? have you considered that ? you could tranfer offset values inside the machine, and only measure, in order to detect if it's broken; like this, you could avoid the in-machine measuring time ... or you wish to target directly a finishing dimension ? you don't probe, and recut ? only one cut, and that's it ? just asking …

The machine remeasures at the same time as checking for breakage if the tool has enough cut time on it, otherwise it just checks if it is broke.

[deadlykitten]

I have done the same, but I saved the msb macros to another file and changed "OO30" and so on to "OT30" as to not mess with the factory msb's

please, what is the difference between ot30 and oo30 ? this ot30, did you stored it inside a lib file, or inside a msb file ? kindly

[rdhoggattjr]

please, what is the difference between ot30 and oo30 ? this ot30, did you stored it inside a lib file, or inside a msb file ? kindly

I made it to where the tool can spin at recommended speeds and feeds in the Renishaw manual for our probes. But I later found out there is a way to make it spin with standard Okuma macros. https://www.cnczone.com/forums/okuma...ubprogram.html

Its's in an SSB file.

[deadlykitten]

hy, i am dealing these days with local variables, and i remembered this thread

VS are local variables ( flashed on reset ), array type : for example, VS00001 = 1 and VS1 = 1 will target same variable, while VS[1] won't work; being an array type, means that the variable is created at system power on, by default, thus VS should never be empty

We used to have a guy that would write zero's to the common variables every night because he said he didn't like that they didn't all match.

if you wish, i have some programs for reseting, backing up, etc ... onestly, i have some days when i hate to see a common variable <>0; yeah, i know ...

also, use this to boost your code; more stuff can be done / kindly

OTCHG (remove comments)
CALL OANTL
IF [PNT NE EMPTY] N10
NOEX PNT=0
N10IF [VS200 NE PAT] N50
IF [VS199 EQ PNT] NRTS
N50IF [VS199 EQ 0] N100
IF [VS199 EQ PAT] N100
M64
N100CALL ONGPS PAT=PAT (*1)
T=PAT M6
N150IF [PNT EQ 0] NRTS
IF [VTLD3[PNT] GT 10] NRTS
T=PNT
NRTS RTS

(*1 maybe it does not matter now, but PAT=PAT is not required on lathes, because local
variables, once created, are available on all following/child nesting levels )