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

>From: ballendo@... [mailto:ballendo@...]
>>Kevin wrote:
>> 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.

Sorry, I forgot to mention that I was assuming that later processing would
realize that a small-radius arc taken at too high a speed will exceed the
acceleration capabilities.
The mathematical part of my mind was just trying to simplify the overall task by
decoupling the two subtasks: detecting sharp corners and picking an appropriate
speed for genuine curved paths. The former task only needs one-move (but still
multi-line) lookahead; the latter requires a lookahead that covers enough future
distance to come to a full stop from the current speed before you reach the
current move's lookahead horizon. If the lookahead is insufficient the
controller either must be pessimistic and slow down, or charge full steam ahead
and have the controller's manufacturer blame the G-code programmer for writing
"out-of-spec" Gcode.
I was only describing the conditions under which the controller must (or
needn't) treat the transition from one move to another as essentially a
zero-radius (and thus infinite-acceleration) arc that requires a dead stop. As
you mention later in your message, another option would be a configuration
parameter that controls what radius should be used for the theoretically sharp
corners; the larger the radius, the less slowdown is required.
-Kevin Martin