Hi everyone,
I have followed the discussion so far with interest. I personally view
gcodes as a very low level language. I guess the addition of owords goes
some way towards improving things. My ideal would be an object based
language for describing the geometry etc of path generation. But my
Hi Alan,
that is an interesting idea.
from the interpreter perspective there's in principle no issue why some other
language couldnt emit canon calls just alike; possible (with a lot of work)
note that other parts of linuxcnc have some assumptions about the language, for
instance the UI's -
On 01.02.12 20:32, Kenneth Lerman wrote:
On 01/31/2012 11:14 PM, Erik Christiansen wrote:
Any need to know the run-time state of a modality before run-time is
illusory. That which needs to be known at run-time needs to be known at
run time, not before. It is worth understanding that the
On 01.02.12 08:42, dave wrote:
On Wed, 1 Feb 2012 19:34:09 +1100
Erik Christiansen dva...@internode.on.net wrote:
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line
as a precursor to restart
On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
On 01.02.12 20:32, Kenneth Lerman wrote:
3 -- A semantic analyzer (whether rule based or coded) will be necessary.
Do you want to prove some property of the gcode program, such as whether
it will ever reach the end?
I've only
On Thu, Feb 2, 2012, at 09:11 AM, John Kasunich wrote:
If you are going to invent a black box (parser, whatever) that
takes in some new dialog and spits out g-code, without doing
I meant dialect, not dialog, sorry
all the checks that the interpreter eventually will do, please
think about
On 02.02.12 09:11, John Kasunich wrote:
On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
On 01.02.12 20:32, Kenneth Lerman wrote:
3 -- A semantic analyzer (whether rule based or coded) will be necessary.
Do you want to prove some property of the gcode program, such as whether
On 03.02.12 12:49, Erik Christiansen wrote:
What I did in July does already check for some run-time conflicts which
I found in the doco, e.g. Turning on radius compensation in an illegal
plane:
The snippet can pick up the conflict in a simple fall-through gcode
program, but not if the axes are
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line as a
precursor to restart from line no?
IIUC¹, running an interpreter through the code from line 1 to a given
line, with all external actions
Another interesting related trawling find, with a some ideas for syntax
evolution:
A G code precompiler which parses a language based on C control structures, and
generates rs274ngc gcode for LinuxCNC (including O-word constructs etc). It's
by a fellow named Lawrence Yu, and its based on
I have been working for sometime on a subset of RS274ngc parser. I have a
program on my Mac which reads a dxf file and converts it to RS274ngc and allows
you to invoke some wizards along with it. The purpose of my parser is to
re-read the RS274ngc files I create an allow them to be edited and
On Wed, 1 Feb 2012 19:34:09 +1100
Erik Christiansen dva...@internode.on.net wrote:
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line
as a precursor to restart from line no?
IIUC¹, running an
On 01/31/2012 11:14 PM, Erik Christiansen wrote:
On 30.01.12 07:54, Kenneth Lerman wrote:
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
What is being missed here is that the present parser does all that you
fear above, just without the maintainability and documentation benefits
conferred
On 02/01/2012 03:34 AM, Erik Christiansen wrote:
On 31.01.12 21:45, dave wrote:
To my uncluttered mind ... read blank ...
is this a good way to set the state of a machine at any given line as a
precursor to restart from line no?
IIUC¹, running an interpreter through the code from line 1 to a
On 1/31/2012 1:48 AM, Erik Christiansen wrote:
3) tools that allow one to treat the grammar as an engineering object,
e.g., view it, analyze it, manipulate it (refactor, group, etc), and
extend it. This area was an arid desert the last time I did any related
technical work.
Well, BNF
On 30.01.12 07:54, Kenneth Lerman wrote:
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
What is being missed here is that the present parser does all that you
fear above, just without the maintainability and documentation benefits
conferred by a higher level implementation, using powerful
On Wed, 1 Feb 2012 15:14:39 +1100
Erik Christiansen dva...@internode.on.net wrote:
On 30.01.12 07:54, Kenneth Lerman wrote:
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
What is being missed here is that the present parser does all
that you fear above, just without the maintainability
On 01/30/2012 01:14 AM, Erik Christiansen wrote:
snippage
1) Be mnemonic. i.e. give some farnarckling clue as to what the command
does. (Even MOV is orders of magnitude superior to 0x01 or g01.)
Erik, is this what you meant by farnarkling:
http://mirror.uncyc.org/wiki/Farnarkling ;-)
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
On 29.01.12 23:05, Kenneth Lerman wrote:
Are you suggesting that a three axis machine where there is
no A axis should have a different grammar than a four axis machine that
does have an A axis.
No, there is no such constraint in the current
On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
On 01/30/2012 12:28 AM, Erik Christiansen wrote:
On 29.01.12 23:05, Kenneth Lerman wrote:
...
...
It is worth understanding that the current parser _does_ have a fixed
grammar, just like the proposed alternative. The significant difference
is that
On 30.01.12 12:37, Kent A. Reed wrote:
On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
I would hope for
1) a formal description of the grammar we already have. As Erik points
out, the LinuxCNC interpreter implicitly defines a grammar. It's just
hard to tell what the grammar is. It's hard to
Am 29.01.2012 um 06:37 schrieb Erik Christiansen:
- wouldnt it be more readable to write:
--
$var1 = $foo + 1
$var2 = 10
if $var1 $var 2
...
else
...
endif
--
Indeedy, but even the '$' is unnecessary.
I'm not sure whether
On 29.01.12 09:31, Michael Haberler wrote:
Am 29.01.2012 um 06:37 schrieb Erik Christiansen:
--
$var1 = $foo + 1
$var2 = 10
if $var1 $var 2
...
else
...
endif
--
Indeedy, but even the '$' is unnecessary.
I'm not sure
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you would handle
foo = 10
oo = 1
g1fooZ100
Is it not
On 1/29/2012 12:37 AM, Erik Christiansen wrote:
On 25.01.12 21:22, Michael Haberler wrote:
[this should move to emc-developers, which is why I'm cc'ing there]
It would be a pity if the rest of us were to be excluded. It is a very
interesting discussion, and the EMC issue was secretive enough.
On 29.01.12 12:59, andy pugh wrote:
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you would
On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote:
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords,
No, that is creating a second named parameter in order to be more
ambiguous later:
g1fooZ100
Is there an axis identifier
On 29.01.12 14:20, andy pugh wrote:
On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote:
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords,
No, that is creating a second named parameter in order to be more
ambiguous later:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
...
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling of the common clauses
for free, and we only
Am 29.01.2012 um 13:59 schrieb andy pugh:
On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 = foo / #44
I am puzzled how you
On 1/29/2012 9:02 AM, Erik Christiansen wrote:
On 29.01.12 12:59, andy pugh wrote:
On 29 January 2012 12:29, Erik Christiansendva...@internode.on.net wrote:
While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:
#43 =
Am 29.01.2012 um 15:20 schrieb andy pugh:
g1YfooZ100
And here is the question? What did I mean?
I was actually meaning feed at the rate defined by the parameter oo,
but how is the parser to know that is what I wanted rather than there
being a missing S (for example) in G1 Sfoo Z100
On 1/29/2012 9:20 AM, andy pugh wrote:
On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net wrote:
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords,
No, that is creating a second named parameter in order to be more
ambiguous later:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
On 29.01.12 14:20, andy pugh wrote:
On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net wrote:
oo = 1
OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords,
No, that is creating a second named
Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
By 'grouping common clauses' do you mean testing for required or permitted
'words' pertaining to
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including canned cycles and such. Less is more.
If one insists on improving g-code, I would
On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including
On Jan 29, 2012 12:44 PM, Kirk Wallace kwall...@wallacecompany.com
wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including
On Sun, Jan 29, 2012 at 6:43 PM, Kirk Wallace
kwall...@wallacecompany.com wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
On Sun, 2012-01-29 at 19:08 +, andy pugh wrote:
On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more.
On 29.01.12 13:12, Kenneth Lerman wrote:
On 1/29/2012 9:02 AM, Erik Christiansen wrote:
But I haven't seen a troublesome gcode example yet. :-)
Remember that just because a computer can understand a grammar does not
mean that a person can. (Consider the C++ grammar.)
Point taken. (And perl
On Sun, 29 Jan 2012 10:43:18 -0800, you wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including canned cycles and such. Less is
On 29.01.12 11:14, Kent A. Reed wrote:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
...
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling
On 29.01.12 13:30, Kenneth Lerman wrote:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling of the
On 01/29/2012 10:40 PM, Erik Christiansen wrote:
On 29.01.12 13:30, Kenneth Lerman wrote:
On 1/29/2012 10:55 AM, Erik Christiansen wrote:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the
On 29.01.12 19:31, Michael Haberler wrote:
Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
By 'grouping common clauses' do you mean
On 29.01.12 23:05, Kenneth Lerman wrote:
Are you suggesting that a three axis machine where there is
no A axis should have a different grammar than a four axis machine that
does have an A axis.
No, there is no such constraint in the current parser, and there is no
reason to imagine that
On 30.01.12 02:33, Steve Blackmore wrote:
On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote:
Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with
a bit of trawling yielded this:
http://fennetic.net/irc/emc3/src/emc/interpreter/
this has rs274 parsers done with ANTLR, and bison/flex
I have no idea what the status is
-m
Am 21.01.2012 um 16:31 schrieb Scott Hasse:
All-
I'm thinking about writing some gcode filters for EMC2 in python,
On 1/28/2012 9:20 AM, Michael Haberler wrote:
a bit of trawling yielded this:
http://fennetic.net/irc/emc3/src/emc/interpreter/
this has rs274 parsers done with ANTLR, and bison/flex
I have no idea what the status is
-m
Michael:
Interesting...the directory bits irc/emc3 certainly
Am 28.01.2012 um 16:20 schrieb Kent A. Reed:
On 1/28/2012 9:20 AM, Michael Haberler wrote:
http://fennetic.net/irc/emc3/src/emc/interpreter/
I suppose a first item of business with the rs274ngc parser code would
be to examine the grammar. As a start, I just looked at the Parser and
[this should move to emc-developers, which is why I'm cc'ing there]
it just occured to me that a decent parser would give us the opportunity for a
significant language simplification while retaining backwards compatibility.
An example for the current RS274NGC language with variable references,
On 23 January 2012 06:03, Michael Haberler mai...@mah.priv.at wrote:
A prettyprinter might use whitespace to improve output readability, that's all
Does anyone else indent their loops and subs in G-code?
--
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.
Am 23.01.2012 um 03:16 schrieb Scott Hasse:
I understand where you are coming from. Word order is not important as
long as you understand how things will be interpreted, and that
understanding matches what actually happens.
I think that point alone would make a pretty printer useful.
Am 23.01.2012 um 11:17 schrieb andy pugh:
On 23 January 2012 06:03, Michael Haberler mai...@mah.priv.at wrote:
A prettyprinter might use whitespace to improve output readability, that's
all
Does anyone else indent their loops and subs in G-code?
me
me
On 1/23/2012 4:17 AM, andy pugh wrote:
On 23 January 2012 06:03, Michael Haberlermai...@mah.priv.at wrote:
A prettyprinter might use whitespace to improve output readability, that's
all
Does anyone else indent their loops and subs in G-code?
Yes
Martin
Does anyone else indent their loops and subs in G-code?
atp
The idea that there is no such thing as objective truth is, quite simply,
wrong.
--
Try before
Yes, C style.
On Mon, Jan 23, 2012 at 9:47 AM, Martin Dobbins tu...@hotmail.com wrote:
Yes
Martin
Does anyone else indent their loops and subs in G-code?
atp
The idea that there is no such thing as objective truth is, quite simply,
wrong.
On Jan 23, 2012, at 2:17 AM, andy pugh bodge...@gmail.com wrote:
Does anyone else indent their loops and subs in G-code?
me
---
Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071
Email -- acon...@ipns.com
Home-Office (503) 982-0906
Am 22.01.2012 um 04:36 schrieb Scott Hasse:
I agree there is a large and difficult problem with respect to the semantic
checking if the desire is to assure that a program will run properly. I'm
really aiming for a step or two below that, where the code would be parsed,
any semantic checks
On 01/22/2012 10:46 AM, Michael Haberler wrote:
well, my requirements for a vehicle would be roughly like so:
- industrial-strength error diagnosis and recovery, LALR(1) capable
- can generate a C/C++ scanner/parser from grammer, lexical definition
- the parser/scanner can be used from C/C++
I have followed this thread for a day or two, but I cannot understand
what would be achieved by the parsing. The beauty of gcode is its
simplicity, a whole block is read and decoded before any action is
taken, so why is word order important?
Are you looking for:
Letter codes without values, or
On 1/22/2012 4:46 AM, Michael Haberler wrote:
well, my requirements for a vehicle would be roughly like so:
- industrial-strength error diagnosis and recovery, LALR(1) capable
- can generate a C/C++ scanner/parser from grammer, lexical definition
- the parser/scanner can be used from C/C++ or
I understand where you are coming from. Word order is not important as
long as you understand how things will be interpreted, and that
understanding matches what actually happens. I think this discussion has
ranged across several useful applications for a formalized parser,
including:
1) My
On Sun, 22 Jan 2012 20:16:40 -0600
Scott Hasse scott.ha...@gmail.com wrote:
I understand where you are coming from. Word order is not important
as long as you understand how things will be interpreted, and that
understanding matches what actually happens. I think this discussion
has ranged
Am 23.01.2012 um 05:56 schrieb dave:
On Sun, 22 Jan 2012 20:16:40 -0600
Scott Hasse scott.ha...@gmail.com wrote:
including things like white space.
OUCH! I've become quite used to g-code with no white spaces and would
hate to see that forced on user. If it is an option I have no
Scott Hasse wrote:
All-
I'm thinking about writing some gcode filters for EMC2 in python, and want
to make these as robust and flexible as possible. To that end, I'm
wondering if there is a typical approach to parsing and validating
arbitrary-format gcode into some sort of canonical form so
On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote:
Every numeric value is preceded by a letter telling what it is.
Except in the wonderful world of RepRap, wherein they're now
(contemplating?) dual-extruder G-Code with multiple numeric values
after the E axis to mix / simultaneously extrude
I understand the basic parsing for the majority of common cases can be done
fairly easily, but this seems rather error-prone for something that will
eventually be moving a machine. I am hoping to build something that is
more robust for handling, e.g. inline comments and all of the other special
Am 21.01.2012 um 20:10 schrieb Ed Nisley:
The RepRap dialect seems to be diverging fairly rapidly from what the
LinuxCNC parser understands; in particular, their myriad M codes look
like a problem.
new M-codes are really easy to introduce into the LinuxCNC G-code interpreter
here's an
On Sat, 2012-01-21 at 21:27 +0100, Michael Haberler wrote:
LinuxCNC in the chipmaking corner of the CNC universe.
Which it does exceedingly well!
For a number of reasons, I don't like the Arduino-based motion control
that's common to DIY 3D printers and would vastly prefer LinuxCNC for
the
On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote:
G-code is extremely easy to parse. Every numeric value is preceded by a
letter telling what it is.
It depends what variant. There may be some this simple, for instance
variants that papertape-reading NC machines used are probably
On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote:
G-code is extremely easy to parse. Every numeric value is preceded by a
letter telling what it is.
The LinuxCNC dialect is a context-free language at least with respect to
expressions and control structures and as such cannot
In the absence of an existing solution that is basically my plan as stated
above with antlr, which can generate a python parser. Although once the
grammar is codified, there is no shortage of parser generators that could
be applied. Some of the reasons Chris points out above lie at the heart of
On 21 January 2012 15:31, Scott Hasse scott.ha...@gmail.com wrote:
To that end, I'm
wondering if there is a typical approach to parsing and validating
arbitrary-format gcode into some sort of canonical form
There is a standalone interpreter in the LinuxCNC source, though I am
not sure what it
Am 22.01.2012 um 03:31 schrieb andy pugh:
There is a standalone interpreter in the LinuxCNC source, though I am
not sure what it is for, or how it works, or if it works any more. Nor
is it in Python. In fact, I don't know why I am bothering, but I guess
I got this far, and it's now only
Am 22.01.2012 um 03:17 schrieb Scott Hasse:
Perhaps it is a lost cause, but having some sort of
what I would call a gcode lint tool would allow people who sometimes take
a naive approach to gcode extension to have an reality check.
a parser with one of the mentioned tools surely can be done
Ed Nisley wrote:
On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote:
Every numeric value is preceded by a letter telling what it is.
Except in the wonderful world of RepRap, wherein they're now
(contemplating?) dual-extruder G-Code with multiple numeric values
after the E axis to
Chris Radek wrote:
But for a modern gcode or for the linuxcnc gcode in particular, this
is not the slightest bit true, and it is a disservice for those in the
know to say it, since inexperienced people hearing it will try to
write regexp-based gcode parsers or other foolishness, and then will
79 matches
Mail list logo
