RE: Thoughts on Gcode interpreters and CNC controls....

>Kevin wrote:
>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.

Exactly right.

>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.

Actually, the problem with ahha is constant velocity contouring
"breaking down" in certain specific, and nowadays more common
instances. This is one FUNCTION of the lookahead process, or rather,
lookahead is ONE COMMON WAY of implementing constant vector velocity
toolpath cutting. (moving along the toolpath AT THE GIVEN FEEDRATE,
at least as fast as the PHYSICS of the machine allow.)

>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.

This will only help IF the problem is in calculation time for
offsets, which as you mention, is GENERALLY pretty simple math.

>The other thing that can be usefully done during lookahead is the
>elimination of the decelerate/dead stop/accelerate between each
>move.

Correct.

> 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.

No. If it were implemented this way, it would/will break down. You
have to look at the RATE of change(in speed and/or direction) within
a given DISTANCE, and modify the feedrate, incorporating accel/decel.

For example A long straight line into a large radius arc is very
different than the same long straight line into a tiny 180 degree arc.

>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.

Yes. and no. The control designer(s) make decisions (based on their
hardware resources and what they feel their customers will need)about
the size of the lookahead they feel will prevent the scenario you
describe. That is why the typical lookahead buffer has grown in size
in recent years; the hardware resources can support it. The older
controls even warned in their manuals not to put non motion lines in
the middle of cutter comp (since the buffer would fill with non-
useful info and cutter comp would break down).

As you say, it still breaks down at the "horizon". The trick is
making the "horizon" shift away as it does for us in the real world.

reminds me of the man chasing the horizon, who when told his efforts
were futile said, "you lie!,he cried. And ran on."

So you are correct, we must look ahead a specific distance (which
changes with feedrate, axis combinations, vector delta read:change in
direction),across multiple lines of gcode(if necessary), to achieve
the required distance for possible decel/stop. We also have to
perform the cutcomp calcs in the time our hardware allows us between
output to steppers or servo updates.(servos must ALSO read the
encoders,convert counts to distance,etc.)

>As someone alluded to, another thing lookahead can do is buffer up
>lower-level commands<snip,where the commands go is immaterial>

This is what Doug mentioned in the beginning of this thread!

So the real question remains. Do we save enough processing time
"compiling" the gcode to low-level cmds? To be worth the hassle of
keeping correlation between the "source" code and the "output" code?
And the loss of(or need to account for) operator interact-ability?

There are only two lower cost systems I'm aware of which do what
we've been talking about, both mentioned earlier;

1.Lcam (which is an integrated environment,proprietary as to internal
"compiled" code AND methods. Larry (main man at Larken automation)
says, "I worked a LONG time to figure this out!")

2.And IndexerLPT(which Art Volta, ability systems main man says
doesn't need backlash comp, and uses integer steps per unit).
Feedrate override "Real Soon Now".

3? Maybe Flashcut? I don't know anymore?

Ballendo

P.S. The CNC world has been using the following model for "Blending
the axis motions" for many years.

When we reach the point to begin decel of the CURRENT move, We begin
the ACCEL of the next move. (next move IS from the lookahead,
hopefully big enough to prevent problems)

Result is rounding of corners, which machinists have learned to live
with, or turn on an EXACT STOP mode where such "rounding errors" :)
are unacceptable.

It worked reasonably well for most people UNTIL CAM(computer-
generated gcode) became more prevalent,AND when products became more
"curvy-three-dimensional". The CAM files are HUGE, with lots of tiny
(short) lines standing in for the arcs of the REAL part. THIS is
EXACTLY the type of file the above method chokes on!

The CAD/CAM people are struggling to get the arcs back into the
output so the control processes fewer short entities. And the CNC
people are struggling to get better at handling LOTS OF short line
segments.