Re: G-code---for the new millenium

Guy, I couln't agree any more.
In today's computer age you should be able to write code like this...

""First, Y axis home but be wary of the Z axis hitting the second
fixture, then start at 34.5X/12.005Y and mill a north/east oriented
inside rectangular pocket of 2.3" on the Y by 4.2" on the X, by half
and inch deep using my favorite cutter. Turn the coolant off, then
GOXOYO and M6. Pause the machine here until I restart the cycle""

Of course, that's a tremendously messy example (intentionally) but
the computer would just return what it didn't get ""please
rephrase "be wary of the Z...etc"".

Point is, there is no reason I can see not to be able to mix and
match G-code with as much conversational programming as possible.
It could even learn what you mean. Results would have to be
simulated before actually running the program of course.

Sean (yes, the example is silly, but doable to some degree of that)

--- In CAD_CAM_EDM_DRO@y..., "Guy Sirois" <guys@w...> wrote:
>
>
> I am thinking (dreaming) out loud here but here goes anyway.
>
> Like most people learning Gcode for the first time, I have some
problems
> remembering the code number for each action.
> As there was recently a thread on "variations" of Gcode (I saw
that in the
> archives) I was wondering if it would be feasible to give to our
> interpreting software, the ability to read text commands and/or
Gcode.
>
> My main area of work is in electronics (not computers) and many
systems are
> now controlled by microcontrollers. Their language is usually very
intuitive
> with commands like
> LSL for Logical Shift Left
> CPI for Compare with Immediate
> SER for Set bits in Register
> CLR for Clear Register
> etc... you get the idea.
>
> I was thinking about implementing alternative text commands to
Gcode that
> would be equally well interpreted by the software receiving it
(machine
> controller). The commands would be 3 or 4 letter words with an
intuitive
> meaning to them. It would not take longer to write the code
manually, but
> would allow a listing that is much more "readable" by humans. It
would also
> allow someone not quite familiar with code to quickly see the tool
path in
> the file.
>
> For example, let's imagine...
> RAP for G00 Rapid positioning
> LIN for G01 Linear interpolation
> ACW for G02 Circular interpolation Clockwise (arcs)
> ACCW for G03 circular interpolation counter-clockwise
> CCCW for G13 Circle counter-clockwise
> XYP for G17 X-Y plane designation
> RADL for G41 cutter radius compensation to the left
> DRL for G83 hole drilling
> ABS for absolute programming mode
> FEED feed rate
> LOOP for loop the program
> DWL for dwell
> RPM for (what else) RPM
> END for end program
> etc...
>
> Shouldn't involve big software changes in the machine controller
programs
> IMHO. If the line doesn't begin with a G## , then check the
comparison table
> to find a matching command and process it as Gcode for the rest of
the
> processing.
>
> Same for the Gcode generators, where there could be an option in
the menu to
> select G-code output or T-code (for Text code) or whatever.
>
> The end result of this could be to render CNC code more attractive
to
> everybody without any drawbacks (that I can see now). The
important thing is
> to make the code intuitive. I do not mean this to be a replacement
to Gcode,
> it is merely an alternative syntax.
>
> Once it has become a feature of the most popular programs we use,
and people
> use it, it can only become more popular with time and, maybe, be
part of the
> new "standard" for modern CNC code.
>
> When Gcode was invented during the fifties, the "computers"
probably
> couldn't deal with text commands, so maybe that's the reason we
are "stuck"
> with the numbers.
>
>
> Oh ! Time to wake-up.
> Was this a bad dream or not ?
>
>
> Guy Sirois