Re: [Emc-users] parsing the current language dialect, and describing as EBNF

[John P. <jo...@ca...>]

From: "andy pugh" <bod...@gm...>
To: <emc...@li...>
Sent: Monday, February 06, 2012 8:03 AM

<snip>

> However I see no reason why we shouldn't consider starting from
> scratch with a new machine-control language, possibly based on Python
> syntax. I would prefer to see that translated directly into motion
> commands in LinuxCNC rather than into any sort of G-code, though.
>
> However, fun though that might be, I doubt it would reach completion,
> or gain any sort of market acceptance outside a very small subset of
> LinuxCNC users, and almost certainly wouldn't expand outside our
> project.

I agree with Andy's last paragraph.

There are, however, pursuasive reasons for a change from G-codes if we could 
allow the machine tool to "understand" enough about what it is doing to be 
(self-)adaptive.

There is a current example in cutter wear compensation. The machine (if 
fitted with laser metrology) or operator (with a micrometer) can adjust the 
control to compensate for a tool that is wearing - no need to re-CAM the 
part!.

Generally though the control dumbly obeys orders (from the CAM) - e.g. 
executing lots of line or arc segment with no notion they define the wall of 
a pocket. As we know, trouble comes if G42 comp is on and a sharp internal 
corner shows up.

There has been international work on a project (STEP-NC) that aims to give 
enough information about the design intent of a part so that the control can 
optimise finish, metal removal, accuracy, or, WHY depending on the stiffness 
of the machine, how blunt the tooling is, variations in the workpiece etc.

This is very ambitious and I have no idea if it is still active or got 
stalled but a higher level machining abstraction could make it worth passing 
on the obvious advantages of the familiar G-codes.

John Prentice