re:RE:Re: gcode subs and vars
Posted by
ballendo@y...
on 2001-01-07 01:04:29 UTC
Smoke,
(snips,inserts below)
switches and press 'step'.
thread, I was comparing the 'embedded' subroutine (as shown by
Mariano) with the example (from a Fanuc style control) I listed.
Wherein the Sub is just another Gcode program (sometimes with a
special ending character). The difference is WHERE the "go-to" goes
to...
<snip>the "go-to" command tells the main program to look for the sub-
line number might be used. But this example points towards the
difference. A subroutine (as used by mariano) will be 'contained' in
the main program SOMEWHERE. A subPROGRAM will be separate, and called
from another PROGRAM. So instead of moving to some line number or
label in the current program, it will go 'out' to the control memory,
or disk drive and find the needed program.
It's kind of like this: One guy has a jar with washers, nuts and
bolts in it(the jar is a program, and the washers, nuts and bolts are
subroutines). Another guy has 4 jars, one with nuts, one with bolts,
and the third with washers. The last jar has a list of bolt assys.
needed. (All the jars are programs. The one with the list is
the 'starting, or main program. When you need a nut, you 'call' the
nut program to get it. Same for bolts and washers.)
In the 2nd example, You don't have to 'pick through' the one jar
every time you need a specific thing. And if you need a new size
nut,bolt, or washer, you just start another jar! After awhile, you
find it is very easy to 'write' and 'maintain' these jars (programs).
And you can take a jar out(or put it in) very easily. Much easier
than searching through the 'mixed up' jar(s)...
line. Or will 'quietly' pre-process the file looking for such things.
Subprograms just need to be available to the control (in memory or on
disk). What we're talking here is 'structured' programming. Which is
a new term for an old idea; organisation. Keep the screw, nuts, and
washers separate, and go get what you need, when you need it. Whereas
the older style of programming kept all the parts in the same jar.
Hope this helps.
Ballendo
P.S. I hope this is making this clearer. We have to remember that
nearly any two things can be looked at in such a way that they
simplify into sameness. Think of Turing, and his proposition for
computers...
(snips,inserts below)
>This was before PC's were even invented. Programming with 1's & 0'sYep, I've done the 1's & 0's thing too. IMSAI 8080 (flip the hex
>is truly a bitch. Programming with the command set was decidedly
>easier.
switches and press 'step'.
>I don't know how you and other programmers define "sub-routine" andYou are exactly right. However, in the CONTEXT of the message and
>sub-program" these days but, if you stop and THINK about it a sub-
>routine and a sub-program are the same thing with different names.
>Using either one of them means you have a "go to" command buried
>somewhere in your main program.
thread, I was comparing the 'embedded' subroutine (as shown by
Mariano) with the example (from a Fanuc style control) I listed.
Wherein the Sub is just another Gcode program (sometimes with a
special ending character). The difference is WHERE the "go-to" goes
to...
<snip>the "go-to" command tells the main program to look for the sub-
>routine (sub-program) at line number xxxxx. Now this line numberAgain correct. Nowadays a 'label'(a named line number), rather than a
>could be line 20, line 200, line 2000 or any where else.
line number might be used. But this example points towards the
difference. A subroutine (as used by mariano) will be 'contained' in
the main program SOMEWHERE. A subPROGRAM will be separate, and called
from another PROGRAM. So instead of moving to some line number or
label in the current program, it will go 'out' to the control memory,
or disk drive and find the needed program.
It's kind of like this: One guy has a jar with washers, nuts and
bolts in it(the jar is a program, and the washers, nuts and bolts are
subroutines). Another guy has 4 jars, one with nuts, one with bolts,
and the third with washers. The last jar has a list of bolt assys.
needed. (All the jars are programs. The one with the list is
the 'starting, or main program. When you need a nut, you 'call' the
nut program to get it. Same for bolts and washers.)
In the 2nd example, You don't have to 'pick through' the one jar
every time you need a specific thing. And if you need a new size
nut,bolt, or washer, you just start another jar! After awhile, you
find it is very easy to 'write' and 'maintain' these jars (programs).
And you can take a jar out(or put it in) very easily. Much easier
than searching through the 'mixed up' jar(s)...
>I was merely pointing out that having all the little sub-routines inYes. Some interpreters will REQUIRE the subroutines to be first in
>the same location (someone mentioned having them at the begining of
>the program...but they could all be just as easily be somewhere in
>the middle or at the end) was logical. It makes it very easy to
>find the one you want should changes (or removal and replacement as
>you mentioned) become necessary. I would prefer them at the
>beginning, since most programs do start at the begining upon opening.
>"SPOCKIAN"! Smoke
line. Or will 'quietly' pre-process the file looking for such things.
Subprograms just need to be available to the control (in memory or on
disk). What we're talking here is 'structured' programming. Which is
a new term for an old idea; organisation. Keep the screw, nuts, and
washers separate, and go get what you need, when you need it. Whereas
the older style of programming kept all the parts in the same jar.
Hope this helps.
Ballendo
P.S. I hope this is making this clearer. We have to remember that
nearly any two things can be looked at in such a way that they
simplify into sameness. Think of Turing, and his proposition for
computers...