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

Doug, and all,

Lookahead in controls goes from the minimum 2 blocks NECESSARY to
perform cutter comp, to 5 in old GE controls, 50 in some Fanucs, 140
in EMC, and there are some who lookahead "as far as I need to" , but
these are either very high end, or sold into niche markets. (Larken
Automation's LCAM is an example. (definitely pre-computes files)

IndexerLPT does a good job in THIS area too, but requires integer
steps per inch, and no backlash comp or feedrate override! Art Volta,
the main man at Ability systems, maker of IndexerLPT, told me if I
needed backlash comp I should build/Get a better machine!

In flashcut's early days, I mentioned to Ron and Rick doing exactly
this sort of pre-compile. Don't know if they are doing it or not.

Tom Kramer and I were talking about BCL just yesterday! What's BCL??
It was supposed to be the NEXT BIG THING, replacing gcode in
controls. He says he was on the standards committee, but has not
followed it for several years. IT could become the "universal code"
some have mentioned in this thread. IT already exists! (Note for you
programmers): it is more like BASIC,or Pascal, than C++ .

>It seems that most controls like to quote a number in terms of
>blocks, but I don't see how that can be a fixed number. I would
>think it'd depend on the actual g-code.

It usually IS a fixed number, and that number is chosen to be big
enough to eliminate delays(based on the MFR's assumptions) in the
motion; small enough to minimise impact on the computers' abilities.
(this is why we're seeing larger lookahead buffers today; the
hardware can handle it.) Also small enough that latency between the
real world input and the control output are kept in sync.

>It's got to be tricky to be able to pre-process everything and vary
>the feedrate during the motion, unless you work off of a variable
>frequency hardware clock or have a few tricks up your sleeve.
>Carlos

Yes, It's very tricky. This is what drives solutions like Jon Elsons'
hardware solution, and my earlier thread on software considerations.

> Ahha, I saw a wood router guy trying to contour with cutter comp and
> it was a disaster because of the micro dwells between code blocks.

Doug Benson WAS the programmer behind the Ahha development for many
years. He left the company about 1 year ago (If I remember correctly)
I don't know if Richard has gotten someone to replace him or if
Richard is doing the coding himself at this point. They've had a
challenge with constant velocity contouring for awhile.

Both the Ahha! and EMC break down when processing lots of (CAM
created) short line segments. Fred Proctor said they (NIST) had a
guest researcher who had partially solved the problem (but needed
more work). Some of this code is in the current release of EMC (it's
not used yet, but the source IS there.)

> My question is, why don't controls have an option to pre-scan a
> program and by accessing the tool and part offset tables pre-
> calulate all the cutter paths so that when actually cutting all the
> controller has to do is deal with interrupts and motion control?

Discussed above. Realtime operator inputs in the middle of a toolpath
combined with the (until recently) heavy computing demands of motion
control.

>Or do some controls have that ability?

Yes, and I KNOW you'll be seeing at least ONE more! :)

Ballendo

P.S. some in this thread have noticed the difference between
lookahead as it is currently done, and a compiled version of the
program. These are two very different animals. I believe Doug's
original question was more to the compiled notion than the
interpreter ability to look ahead.

A final thought: The need for a shortened version of the program is
becoming LESS necessary all the time. PC's are just getting faster!

Virtually ALL controls, including EMC, build an internal represen-
tation of each Gcode line. This block of info is then used to tell
the motion hardware or code what to do, when; and where.

Nowadays, a compiled program of just these blocks WOULD BE MUCH
SHORTER AND CONCISE, but would REQUIRE the recompile of the program
for NEARLY ANY OPERATOR/PROGRAM changes, with the attendant problems
all engineers know RE: engineering change orders (ECO's) i.e.,keeping
it all in sync. And would be human unreadable, for the most part.