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 - n
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 r
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 a
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
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
> thin
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 onl
On 01.02.12 08:42, dave wrote:
> On Wed, 1 Feb 2012 19:34:09 +1100
> 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 l
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
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 l
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
>>>
On Wed, 1 Feb 2012 19:34:09 +1100
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 thr
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 se
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 PLY/(P
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 suppre
On Wed, 1 Feb 2012 15:14:39 +1100
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
> > > docu
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 po
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.
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
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 diff
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 curr
On 01/30/2012 01:14 AM, Erik Christiansen wrote:
> 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 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 handle
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 th
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 me
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
>>>
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 o
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
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 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
On Sun, 2012-01-29 at 19:08 +, andy pugh wrote:
> On 29 January 2012 18:43, Kirk Wallace 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
On Sun, Jan 29, 2012 at 6:43 PM, Kirk Wallace
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
On Jan 29, 2012 12:44 PM, "Kirk Wallace"
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. L
On 29 January 2012 18:43, Kirk Wallace 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
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
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
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 Christiansen 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
On 1/29/2012 9:20 AM, andy pugh wrote:
> On 29 January 2012 14:02, Erik Christiansen 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
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
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 Christiansen 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 / #
Am 29.01.2012 um 13:59 schrieb andy pugh:
> On 29 January 2012 12:29, Erik Christiansen 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
> f
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 w
On 29.01.12 14:20, andy pugh wrote:
> On 29 January 2012 14:02, Erik Christiansen 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:
Yes, th
On 29 January 2012 14:02, Erik Christiansen 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 missing here? If
On 29.01.12 12:59, andy pugh wrote:
> On 29 January 2012 12:29, Erik Christiansen 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 =
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 en
On 29 January 2012 12:29, Erik Christiansen 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 a significant probl
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 '
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 unneces
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. Doing
the same with possible user syntax improve
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 Pars
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" cer
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 pytho
[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 Jan 23, 2012, at 2:17 AM, andy pugh 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
--
Try
Yes, C style.
On Mon, Jan 23, 2012 at 9:47 AM, Martin Dobbins 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.
>
>
>
>
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 yo
me
On 1/23/2012 4:17 AM, andy pugh wrote:
> On 23 January 2012 06:03, Michael Haberler wrote:
>
>> A prettyprinter might use whitespace to improve output readability, that's
>> all
> Does anyone else indent their loops and subs in G-code?
>
--
Am 23.01.2012 um 11:17 schrieb andy pugh:
> On 23 January 2012 06:03, Michael Haberler 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
-
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.
D
On 23 January 2012 06:03, Michael Haberler 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 05:56 schrieb dave:
> On Sun, 22 Jan 2012 20:16:40 -0600
> Scott Hasse 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 problem.
> Just my p
On Sun, 22 Jan 2012 20:16:40 -0600
Scott Hasse 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 across several use
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 orig
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+
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 v
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/
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 check
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
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
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 that can be done statically would be done, the words
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 d
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 C
On 21 January 2012 15:31, Scott Hasse 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 is for, or how it w
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
m
> 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 can
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, 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 high
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 e
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
ca
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
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 fo
81 matches
Mail list logo