Re: G-Code Liberries II/How the cadcam-less survive XXLVII: The E-word as a counter

Oh yeah, was wondering what happened to the OP, Douglas Simmonds, from the
first G-code Liberry Q.
I think we--well, mostly Banquer--scared him off, not just the ng, but from
g-code. He mighta concluded, Sheeiit, these muhfugguhs are fuggin *nuts*,
and it may be caused by G-code itself....

Well, we should re-assure him that whatever the state of our minds is, the
cause is not g-code. Metallic dust, mebbe...
Which still don't explain jb...
But in-breeding does.

Doug, I got a nice manual BP you might find useful... :)
--
Mr. P.V.'d
formerly Droll Troll
"Proctologically Violated©®" <physical@xxxxxxxxx> wrote in message
news:spednScE0_wAaV7eRVn-jQ@xxxxxxxxxx
> Awl--
>
> A'ight, here is the latest and the greatest. It took me, this time, but a
> whole evening to crank out a part! wow...
> But the program works.... finally. goodgawd....
>
> To better understand the rationale behind/significance of using the E-word
> as a counter, consider the existing options/constraints in
> drilling/milling a series of holes, slots, etc.
>
> First, if just drilling, the macro issue is fairly moot, because you can
> put *any* sequence of holes in L100, and just call L100 (as L101), within
> and canned cycle, eg G83, etc. See the original G-code Library thread for
> my drilling/tapping ditty that employs this.
>
> If milling, AND the sequence of holes/slots is uniformly spaced, a macro
> becomes useful because unless the milling is a canned pocket routine, you
> don't have the L101 option, as above--you would, without a macro, have to
> explicitly do the milling at each X,Y offset.
> You might be able to put the milling moves themselves in, say, L500, call
> that for each offset, and save a little coding that way, but you would,
> w/o a macro, still have to hump some code at each offset.
> A macro spares you all that (see below)
>
> BUT,
> What if the slot sequence is NOT regular/uniformly spaced?? (still in the
> milling context, not drilling)
> Now, you cain't even use a macro!
> Why?
> Because inherent in the macro loop is a *constant counter* or increment,
> like G91. To wit:
>
> Suppose you want to mill a slot 3/8 x 1" w/ a 3/8 cutter, every 3.0". In
> PV-parlance (ie, avoiding CRC at near-all costs), you would write this:
>
> L100( slot variables)
> #V1=1.0' slot length
> #V2=.375' slot width--not really nec. in this example.
> #v3=.375' cutter diam
> #r4=.25' slot depth
> #v5=(v1-v2)/2' the cutter-comp'd X move--actually, 1/2 of the move.
> #v15=25' maximum allowable X coordinate/distance, ie, can't mill a slot
> past this point.
> #v20=1.5' slot spacing, c-c
> m17
> m30
> ( note the diff between r and v words: only R's can be attached to other
> words--x, y, etc. V-values must be passed to r's before their values can
> be attached to x,y's. pita, but that's fadal-speak.
> So I use V's for raw data and calculations, and pass them to r's later;
> sometimes, as above in #r4=.25, I'll but a value directly to r.
> (
> ( main program
> g0g90g80g49g40g17
> m6T1
> L101
> #v10=0' initializes the counter, altho the #clear command may already do
> this.
> g0x0y0z2.h1e1m3s1500( e1 would be set at the first slot center)
> z1.
> #clear
> #:T1' begins the loop
> #r1=v10-v5' the *new* cutter comp'd x coordinate
> g0x+r1y0( one end of the slot
> g0z.01
> g1z-r4f6.5( mill down at one end of slot
> g1x-r1f5.5( completes the x move to the other end of the slot)
> g0z.1
> #v10=v10+v20' incrementing the counter by v20 (1.5" from above)
> #if v10>v15 then goto :T1' decision line to loop/end loop
> g0z4.m5m9
> (
> m6t2
>
> OK. So this will mill as complicated a slot as you desire (put more moves
> within the loop, as req'd, as if there were no macro), in a very
> programming-economical fashion--*if* the holes are uniformly spaced..
>
> Now, suppose the hole positions are NOT uniform, such as the sequence 2,
> 4.5, 8, 10., 14, 17, 22, along X
>
> There is no way for a macro incrementing a *coordinate word* (ie, X, Y) to
> accommadate non-uniform spacing.
>
> However, you *can* accommodate repetitive milling along non-uniform
> spacings by incrementing the *E word*--turns out that virtually all
> "words" can have variables passed to them, not just x,y,z's.
> .
> First, list each slot center position as an offset in the offset table
> FO 1 2,,,,,
> FO 2 4.5,,,,,
> FO 3 8,,,,,
> etc.
>
> These are your e-words.
>
> Now, rewrite the above macro as follows:
>
> L100( slot variables)
> #V1=1.0' slot length
> #V2=.375' slot width--not really nec. in this example.
> #v3=.375' cutter diam
> #r4=.25' slot depth
> #v15=8' altho we only have 7 holes, the counter must be n+1
> ( also, no need for v20 here, because the loop increment will *always* be
> 1.
> #r1=(v1-v2)/2' cutter-comp'd x move
> m17
> m30
> ( main program
> g0g90g80g49g40g17
> m6T1
> L101
> #r1=(v1-v2)/2' the PV x-move, w/ built-in cutter comp.
> #v10=1' initializes the counter to the first offset.
> g0x0y0z2.h1e1m3s1500( positions us at x0y0 at the first offset, which is
> in fact our first hole
> position
> z1.
> #clear
> #:T1' begins the loop
> g0x+r8y0
> z.01
> g1z-r4f6.5
> x-r1f5.5
> g0z.1
> #r8=v10+1' incrementing the counter for the next e-word
> #if r8>v15 then goto :T1' decision line to loop/end loop
> g0z4.m5m9
> (
> m6t2
>
> Which cycles through each offset (E word), because the increment is
> exactly 1, up to the last desired e,
> Since any type of sequence of coordinates can be specified in the offset
> table, you are now no longer limited to uniform spacings.
> AND, it is quite easy to edit/change spacings.
> <budda bing>
>
> So there you have the difference between to types of incrementing macro
> loops.
> The fadal manual has a number of interesting examples of macros, but none
> showing this technique.
>
> Now, this is *not* the program I have been working on, and just ran--the
> one I was going to use to illustrate the above.
> It was actually easier for me to do this sample ditty from scratch than to
> list my program and then try to coherently annotate it--too much g-d
> g-code can make anyone's eye's glaze over, and often there are so many
> built-in/hidden assumptions, as a result of offsets, fixturing, other
> strategies, that often the raw code is not entirely meaningful anyway.
>
> However, the offset strategies in the program I was going to post, and how
> these strategies are handled via variables, may be of interest to some,
> and if they are, holler, and I will post the program, and explain my
> contortions therein.
>
> What some may find interesting is that the program successfully (I think)
> straddles that peculiar fence between prototype and half-assed production,
> which in my situation is ideal.
>
> The "part" is actually a unit of 4 "tracks" that line a doorway to hold a
> bar. The four section tracks *appear* identical, but in fact each half is
> the mirror image of the other (like a left and right hand), and thus *not
> identical*, from a fixturing POV (the right hand cannot fit into a
> left-hand glove).
>
> Fairly maddening, in fact, to be so similar, but not quite "similar
> enough"--"chiral" or "stereoisomeric" in the chemical parlance, w/
> striking applications/implications in enyzmes, etc.
> Ax me about Chromium Picolinate, one of the biggest frauds ever foisted on
> the health consumer.....
> .
> Combine this w/ the fact that 90 degree faces are drilled/milled, and must
> line up fairly exactly, so more locations must be preserved...
> Combine this with the fact that the pieces are too goddamm long for the
> fadal, and must be shifted (preserving locations once again), and goddamm,
> you are in Offset Hell.
>
> A workable solution was finally achieved by grouping offsets in variables,
> and putting those variables for each grouped operation in subroutines, and
> then selecting subroutines, which then assign G52's all over the place.
>
> Actually now is pretty simple, but it took an *extraordinarily* long time
> to get to this point.
>
> Would be interesting to see how cadcam would impact on fixturing/offset
> strategies.
>
> I may ackshooly get another section done today! :)
>
> A'ight....
> Oh, I didn't run the above ditties, so there may be a typo or mistake or
> two, but the general idea holds.
> --
> Mr. P.V.'d
> formerly Droll Troll
>


.

Relevant Pages