please, help with local variables

[deadlykitten]

hello, there is a program, delivering different result on mill vs lathe .

please, is there a way to make machines behave the same ? kindly !

[lathe]
DIA1=10
DIA2=20


CALL OS02


V3=DIA1
V4=DIA2


M02


OS02


DIA1=100
DIA2=200


V1=DIA1
V2=DIA2


RTS


 ( V1=100 )
 ( V2=200 )
 ( V3=100 )
 ( V4=200 )

[ mill ]
DIA1=10
DIA2=20


CALL OS02


VC3=DIA1
VC4=DIA2


M02


OS02


DIA1=100
DIA2=200


VC1=DIA1
VC2=DIA2


RTS


 ( V1=100 )
 ( V2=200 )
 ( V3=10  )
 ( V4=20  )

Similar Threads:

• Local variables
• Local Variables?
• local variables of a macro
• Local variables
• G65 local variables help

[deadlykitten]

can i use global variables on mill, as on lathe ?

[deadlykitten]

Lathe is V100 mill is VC100

hy, this thread is about local variables, not common variables, like the ones from your post if you wish, please check attached file ...

[deadlykitten]

hy teahole

You can also use: Mill: VC[100] or Lathe: VC[100]

ok ?!

The lathe iteration is the correct result, but you are having read ahead issues

so the lathe is slower on read ahead ? after latest trials, i can say that "lathe team" is delivering better stuff than "mill team"

Run the mill in single block, check your result. I'd wager it'd match the lathe

i will compare read ahead on bought cnc's, and also i will run the mill in single-block; if you are right, than i will .....

TIME=VDIN[1001]

you really have some stile with variables what does this one ? kindly !

[deadlykitten]

Mill: VC[100] or Lathe: VC[100]

hy, VC[...] works on bought; also, i scanned my lathe documents, and there is no information about this; only a reference about "VC1" from where do you have all this tricks ? well, this one is not so huge, but still ....

The lathe iteration is the correct result

maybe the mill is the correct result ? i run the mill like this :
... single block
... buffer off
... TIME=VDIN[1001], but nothing changed ...

on "single block", i had to press green button only 2..3 times to run the program, and thus, machine did not stop at each line; i think it is looking for a G code, and if there is nothing, than it jumps over more than 1 line

however, thx for your suggestions

[deadlykitten]

hy teahole glad to see you ... please, i did not get it :

It will not stop on every line in single block with nothing but variables and as a result the program will keep reading them until it finds something else >so by using "TIME=VDIN[1001]", than when running in single block machine will stop only on lines with variables ? and if this is true, than what is the purpose for this ?

TIME is setting a local variable to be named "TIME", and you're setting the value to VDIN[24] > i am lost ... so lost : so a local variable may be initialized with VDIN[1001], and that local variable may be called TIME or LV01 ? and what happens next with the local variable ? this variable stores a value = VDIN[1001], but why does it store it, and for how long ?

Id wager the addition of a G code would be correct > why would i add a G code ? when i input "TIME=VDIN[1001]", machine was jumping more than a "single line" in "single block", and i just supposed that it was looking for some G codes

However, as another solution, to prove the lathe is correct or the mill is, add an M331 to the lathe before and after the CALL statement. Then, add, and I forget the exact number needed, so we'll guess high, 20 lines that read: G4F.01 before and after the call statement. I think if you were to add the VDIN[1001] with a single G4 it may do the same > so using "TIME=VDIN[1001]" has the same effect like :

M331
CALL Oxyz
M331
G04 F 0.01 ( ~20 times ? )

and the "effect" is ? you mean to delay the buffer ? to avoid the "read ahead" ? i remember you said this before here : http://www.cnczone.com/forums/okuma/...tructures.html

i have allready disabled the "buffer reading" from machine parameters, and nothing changed ... thus, why would i try other techniques to disable "buffer / read ahead" ?

[deadlykitten]

As for "lathe team" vs "mill team", i disagree entirely. Frankly ... So I may not want it to read ahead so far, so fast.

i agree with you / when i said something about "lathe team" and "mill team" i was not reffering only to the situation described in this thread ( sorry for the confusion )

in recent threads had been discussed some differences, more or less important, but is obvious that this differences exist and "lathe guys" should talk more with "mill girls"

a major difference, for example. that i wrote in last post here : http://www.cnczone.com/forums/okuma/...tor-stuff.html, is that mill reaction time on "load monitor" is slow compared to lathe

i think it would be a good idea to open a thread only for differences between these teams

[deadlykitten]

First, scanning your documents will not yield you what you're looking for

i totally agree : this is way i don't read manuals when i search something, i select "inside files search" and choose all lathe or mill manuals, so i can scan pretty fast through all documentation with 1 click

Most of my tidbits came from deep reading into manuals, old and new. It's amazing how much stuff existed on the old controls that never got used because nobody knew how/why you would and are detailed in older manuals, but not in newer ones. Usually i'm searching for a solution to some problem i'm having, and read about something and think: "that may be damn useful someday. I'll write it down"

you know, one of us should RTFM yeah, i know, i know ...

Then i write it down, what it does and keep an active running list.

i have 3 main lists :
... one with issues about parts that i must craft
... one with Okuma cnc's issues
... one with issues about a more organized shop

i need a programmer to handle 1st and 2nd lists, so i would focus on 3rd

That's where i discovered ... how to reset mill common variables to "empty"..

i have never reset a variable in this way; at this moment i don't even know why i would do so ...

Can I get a hell yeah yee haw for same t call as current is made alarm D?

i don't know what a D alarm does, but i can say that i handle this case with my tool change procedure : http://www.cnczone.com/forums/okuma/316654-forum.html

ps : if you listen, you will hear me cheering for this / if you''ll keep it this way, you will get ( soon ) another Nobel prize



.

[deadlykitten]

the purpose of the VDIN[####] is to force the control to wait to read ahead in a way that it is calculating variables and numbers ahead of time

so in this way, when a line with a formula/variables is reached, than it will be executed faster, because it had been calculated before ? far as i know, this is default behaviour on cnc's, because the read ahead buffer does it on it's own / so what extra-functionality does the VDIN ? is it somehow increasing/enhancing the read-ahead ?

A local variable is initialized as you say as soon as you define it within a given program. So once TIME exists, I can check it's value. I can also check it's existence.

ok, i understood your examples / also, at this point, i have no idea where or why i would use such examples

Let me see if I can get a mill for a minute to create a demonstration of what i'm trying to explain here

if you wish you may use an obelisk to travel near my location ( is a mill here ), but 1st you must achieve "okuma programmer rank = the traveller" ; such ranks are officialy released, but if you will trick this bureaucracy, than you may get disintegrated after entering the obelisk far as i know it doesn't hurt, but ...

I'm just trying to express the lathe is correct, and the mill is wrong based on the results you're reading and explain why

also i believe that the lathe is correct ; maybe there is a parameter / bit / something simple on the mill, but i don't know how to acces it

however, all this started when i wished to export the result from a "soubroutine" to a "main program" ; this is what i have done so far :
... i give up using local variables, so i used a common variable instead, or
... i used a 4th kind variable; there are "common", "local" and "system variables" explained inside manuals ; and also 4th kind's, that i found inside msb files this are "local variables" that do not respect the syntax that is recomended to be used, thus they begin with "V", and normally it is not allowed to use local variables that begin with "V" ; like this i can export the result from a soubrutine that is written in a file, to a program that is written in another file so, this variable acts "global" not only inside a file, but also between files, just like a "common variable" ... i discovered this when tuning my renishaw

such a thing requires caution, because the 4th kind variable was designed for a "purpose" ; so, when is used inside a program, than it must be done in such a manner that the "purpose" won't get affected / i know when the "purpose" occurs

[deadlykitten]

LV = 100
CALL OSUB
VC1 = LV
M02

 ( . . . . . . . . . . . )

OSUB
    LV = LV + 1
RTS

when a local variable(=lv) is created before the CALL OSUB, and is edited inside the OSUB :
... lathes pass the "new value" to the lv, thus VC1 will be 101
... mills do not, thus VC1 will be 100

question is which case is correct ? if you ask me, i would say the lathe, but there is no example inside the manuals to sustain mill or lathe behaviour. lv's are presented differently in mill and lathe manual.

all examples from manuals are like a "lv" may be passes from the main to the sub, and again to other sub, but there is nothing about "coming back"

by "coming back" i mean to perform some calculations inside a soubrutine, and after to pass the final result back to main program

since i can not do it by using a local variable, i used instead other variable type, as shown in previous post, but still, this behaviour of local variables makes things safer for a "single way" usage, so only when passing arguments/values futher, to another soubrutine; there is no feedback ...

[deadlykitten]

hello, is it possible to visualize what local variables are registered, and with what values ?

something like a "local variables list" ? kindly !

[deadlykitten]

hello this days, while i was searching for something, i saw a table with local variables, like a printscreen from the cnc monitor ... i can not find that page again, and i wonder what was it about

[deadlykitten]

You can also use:
Mill: VC[100]
or
Lathe: VC[100]

hy teahole i had some simple counting variables V1=V1+1, and V2=V2+2, and i just remembered your post, so i finally wrote it like this :

OPP

 VC [ LV04 ] = VC [ LV04 ] + 1

RTS

so i increment those by CALL OPP LV04 =argument

Makes it easier to use lathe and mill macros across the 2 controls. Been around for a long time. Nobody uses it.

please, what type of macros / procedures do you use ? particular for a cnc or across ?

i mean, if u have time, please ? i will create a thread about this; thank you

[deadlykitten]

hy teahole ! i just received some pretios infos, it seems that VDIN[1001] returns the duration in seconds since the cnc was turned on

... like there is a tick-tock timer which starts when machine starts

of course, like you said, there may be other things related to VDIN[1001]; kindly !

[deadlykitten]

Let me see if I can get a mill for a minute to create a demonstration of what i'm trying to explain here.

There's a difference between reading a program and executing a program. NC operation doesn't count a complete part until you run a part WITHOUT machine lock on, for example.
I'm not sure how to explain this without a machine to do it on, if I can think of a way to do it.

hi i know that i am not in the position to rush you, but please, maybe you will share some better examples

i am still curios about what you mean ... kindly !

[deadlykitten]

hello, please, how to check if a local variable is "EMPTY" ?

for example, if a soubroutine requires a parameter, and if that parameter is not specified at the CALL statement, how to check if the parameter is missing ( inside the soubroutine ) ?


the soubroutine from the shared code should perform well at block N1, and raise an error at block N2, because there is no LV01 at N2

... but in reality i receive an error the 1st time i call the soubroutine, at the line inside the soubroutine : "IF [ LV01 NE EMPTY ] NJUMP"

lathe :
... images 1, 2
... seems like the controller considers EMPTY as a local variable, and gives an error because it has more than 4 chars

mill :
... images 3, 4
... controller sais that the local variable used is not registered; i guess it is refering to EMPTY as being a not-registered local variable

please, how to handle this case ? kindly

    N1 CALL OS01 LV01 = 1
    N2 CALL OS01


    M02


OS01


    IF [ LV01 NE EMPTY ] NJUMP
         NLOOP M0 ( missing parameter )
         GOTO NLOOP
    NJUMP LV01 = LV01 + 1


RTS

[deadlykitten]

giiiiiiiiz, thx teahole !! it works ... nice, thank you !!!


pls, i have some extra-questions :


... " IF TIME " checks if the variable "exists"; i need to check if the variable does "not exist", so to shorten the code something like " IF [ TIME EQ EMPTY ]" or like " IF NOT TIME "; unfortunately, those syntaxes do not work


... broby uses " IF [ PD EQ EMPTY ] NALM2 " inside a helix macro
... mr wizard said that adding P to a letter makes it readable; makes it readable where ?

    CALL OSUB PD = 12
    M02

OSUB

    V1 = D     ( does not work / error, etc )
    V1 = PD    ( works )

RTS

what exactly is behind these P* variables ? they are not local ... are they reseved only for macros ? also can be used P** / P*** / P**** like PA / PAB / PABC ?


i know that there are some "extended adress chars" that should not be used : " PA PW PX PXD PXE PXF PZ PZD PZE PZF "
what happens if someone uses one of them ? kindly

[deadlykitten]

please, how to destroy a local variable ?

    NA1 LV01 = 55
    NA2 CALL OSUB
    NA3 V1   = LV01
    M02

OSUB

    NB1 LV01 = LV01 + 1 ( LV01 will be 56 )
    NB2 LV01 = EMPTY / nill / kaput , vanish in space ...
    NB3 V1   = LV01

RTS

i wish to destroy the variable at block NB2, so at NB3 ( and at NA3 perhaps ) to have an error / kindly

[deadlykitten]

hello this days, while i was searching for something, i saw a table with local variables, like a printscreen from the cnc monitor ... i can not find that page again, and i wonder what was it about

You probably saw the list for "Reserved Local Variables" in the appendix section of the programming manual ( last section most likely )

hey ( mr ) superman ( sir marvel ), what's up ? i found it :

lathe :
... #20.5, or para\easy op\local variable display ( image 1 )
... a local variable table, with names and values will appear ( image 2 )
... there isn't a lot of infos inside lathe manuals about this

mill :
... there is some infos about this inside the operation manual ( image 3 ) wtf was i doing 2 years ago at that random page ?
... to activate it, press pg_up/down in the area shown in image 4

this option helps debugging subroutines; fog is gone / kindly

[deadlykitten]

hello all, about the local variable table, shared in previous post, i don't use it ...

when i discovered it, i thought that it is really interesting, but now, actually is slow, for me, when it comes to debugging subroutines

using that table requires to run the subroutine in step-by-step, and inspecting each value as the execution evolves

i use "write" function to create a file with local variables, and all "write" functions are inside a conditional code, thus i can toggle them to be used or not; if i don't need to inspect the values, i turn it off, so to avoid cycle downtime

inside that file i can see all the values at once; sometimes i open several such files, and i simply alt+tab between them, so to visualy locate fast the values that changed ( if you wish, check attached )

this helps to create a larger view, when developing subroutines that are too complex too follow

well, just saying / kindly