Re: Look-ahead

<snip>
As to how to handle the setting of speed between segments, it seems
to me that one can either 1) pre-process the data setting in the
calculated minimum speed or 2) do the calculations between reading
the blocks. The second alternative would seem to slow down things
too much!
<end snip>
Well you pretty much have the idea. The forward looking functions
are controller
specific methods to handle the inherent problem of start/stop for
each command. The
basic command structure is blocked so the control has to execute a
block as if it is the
only one (start, accelerate , do it , decelerate, stop ) .
In the machine world you have the advantage of having a complete
file for the part so
armed with this map you can look ahead to see if there is more to
come. This process can
be done many ways each with some pro vs. con arguments. In the ideal
sense I am trying
to convert from a positional based control method to more a velocity
based. I alter the
controller logic to accept the start and stop velocity for a move in
addition to the basic
definition. Since the common G-code block format does not include the
entry and exit
velocity, it has to be calculated by combining blocks.
As you noted how you handle this is a system design question. You
could include the
required parameters in the command set by coupling the CAM function
to the controller
as some do with a custom interface command set. Obvious down side is
it is no longer a
standard interface.
You could preprocess the standard files applying all sorts of
smoothing and such then
simply execute the command stream. This would work great but is no
longer interactive,
you now have to figure how to track the lines executing , how to
provide overrides and
edits.
The logical step is then to break the control task into threads or
separate execution units.
The command processor interprets several blocks "looking ahead" far
enough to resolve
the current move and end point strategy. This is then buffered to the
drive module. This
works as long as there is enough time or processors for the geometry
engine to keep the
drive buffer full. You can retain the interactive features with minor
limitations and a
standard interface. One down side, is this method falls apart where
time becomes an
issue, rather than commanded start / stop action where acceleration
is factored in, if the
buffer runs dry you can get abrupt transitions such as a glitch to
stop from a high rate.
You have to insure the timing remains intact and should also provide
a default handling
for error cases which may or may not introduce error. In most cases
default to a rapid
deceleration on glitch will work. The theory here is you are never
moving at a rate that is
faster than the maximum deceleration can stop before the end point of
a move or series of
combined moves. Handling coordinated moves on an error?? there will
always be a case
where some error is introduced. You can improve the response through
clever means but
it is best to simply avoid the buffer out of data errors and limit
the rates to what the
processing equipment can handle.

How you handle the look ahead varies but the basic idea remains
constant. You simply
need to look far enough ahead to resolve the current move and you
need to process
enough moves such that the worst case delay in the geometry can keep
up with the
buffered driver logic. The driver section may be an external buffer,
a separate task or a
dedicated interrupt process . With enough processor you can even roll
the tasks back into
one running fast enough but this would not be my preferred choice.
As you figured there is no magic, the work has to be done so it is
simply a matter of how
you slice the pie.

Brian.
BSP