RE: [CAD_CAM_EDM_DRO] Thoughts on Gcode interpreters and CNC controls....

The problem with saying that a system does 2 (or 5 or 50...) lines of lookahead,
is that this is essentially meaningless, unless you also state what the
lookahead accomplishes. In some sense almost *any* PC-based controller does
"lookahead" merely by the fact that it does block reads of its input file. But
that really can't be considered to be a useful form of lookahead.
One of the things that can be usefully done during lookahead is toolpath offset
calculation. I gather that this is the feature that Ahha has (had?) problems
with, although I am not certain why they seem like simple enough calculations.
As someone mentioned, if your controller has problems with this, you can
preprocess your G-code to give the tool centerline path instead of the cutting
path, and run the controller without the offset calculation.
The other thing that can be usefully done during lookahead is the elimination of
the decelerate/dead stop/accelerate between each move. If (and only if) the end
of one move and the start of the next have a common tangent (in 3-D) it is not
necessary to stop, or even to slow down, between the moves. In order to
implement this, however, the controller must lookahead not a specific number of
lines, but a specific distance of overall motion. If it has a limit on the
lookahead lines, it must assume that a dead stop is required at the lookahead
horizon, and possibly start decelerating several lines before that point to make
sure that the (assumed) dead stop is possible.
As someone alluded to, another thing lookahead can do is buffer up lower-level
commands to some form of programmable pulse generator.
-Kevin Martin