Re: [CAD_CAM_EDM_DRO] reflections on g-code

Ray,

Thanks for the comments in this and your past postings. Looks like
there are TONS of parameters to set up full sized machines! I'm still
wading through RS274 and NIST documents, but making progress. Variables
using #'s or V's implemented vary easily, and I started looking at an
old expression evaluator I had. Not so simple. Nearly every character
must be token, and each one passed to the expression evaluator
separately. so (3.00 * 4.50) gets EVERY SINGLE character passed for
eval and pushed on the expression stack. Much more complicated to parse
a block of Gcode! that one I'll have to think about for a while! Would
be fine for a "fill in the blank". I'll see what I can do with named
variables.

Alan KM6VV

Ray wrote:

>
> This list has been busy while I was out terrorizing a few German drivers
> by getting the alfa to 260km/hr or by red-lining the BMW. Autobahn does
> compress apparent distance.--
>
> It has been my impression for quite a while now that the g-code discussion
> was the kind of issue that really has no place to go. Let me explain by
> asking you to think of g-code as a mix of three different things.
>
> At the lowest level, are the codes that set up the way that the control
> should think about subsequent program blocks. These include; kinds of
> moves, plane definition, tool to use and offsets. Some M codes
> fall into this class, turning on coolant, and such.
>
> The second level of g-code are actual position words. x1.2305. y4.30987,
> r2.1039.
>
> The third are all of the "features" that tool builders include to make
> their machine more desirable that machines made by their competitors.
>
> Now, if you are just buying a box or executable that takes g codes and
> runs a machine, it is good to have as many codes and as many subroutines
> and macros as possible. Fancy codes here will allow you to write compact,
> non-redundant programs without having to mess with the box.
>
> >Subject: re:gcode vars and subs -- How about macros
>
> >Greg,
> >Why not do the "math" stuff up above. Let the CAD/CAM, or your special
> >"design" program generate the resultant Gcode. The task needs be kept
> >divided into several levels of abstraction. Start from where ever you
> >want, and it all ends up as Gcode. IMO.
> >Alan KM6VV
>
> IMO Alan is right on here. If you run from a PC using adjustable
> software, you only need the first two classes of codes. Why? Because in
> the PC, you can make a virtual "fancy" g-code engine that spits out
> whatever collection of program blocks you want. A bunch of code can be
> inserted with a single mouse click If you want to:
>
> peck a hole at x2y2
> from z-1
> to z-4
> using a .25 peck,
> and .01 bottom dwell
> and a retract that clears the part on each peck.
>
> Or if you want to thread a rod your virtual engine can develop and crank
> out all of the passes to produce the result that you want. These do not
> need to be built into the interpreter itself.
>
> >The M code you listed is ugly to be sure, but I have to say the "new
> >feature" (msg implemented in EMC is worse. It requires READING at
> >least 4 digits into a comment, as opposed to just stopping when
> >the "(" is encountered, and going to the next line. Since EMC reads
> >the whole line anyway, it SEEMS ok. But these are the 'sneaky' kinds
> >of things that lead to bloatware and poor performance, IMO.
>
> >Ballendo
>
> Here I am more than guilty because I wrote a bit of Tcl/Tk that would run
> a main program and a sub program and refer to each other using comments.
> A better approach is available with what is called conversational
> programming. I've seen systems with real old controls like GE 550's that are
> being drip fed very modern 3d stuff from PC,s
>
> In the Netherlands, I saw a system that uses just the barest minimum of
> the EMC g-code set, runs everything in MDI, (drip-feed) and has enough of
> a buffer between the PC and dedicated motion boards to allow NT to do the
> control work. The gui, written in visual c, includes many features like
> macros, subroutines, and axis position based on variables. And a user has
> access to the full range of c language computation, logical expression
> evaluation, and looping. And the owner/writer of this system has enough
> time left over to be an awesome cook.
>
> No, the author is not your average hacker but if you've spent any time
> with a low level programming language you know that that language will
> work more logically than the best g-code control language out there.
> G-code was invented to move a machine in predictable ways. I don't think
> that we should extend to to accept NURBS or any other of the latest visual
> offerings. We don't need to extend RS274 to do the latest contortions as
> though it was a frantic teen-aged dancer. These need to be handled by
> code writers, post-processors, or whatever.
>
> Several of the EMC folk have been working on two conversational
> programming schemes. The first is based around the g-code routines that
> Jon Elson wrote in c. This approach writes a g-code program file for
> later execution. Bolt circles, pocket milling, grill patterns, simple
> text, and markers for rotary knobs are a few of the routines already
> available. You can get a copy by downloading cpstuff*.tgz from the
> linuxcnc.org/Dropbox. You'll need Tcl/Tk to run it but you can get that
> program language free from Scriptics for nearly every computer and OS in
> existence. Linux users will already have it on their OS.
>
> Matt has been working to transform the cp model into a kind of drip feeder
> for EMC that includes complex routines built from simpler routines and
> uses a tree widget to show the parts of a program. A simple example
> can be constructed by thinking about a bolt circle. 1-a rapid to
> location, 2-drill to depth, 3-dwell, 4-return to clear part. This "macro"
> is repeated for the number of holes needed.
>
> And at the top level this routine can be changed by changing the geometry
> from circle, to ellipse, to rectangle, to line, etc. While at the lower
> levels, the routine can be changed by replacing drill with peck. It can
> also be changed by redefining the relationship between the holes as
> equidistant or some other scheme.
>
> Using his work, you will be able to program with EMC and never look at or
> edit g-code, unless you want to. His next step is simple 2d CAD program
> that is already in there but needs to be integrated.
>
> A further step might be to make the programmer output something other than
> G-code so that it could feed an other box entirely.
>
> >Another note along this line of thinking came up awhile back. EMC has
> >a standalone interpreter with LOTS of error checking. Then the error-
> >checked code is run through the SAME error checks again at run time!
> >I mentioned 'cleaning out' the run-time interpreter, so the speed
> >gained could be used for trajectory planning,etc. RayH thought it
> >seemed a good idea, and asked me to work on it. I told him my plate
> >was already full. Don't know from there what happened/is happening?
>
> >Hope this helps.
> >Ballendo
>
> Nothing is happening here right now. Like trashing fine poetry, we
> have been reluctant to start in on Tom's code. I'm sure that when we get a
> solid conversational product here, we will be running two levels of EMC
> interpreter. The first will include all of the error checking and will
> be used to verify a cp or program. The second stripped down version will
> be used for runtime in those places were we need to interpret more than 100
> blocks per second. (autobahn)
>
> If you want to help contact one of us off list. If you want to comment
> on my thoughts be considerate and snip 'cause this was a long post.--
>
> Ray
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
> Addresses:
> Post message: CAD_CAM_EDM_DRO@egroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
> List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
> Moderator: jmelson@... [Moderator]
> URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
> FAQ: http://www.ktmarketing.com/faq.html
> bill,
> List Manager