On 20.04.12 09:53, Viesturs Lācis wrote:
> I was thinking about Kenneth's idea:
>
> 2012/4/19 Kenneth Lerman <kenneth.ler...@se-ltd.com>:
> > Is anyone here interested in writing a filter that takes as input a
> > tolerance (error band) and a sequence of motions (arcs and line
> > segments) and generates a new sequence of motions that duplicates the
> > original within the error band? It sounds like that would be one way to
> > address the problem.
>
> Is there a way to create a filter that would convert those small, tiny
> G1s into a 3D Nurbs lines?
...
> It does not seem to be problem finding formulas on the web to
> calculate a coordinates of a point on a described line. But reversing
> that seems difficult.
Curve fitting to an arbitrary bunch of points is an approximate art,
AIUI, with tolerance calculation at all points probably taking a bit of
time. Admittedly, I don't know whether nurbs make that faster/slower or
easier/harder to achieve algorithmically. But it does look "non-trivial".
But isn't the LinuxCNC dictum "Must be able to come to a dead stop
within the current line segment" unnecessary and unhelpful when
following a piecewise linear approximation of a smooth curve? If a curve
of ten thousand linear segments were instead one continuous nurb (or
whatever), then LinuxCNC would not be expected to stop in a thousandth
of an inch at any irrelevant point along the single-segment curve, IIUC.
(That's in fact where the much-desired speed improvement would come from.)
If it is impossible to increase LinuxCNC's look-ahead, to allow it to
see that it need not radically decelerate, then why not put the
look-ahead in the gcode? Gcode allows Feedrate setting amongst the
"axes" terms in a G1. Would it not be possible to add a Gwhiz gcode to
turn off the stopping-within-a-segment hesitancy, and set a nice fast
initial Feedrate along with the G1. A lower Feedrate setting would then
be inserted prior to any sharp corner or the end of the curve.
Manual insertion of Feedrate tweaks is immediately available¹. Holding
one's breath waiting for this facility in CAM software is probably
inadvisable. But it is not a difficult task for a gcode filter to do
nothing but look for a G1 with a Gwhiz, then calculate the deceleration
needed to negotiate corners or stop at the end, and bang in a Feedrate
adjustment. (For the end, just add up micro-segment lengths until
there's enough decelerating distance, then insert the lower feedrate.
The gcode filter can look ahead to the end of the longest G1 list of
points, if system RAM permits, but a few hundred segments might do.)
This is engineering, and we're here to make swarf, with reasonable
accuracy, and optimal speed. I don't think that there's any extra merit
in a complex mathematical solution. So would something akin to the above
let us scoot faster over irregularly curvaceous workpieces?
Erik
¹ OK, inserting far enough before the corner to allow deceleration
distance would entail totting up roughly the length of the trailing
path segments, or allowing plenty. A gcode filter would be a boon.
--
In all affairs it's a healthy thing now and then to hang a question
mark on the things you have long taken for granted.
- Bertrand Russell
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
