> but we were always constrained to a 'tangential contour' ,meaning each
> path element could not be blended.
> 1) do 'tangential' contours like this get blended anyway?
> 2) would contours like this benefit from the effort?
> ( I'd guess CADCAM could increase velocity by removing detail,
> and CADCAM could isolate slow parts of the cuts )
If I understand correctly the velocity scheduling problem is made
(much) easier when the input G-code has a continuous tangent
("C1-continuous").
If a jerk-limited exact-stop controller is fairly easy to come up
with, then extending it to "exact-path" should not be that much
harder. I think the g-code with continuous tangent that you are
describing could be machined with an exact-path controller.
The velocity-scheduling for exact-path really only needs to look at
what is happening within a segment, and not concern itself much with
the endpoints since the startpoint of the next segment is guaranteed
to be in the direction of the last tangent.
The hard case is the one where consecutive segments don't have a
common tangent, and in order not to have to bring the machine to a
complete stop at the corner we "blend", or deviate from the programmed
path up to a maximum given tolerance. The current LinuxCNC
implementation for this has little or no documentation.
The concept of "lookahead" is somewhat independent of all of this. The
strategy is to keep the feedrate as high as possible. But we need to
be able to stop the machine at the end of the program, or when we get
to a sharp corner where we really need/want a complete stop. I think
the current LinuxCNC implementation only looks at the next G-code
segment and schedules feedrate so that it is possible to completely
stop the machine at the end of that next g-code segment.
So in summary there are a couple of issues (mostly thinking out loud
for myself, correct me if I am wrong!)
- Feedrate scheduling within one g-code segment
-- Current LinuxCNC is acceleration-limited.
-- State of the art is jerk-limited
-- Jerk-limited trajectory would be easier for motors/drives/PID to follow
- Feedrate scheduling at start/end of each segment of g-code in a program
-- Current LinuxCNC has exact-path G61 and blend G64
-- No need to change the user-experience here. But math/algorithm
changes for jerk-limited control
-- The paper does this in a separate process that maintains a queue of
feedrate-scheduled segements that are consumed by the process above.
- Lookahead. Look forward N segments in the queue of segments and
predict when we have to stop the machine.
-- Current LinuxCNC N=1.
-- More is better (?)
Improving lookahead probably involves overcoming the "one g-code
segment per traj-cycle" limitation that I understand the current
implementation has. In fact it may be this limitation more than the
N=1 lookahead that limits performance now.
Anders
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
