Re: [Emc-users] gcmc - G-Code Meta Compiler

[Bertho S. <be...@va...>]

On 10/30/2013 01:41 PM, andy pugh wrote:
> Whist not wanting to defend G-code, which is, as you say, horrible as
> a programming language, it does already contain G-codes to switch
> between units and (At least with the LinuxCNC variant) repeating
> patterns are reasonably manageable with the use of subroutines, loops
> and conditionals.

The unit switching (G20/G21) makes life more difficult (IMO) in all
cases where you have to calculate your position in a mixed setup. It is
much easier to associate a unit to a variable and let it be converted
automatically. It is less error-prone.
Secondly, reading G-code that switches between units is a real hell. The
problem is that you have to keep track manually (in your mind) which
unit target is active. Again, very error prone.

The loops and conditionals provided by G-code are, well, archaic. The
format is context-sensitive and uses line numbers to keep track. Moving
things around in a G-code program is a pain.

The reason for a context-free grammar is to make coding more flexible
without having to think about line numbers. A paradigm that has proven
to be very successful.


>> I looked for a meta compiler or generic pre-processor, but could not
>> find anything that satisfied me. Being able to program should be "easy".
> There is an alternative (and possibly more interesting) approach, you
> could develop your meta-language into an alternative interpreter for
> LinuxCNC.
> The interpreter doesn't _have _ to read G-code. It is just that the
> only one we have does so. Pluggable interpreters have been an option
> for a while.

That would certainly be an option for future development. However, my
first milestone was to be compatible with existing setups (primarily to
make my own stuff).

That is to say, I could have written my G-code program that started this
project in two days. Instead I opted for using two weeks making gcmc. :-)

For a future as a secondary/pluggable interpreter, it would be required
to finalize the grammar, discuss required built-in functionality,
discuss how to handle rotational axes and get a grip on all bugs.

I think it would be a great idea, but I do not want to rush things.


-- 
Greetings Bertho

(disclaimers are disclaimed)