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

Hello,

I received an interesting offlist email recently from a gentleman who
had "taught" his voice to text software (Dragon Naturally speaking)
to type gcode when spoken to in the manner you describe!

Okay, not quite, but he would say something like "make a line" and
the software would type "G01". He mentioned that by using the "macro"
capability of Dragon Nat speak, he could be more complex in his use;
and get the program to allow alternating spoken/typed input (typing
3.253 may be faster than saying three-point-two-five-three).

But he ALSO said that since getting Dolphin Partmaster, he has not
used his "speak-to-gcode" setup much...

I have also used Dragon, and it intrigues me where this could lead.
But for now at least, someone else will have to pursue it, as I'm
pretty busy.

Hope this helps.

Ballendo

P.S. I've kept the name private as this was a private email exchange.
But he may want to add more, or correct what I have posted.

--- In CAD_CAM_EDM_DRO@y..., "audiomaker2000" <audiomaker@s...> wrote:
> 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